Volumetric clouds что это

Volumetric Clouds

An overview of real-time cloud rendering using the Volumetric Clouds component and volume materials.

The Volumetric Cloud component is a physically-based cloud rendering system that uses a material-driven approach to give artists and designers the freedom to create any type of clouds they need for their projects. The cloud system handles dynamic time-of-day setups that is complemented by the Sky Atmosphere and Sky Light using the real time capture mode. The system provides scalable, artist-defined clouds that can adapt to projects using ground views, flying, and ground to outer space transitions.

How are clouds rendered?

Previously, rendering clouds in real-time for games and cinematics have primarily been achieved through static materials applied to a sky dome mesh or a similar approach. Now, the volumetric cloud system uses a three-dimensional volume texture that is ray-marched to represent cloud layers in real-time. The material-driven approach provides the most flexibility for artists and designers to create clouds that can move across the sky, of any type, and can handle different times of day.

The sections that follow explore and break down the cloud system’s elements that contribute to rendering them for real-time rendering.

Ray Marching the Cloud Volume

The participating media that makes up clouds require complex lighting simulations that either aren’t possible, or are too expensive, for real time simulation on consumer-grade hardware. The Volumetric Cloud system employs ray- marching and approximation to simulate cloud rendering for scalable real-time performance across many supported platforms and devices. This makes it possible to support real time time-of-day simulations that support the multiple light scattering effect of lighting, shadowing from clouds and onto clouds, light contribution from the ground onto the bottom layer of clouds, and much more.

Light Multiple Scattering

Light rays that travel through a volume have the potential to scatter on particles within the volume before reaching your eye, or a camera sensor. This effect of light is called multiple scattering, and it is what defines the distinct appearance of clouds. In a cloud, the droplets that make up the cloud usually lead to an albedo that is close to a value of 1, meaning that light is almost never absorbed within the volume. Light that is not absorbed passes through the volume making the scattering effect very complex in the process. The multiple scattering effect of the participating media affects light travel through the cloud volume; it’s what makes them look bright while also appearing very thick.

The complexity of multiple scattering in real-time rendering is solved by using an approximation of realistic scattering by tracing multiple octaves (or steps) of light transmittance in the volume material. The Volumetric Advanced Material Output expression enables you to set the number of octaves used along with the amount of multiple scattering contribution, occlusion, and eccentricity that happens.

The example below shows the difference between no octaves used (single scattering), one octave, and two octaves of multiple scattering approximation. High octaves apply additional scattering approximations to your cloud material but make the shader more expensive in the process.

For games projects, it is recommended to only use a single octave of light multiple scattering for performance considerations. However, you can use high Contribution and low Occlusion values on the Volumetric Advanced Material expression in your cloud material to similar effect without impact to performance. See the Volumetric Material section below.

Источник

Volumetric clouds что это

Volumetric Clouds in Unity

Use three different textures to render the volumetric clouds,

Perlin-Worley texture ( base cloud shape ) : 128^3 resolution

Worley noise texture ( detail base cloud shape ) : 32^3 resolution

Cloud density model

Weather system:

This little map represents the weather settings that drive the clouds over our section of world map. The Red is coverage, Green is precipitation and blue is cloud type.

Cloud type :

Height gradient:

height gradient change the noise signal over altitude.

If we were to describe the probability of change in density over height for a cloud we might use a remapping function.

Basic cloud shape:

We build a basic cloud shape by sampling our Perlin-Worley texture and multiplying it by our height signal and then multiply the result by the coverage.

Detail cloud shape:

Erode the base cloud shape by subtracting the Worley noise texture at the edges of the cloud. If you invert the Worley noise at the base of the clouds you get some nice whispy shapes.

Wind effect :

Cloud Lighting model

Ambient light:

Beer’s Law :

Beer’s law states that we can determine the amount of light reaching a point based on the optical thickness of the medium that it travels through.

Henyey-Greenstein model :

In clouds, there is a higher probability of light scattering forward. This is called Anisotropic scattering. This model is used to reproduce Anisotropy in cloud lighting.

Each time we sample light energy, we multiply it by The Henyey-Greenstein phase function plus Beer’s Law.
Light Energy = e^<-d>*HG

Rendering sun light:

Rendering cloud:

By ray marching through spherical atmosphere we can ensure that clouds properly descend into the horizon.

Step1. Determine eye position under the clouds, within the clouds or above the clouds.

If you had some questions about» INTERSECTION OF A RAY WITH A SPHERE «, please refer to the references[3], p.388.

Step2. Calculate ray step length based on the distance from eye position to cloud.

Источник

Реализация физически корректных объемных облаков как в игре Horizon Zero Dawn

Раньше облака в играх рисовались обычными 2D спрайтами, которые всегда повернуты в направлении камеры, но последние годы новые модели видеокарт позволяют рисовать физически корректные облака без заметных потерь в производительности. Считается, что объемные облака в игры принесла студия Guerrilla Games вместе с игрой Horizon Zero Dawn. Конечно, такие облака умели рендерить и раньше, но студия сформировала что-то вроде промышленного стандарта на исходные ресурсы и используемые алгоритмы, и в настоящее время любая реализация объемных облаков так или иначе этому стандарту соответствует.

UPD. Картинка обновлена. Изменения описаны в конце статьи.

Весь процесс рендеринга облаков очень хорошо разбивается на этапы и важно отметить, что неточность реализации даже на одном из них может привести к таким последствиям, что будет непонятно где ошибка и как ее исправлять, поэтому желательно каждый раз делать контрольный вывод результата.

Tone mapping, sRGB

Перед началом работы с освещением важно сделать две вещи:

Формула подойдет для большинства случаев, но не в 100% в зависимости от монитора. Важно, что sRGB преобразование всегда делается в последнюю очередь.

Модель освещения

Рассмотрим пространство заполненное частично прозрачным веществом разной плотности. Когда луч света проходит сквозь такое вещество, то он подвергается воздействию четырех эффектов: поглощению, рассеиванию, усиливающему рассеиванию и самоизлучению. Последнее возникает в случае химических процессов, протекающих в веществе, и здесь не затрагивается.

Допустим, у нас есть луч света, который проходит через вещество из точки A в точку B:

Свет, проходя сквозь вещество, подвергается поглощению этим самым веществом. Непоглощенную долю света можно найти по формуле:

где — оставшийся после поглощения свет в точке . — точка на отрезке AB на расстоянии от A.

Часть света под воздействием частиц вещества меняет свое направление. Долю света, не изменившего свое направление, можно найти по формуле:

где — доля света, не изменившего свое направление, после рассеивания в точке .

Поглощение и рассеивание необходимо объединить:

Функцию называют затуханием (attenuation или extinction). А функцию — передаточной функцией. Она показывает сколько света останется при прохождении из точки A в точку B.

Что касается и : , где C — некая константа, которая может иметь разное значение для каждого канала в RGB, — плотность среды в точке .

Теперь усложним задачу. Свет движется из в точки A в точку B, он затухает в процессе движения. В точке X часть света рассеивается в разных направлениях, одно из направлений соответствует наблюдателю в точке О. Далее порция рассеянного света движется из точки X в точку О и снова затухает. Путь интересующего нас света AXO.

Потерю света при движении из A в X мы знаем: , также как и знаем потерю света из X в O — это . Но что на счет доли света, которая будет рассеяна в направлении наблюдателя?

Если в случае обычного рассеивания интенсивность света падает, то в случае усиливающего рассеивания она увеличивается за счет рассеивания света, произошедшего в соседних областях. Суммарную величину света, пришедшего из соседних регионов, можно найти по формуле:

где означает взятие интеграла по сфере, — фазовая функция, — свет пришедший из направления .

Посчитать свет со всех направлений достаточно сложно, однако, мы знаем, что основную порцию света несет наш оригинальный луч AB. Формулу можно существенно упростить:

где — угол между лучом света и лучом наблюдателя (т.е. угол AXO), — исходное значение интенсивности света. Суммируя все вышесказанное, получим формулу:

где — входящий свет, — свет, дошедший до наблюдателя.

Усложним задачу еще чуть-чуть. Допустим, свет испускается источником света типа directional light, т.е. солнцем:

Происходит все тоже самое как в предыдущем случае, но много раз. Свет из точки А1 рассеивается в точке Х1 в сторону наблюдателя в точке О, свет из точки А2 рассеивается в точке Х2 в сторону наблюдателя в точке О и т.д. Мы видим, что свет достигший наблюдателя равен сумме:

Или более точное интегральное выражение:

Важно понимать, что здесь , т.е. отрезок разбит на бесконечное количество участков нулевой длины.

С небольшим упрощением солнечный луч, проходящий через атмосферу, подвергается только рассеиванию, т.е. .

И даже не одному типу рассеивания, а целым двум: релеевскому рассеиванию и рассеиванию Ми. Первое вызвано молекулами воздуха, а второе аэрозолем воды.

Суммарная плотность воздуха (либо аэрозоля), через которую пройдет луч света, двигаясь из точки A в точку B:

где — масштабирующая высота, h — текущая высота.

Простое решение интеграла будет таким:

где dh — размер шага, с которым берется выборка высоты.

Теперь посмотрим на рисунок и воспользуемся формулой, выведенной в предыдущей части “модель освещения”:

Наблюдатель смотрит из O в O’. Мы хотим собрать весь свет, который достигнет точек X1, X2, …, Xn, будет в них рассеян, а затем достигнет наблюдателя:

где интенсивность излучаемого солнцем света, — высота в точке ; в случае с небом константа С, находящаяся в функции обозначается как .

Решение интеграла может быть таким:

Эта формула справедлива как для релеевского рассеивания так и для рассеивания Ми. В итоге значения света для каждого из рассеиваний просто складываются:

(содержит значения для каждого канала RGB)

(значения для всех каналов RGB одинаковы)

Количество выборок на отрезке и на отрезке можно брать 32 и выше. Значения радиуса Земли — 6371000 м, толщина атмосферы — 100000 м.

Что со всем этим делать:

Модель облаков

Нам потребуется несколько видов шума в 3D. Первый — это тайлящийся fractal Brownian motion (fBm) шум Перлина:

Результат для 2D среза:

Второй — тайлящийся fBm шум Вороного.

Результат для 2D среза:

Для получения тайлящегося fBm шума Ворлея необходимо инвертироваь тайлящийся fBm шум Вороного. Однако, я немножко изменил диапазоны значений на свое усмотрение:

Результат сразу напоминает облачные структуры:

Для облаков нужно получить две специальных текстуры. Первая имеет размер 128х128х128 и отвечает за низкочастотный шум, вторая имеет размер 32х32х32 и отвечает за высокочастотный шум. Каждая текстура использует только один канал в формате R8. В некоторых примерах используют 4 канала R8G8B8A8 для первой текстуры и три канала R8G8B8 для второй, а затем каналы смешивают в шейдере. Я не вижу в этом смысла, потому что смешивание можно произвести заранее тем самым получив большее попадание в cache coherence.

Для смешивания, а также еще в некоторых местах будет использоваться функция remap(), которая масштабирует значения из одного диапазона в другой:

Начнем подготовку текстуры с низкочастотным шумом:
R-канал — тайлящийся fBm шум Перлина
G-канал — тайлящийся fBm шум Ворлея
B-канал — тайлящийся fBm шум Ворлея с меньшим масштабом
A-канал — тайлящийся fBm шум Ворлея с еще меньшим масштабом

Смешивание производим таким образом:

Результат для 2D среза:

Теперь готовим текстуру с высокочастотным шумом:
R-канал — тайлящийся fBm шум Ворлея
G-канал — тайлящийся fBm шум Ворлея с меньшим масштабом
B-канал — тайлящийся fBm шум Ворлея с еще меньшим масштабом

Результат для 2D среза:

Еще нам потребуется 2D текстура-погодная карта, которая будет определять наличие, плотность и форму облаков в зависимости от координат пространства. Ее рисуют художники для более точной настройки облачности. Интерпретация цветовых каналов погодной карты может быть разной, в варианте, который я одолжил, она следующая:

R-канал — покрытие облаков на малой высоте
G-канал — покрытие облаков на большой высоте
B-канал — максимальная высота облаков
A-канал — плотность облаков

Теперь мы готовы к тому, чтобы составить функцию, которая будет возвращать плотность облаков в зависимости от координат 3D пространства.

На входе точка пространства с координатами в км

Сразу добавляем смещение ветром

Получаем значения погодной карты

Получаем процент высоты (от 0 до 1)

Добавляем небольшое скругление облаков снизу: Делаем линейное уменьшение плотности до 0 с увеличением высоты согласно B-каналу погодной карты:

Снова добавляем скругление облаков снизу:

Также добавляем скругление облаков сверху:

Объединяем результат, сюда же добавляем влияние плотности из погодной карты и влияние плотности, которая задается через gui:

Объединяем низкочастотный и высокочастотный шум из наших текстур:

Во всех документах, которые я читал, объединение происходит другим способом, но мне понравился такой вариант.

Определяем величину покрытия (% неба, занятый облаками), которое задается через gui, также используются R-,G- каналы погодной карты:

Вычисляем финальную плотность:

Какой именно должна быть эта функция — вопрос открытый, потому что проигнорировав законы, которым подчиняются облака при настройке параметров, можно получить очень необычный и красивый результат. Все зависит от области применения.

Интегрирование

Атмосфера Земли делится на два слоя: внутренний и внешний, между которыми могут находится облака. Эти слои можно представить сферами, а можно и плоскостями. Я остановился на сферах. Для первого слоя я взял радиус сферы 6415 км, для второго слоя радиус 6435 км. Радиус Земли округлил до 6400 км. От условной толщины “облачной” части атмосферы (20 км) в дальнейшем будут зависеть некоторые параметры.

В отличие от неба облака непрозрачны и при интегрировании требуется не просто получить цвет, но также получить значение для альфа-канала. Для начала нужна функция, которая вернет суммарную плотность облака, через которую пройдет луч света от солнца.

Никто не заостряет на этом внимание, но практика показала, что вовсе не нужно учитывать весь путь луча, нужен только самый крайний промежуток. Мы допускаем, будто облака выше усеченного отрезка вообще не существуют.

Кроме того, мы сильно ограничены в количестве выборок плотности, которые можно сделать не убив производительность. Guerrilla Games делают 6. При чем в одной из презентаций разработчик сказал, что они разбрасывают эти выборки внутри конуса, и последняя выборка специально делается очень далеко от остальных, чтобы охватить как можно больше пространства. Полученные неточности и шум все равно сгладятся на фоне соседних выборок и это наоборот превратится в повышенную точность.

Я в итоге остановился на 4 выборках, которые лежат на одной линии, однако последняя берется с увеличенным в 6 раз шагом. Размер шага 20 км * 0.01, что равно 200 м.

Функция довольно проста:

Теперь можно перейти к более сложной части. Определяем наблюдателя на поверхности Земли в точке <0, 6400,0>и находим пересечение луча наблюдения со сферой радиусом 6415 км и центром <0,0,0>— получаем стартовую точку S.

Ниже базовый вариант функции:

Размер шага определяем как 20 км / 64. Т.е. в случае со строго вертикальным направлением луча наблюдателя мы сделаем 64 выборки. Однако, когда это направление более горизонтально, то выборок будет несколько больше, поэтому в цикле не 64 шага, а 128 — с запасом.

На старте мы полагаем, что конечный цвет черный, а прозрачность равна единице. С каждым шагом мы будем увеличивать значение цвета и уменьшать значение прозрачности. Если прозрачность окажется близкой к 0, то можно осуществить предварительный выход из цикла:

ufmProperties.attenuation — есть не что иное как C в , а ufmProperties.attenuation2 — C в . ufmProperties.sunIntensity — интенсивность излучения солнца. sunColor — цвет излучения солнца.

В глаза сразу бросается недостаток — сильное затенение. Но сейчас мы будем исправлять отсутствие усиленного освещения вблизи солнца. Так получилось, потому что мы не добавили фазовую функцию. Для расчета рассеивания света, проходящего через облака, используется фазовая функция Хеньи-Гринштейна, которые открыли ее в 1941 году для аналогичных вычислений в газовых скоплениях в космосе:

Здесь следует сделать отступление. По каноничной модели освещения фазовая функция должна быть одна. Однако на деле получаемый результат никого не устраивает и фазовых функций все используют две, да еще и объединяют их значения особым образом. Я также остановился на двух фазовых функциях, но их значения просто складываю. Первая фазовая функция имеет g близкое к 1 и позволяет сделать яркое освещение вблизи солнца. Вторая фазовая функция имеет g близкое к 0.5 и позволяет сделать постепенное уменьшение освещенности по всей небесной сфере.

ufmProperties.eccentrisy, ufmProperties.eccentrisy2 — это значения g

Теперь можно начать борьбу со слишком сильным затенением. Оно присутствует, потому что мы не учли свет от окружающих облаков и неба, который есть в реальной жизни.

Я решил эту проблему так:

Где ambientColor — цвет неба в направлении луча наблюдения, ufmProperties.ambient — настроечный параметр.

Осталось решить последнюю проблему. В реальной жизни чем более горизонтального направления придерживается взгляд, тем больше мы видим некий туман или дымку, которые не позволяют нам видеть совсем далекие объекты. Это также нужно отразить в коде. Я взял обычный косинус угла направления взгляда и экспоненциальную функцию. На основании этого вычисляется некий коэффициент blending, который позволяет сделать линейную интерполяцию между результирующим цветом и цветом фона.

ufmProperties.fog — для настройки вручную.

Видео с демонстрацией:

Оптимизация и возможные улучшения

После реализации базового алгоритма рендеринга следующая проблема заключается в том, что он слишком медленно работает. Мой вариант выдавал 25 fps в full hd на radeon rx 480. Два следующих подхода для решения проблемы предложили сами Guerrilla Games.

Рисуем то что действительно видно

Экран делится на тайлы размером 16х16 пикселей. Сначала отрисовывается обычное 3D-шное окружение. Оказывается, что большая часть неба закрыта горами или крупными объектами. Соответственно требуется выполнить расчет только в тех тайлах, облака в которых ничем не загорожены.

Когда камера неподвижна, получается что облака в общем-то можно и не обновлять. Однако, если камера сдвинулась — это не значит что нам нужно обновить целый экран. Все уже отрисовано, нужно просто перестроить картинку в соответствием с новыми координатами. Нахождение старых координат по новым, через проекционную и видовую матрицы текущего и предыдущего кадров называется репроекцией. Таким образом, в случае смещения камеры мы просто переносим цвета в соответствии с новыми координатами. В тех случаях, когда эти координаты указывают за пределы экрана, облака необходимо уже честно перерисовать.

Идея с репроекцией мне не нравится тем, что при резком повороте камеры может получиться, что рендерить облака придется для трети экрана, что может вызвать лаг. Не знаю, как с этим разобрались Guerrilla Games, но по крайней мере, в Horizon Zero Dawn при управлении джойстиком камера движется плавно и проблем с резкими скачками там нет. Поэтому в качестве эксперимента я придумал свой подход. Облака рисуются в кубическую карту, в 5 граней, т.к. низ нас не интересует. Сторона кубической карты имеет пониженное разрешение, равное ⅔ от высоты экрана. Каждая грань кубической карты делится на тайлы размером 8х8. Каждый кадр на каждой грани обновляется только один из 64 пикселей в каждом тайле. Это дает заметные артефакты при резких изменениях, но т.к. облака довольно статичны, то такой трюк незаметен. В итоге radeon rx 480 выдает 500 fps в full hd под вулкан и 330 fps под opengl. Radeon hd 5700 series выдает 109 fps в full hd под opengl (vulkan не поддерживает).

При обращении к текстурам с шумом брать данные с нулевого mip-уровня можно только в самых первых выборках, а затем чем более дальние выборки мы делаем, тем больший можно брать mip-уровень.

Чтобы симулировать наличие перисто-высотных и перисто-кучевых облаков в Guerrilla Games при интеграции последние выборки делаются не из 3D текстур, о которых я рассказывал, а из специальной 2D текстуры.

Для создания эффекта раздувания облаков ветром используется несколько дополнительных текстур в curl-шумом. Эти текстуры нужны, чтобы сместить оригинальные координаты.

Такие лучи, нагоняющие драмы, реализуются в постпроцессинге. Сначала рисуется яркая подсветка вокруг солнца, где оно не перекрыто облаками. Затем эту подсветку необходимо радиально сместить прочь от солнца.

Теперь нужно применить радиальное сглаживание.

На самом деле улучшений и тонкостей намного больше, но я не стал проверять их все, поэтому не могу с уверенностью про них рассказать. Однако, ознакомиться с ними можно самостоятельно. Самой сильной я считаю документацию по облакам от движка Frostbite.

Обновление. V2.

Второй итерацией я внес небольшие изменения и улучшил внешний вид облаков.

Постоянное рассеивание лучей света внутри облаков приводит к тому, что до глаз наблюдателя может доходить не только прямой свет от солнца, который прошел через облако, но и, например, тот, которым облако освещено с боковых сторон. Это называется мультирассеиванием или множественным рассеиванием.

Без этого эффекта облака больше похоже на дым, что можно было видеть в предыдущей версии. Хорошей аппроксимацией мультирассеивания является повторение одних и тех же вычислений с разными коэффициентами и значением g для фазовой функции.

Напомню формулу интегрирования при единственном рассеивании:

где

Формула для множественного рассеивания будет такой:

где

где a, b, c подбираются вручную, для начала можно взять значения 0.5 для всех, а N взять равным 7.

Мультирассеивание требуется только для облаков, для неба оно не внесет существенных изменений.

Исправление цвета неба

В формулах есть неточность: я считаю релеевское рассеивание и рассеивание Ми параллельно, хотя в действительности его надо считать последовательно. Допустим, после первого шага i = 0 мы посчитали остаточный свет после релеевского рассеивания, теперь этот свет используем для вычисления остаточного света после рассеивания Ми и только потом переходим к шагу i = 1, где находим остаточный свет от остаточного света после шага i = 0. Также я добавил влияние озонового слоя, который аналогично вклинивается в формулу с последовательным расчетом. Ниже коэффициенты для всех трех типов рассеивания, которые я использовал.

#define RAY_SCATTERING vec3(5.8 / 1000000.0, 13.5 / 1000000.0, 33.1 / 1000000.0)
#define MIE_SCATTERING vec3(2.0 / 1000000.0)
#define OZONE_SCATTERING vec3(0.0)
#define RAY_EXTINCTION RAY_SCATTERING
#define MIE_EXTINCTION (MIE_SCATTERING * 1.1)
#define OZONE_EXTINCTION (vec3(3.426, 8.298, 0.356) * 0.06 / 100000.0)

В принципе это все. Далее будут результаты того что получилось после внесения изменений. С мультирассеиванием без исправления неба:

С мультирасеиванием и с исправленным небом:

Источник