Войти
Вячеслав ЕгоровСтатьи

Атмосферные эффекты в играх (Crytek, перевод) (3 стр)

Автор:

Изображение

Сверху слева: сцена ландшафта утром, настройки по умолчанию
Сверху справа: плотность глобального тумана увеличена
Снизу слева: сцена заката, наблюдаемая с другой позиции, настройки по умолчанию
Снизу справа: плотность глобального тумана увеличена
Заметьте, как солнечное гало блестит на частях ландшафта.
Изображение
Слева: сцена ландшафта утром, спад по высоте увеличен
Справа: сцена ландшафта утром, спад по высоте уменьшен, глобальная плотность тумана увеличена
Изображение
Кадры заката с различными настройками для глобальной плотности, спада по высоте, факторов рассеивания М'и (Mie) и Рэлея (Rayleigh)
Таблица 1. Эффекты атмосферного рассеивания

6. Локально распределённый туман с помощью объёмов тумана


  Для целей игрового дизайна часто требуется локально спрятать или замаскировать определённые области в игровом мире, и для такой задачи глобальный туман не очень подходит. Вместо него мы используем объёмы тумана. Целью реализации было сделать модель на подобии той, которая описана в главе 4, но только для локально распределённой области. Мы поддерживаем два типа объёмов тумана: эллипсоиды и боксы. Как мы видим выше в функции ComputeVolumetricFog, нам потребуются стартовая и конечная точки внутри объёма тумана для нахождения значения цвета тумана. Отметьте, что глобальный объёмный туман, это не что иное, как бесконечный объём со стартовой точкой у камеры, и конечной у мировой позиции текущего фрагмента. Для определения этих двух точек мы рисуем геометрическую оболочку объёма тумана: если камера находиться снаружи объёма, рисуем передние грани с включенным тестом глубины, иначе, рисуем задние грани с выключенным тестом глубины. Таким образом возможно узнать, где луч из камеры пересекает объём, и пересекает ли он его вообще. Трассировка луча для обоих примитивов происходит в пространстве объекта для упрощения и ускорения расчёта. Если пересечение не найдено, отрисовка пикселя отменяется HLSL командой clip. Делая это, мы упрощаем результирующий код для графических ускорителей, которые не поддерживают быстрых динамических ветвлений, и компилятору не приходится иметь дело с “if”\“else” условиями, для которых в таком случае надо исполнять обе ветви кода, и выбрать финальный результат. Если пересечение с объёмом происходит, мы делаем дополнительную проверку, используя значение глубины фрагмента, для того чтобы определить случай, когда луч сталкивается с геометрией сцены ещё до того, как выйдет из объёма тумана. В таком случае, позиция фрагмента перезаписывает конечную позицию вектора. Также, в случае, если мы находимся внутри объёма тумана, стартовая точка будет являться позицией камеры. После нахождения стартовой и конечной точки пересечения луча, их можно вставить в формулу расчёта объёмного тумана.
Изображение
Таблица 2. Объём тумана, с трассировкой луча на GPU (эллипсоид), наблюдаемый снаружи (слева) и изнутри (справа)

  Другие подходы реализации объёмов тумана также были приняты во внимание. Полигональные объёмы тумана выглядели хорошей идеей с начала (глубина всех задних граней вычитается из глубины всех передних граней для получения длины луча проходящего сквозь объём тумана по направлению к пикселю). Они также не страдали от артефактов отсечения граней у ближней плоскости отсечения, так как глубина равная нулю никак не влияет при сохранении глубины передних и задних граней. Их преимущество над строгими примитивами, описанными выше, заключается в том, что они могут быть очень сложными (но при этом выпуклыми). Однако пытаясь сделать эффективную трассировку луча, мы остались с более простыми примитивами как эллипсоиды и боксы. Но полигональные объёмы тумана имеют ещё несколько минусов, которые были приняты во внимание и перевесили их преимущества (как минимум для целей CryEngine2):
- Они позволяют реализовать только простой туман, основанный на глубине.
- На данный момент они требуют отрисовки в два прохода для сохранения глубины задних граней, и вычитания глубины передних граней.
- Более того, они также требуют дополнительную текстуру и поддержку блендинга с floating point точностью, что запрещено, когда поддержка объёмов тумана требуется и на старом оборудовании.
  Существуют реализации полигональных объёмов тумана, которые используют хитрые игры с битами для того чтобы заставить их работать со стандартными RGBA8 текстурами. Но вместе с этим появляются требования, чтобы объёмы тумана не переходили определённые рамки размеров и depth complexity, чтобы избежать переполнения чисел. Эти ограничения перевешивают все остальные преимущества.
Изображение
Таблица 3. Объём тумана, с трассировкой луча на GPU (бокс), наблюдаемый снаружи (слева) и изнутри (справа)

7. Применение тумана к полупрозрачным объектам


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

7.1. Глобальный туман


  Глобальный туман для полупрозрачных объектов рассчитывается в вертексном шейдере. Нужно также позаботиться о том, чтобы правильным образом смешивать затуманенный полупрозрачный объект со значением цвета в буфере кадра, который уже хранит затуманенную сцену с непрозрачной геометрией. Очень хорошо, что полный расчёт тумана (как плотности, так и цвета) полностью основан на математических инструкциях и не требует выборок из таблиц какого-либо вида. Использование текстур было бы невозможным, так как ранние шейдерные модели не позволяют делать выборку из текстуры в вертексном шейдере, но должны поддерживаться ради совместимости.

7.2. Локальные объёмы тумана


  Расчёт влияния локальных объёмов тумана на полупрозрачные объекты более сложен. На данный момент, оно просчитывается только для каждого объекта целиком. Это кажется наихудшим приближением из всех, но было обнаружено, что если дизайнеры знают о таких ограничениях, они могут сами находить обходные пути. Обычно им требуется следить, чтобы полупрозрачные объекты не становились слишком большими. Также, переход цвета в объёме тумана должен быть более мягким, так как резкие переходы более явно показывают проблемы aliasing’а (то есть, видно, что берётся один сэмпл на весь объект). Код трассировки, выполняемый попиксельно на GPU, может быть легко переведён обратно в C++ и задействоваться для каждого полупрозрачного объекта посланного на отрисовку. Для того чтобы максимально уменьшить количество трассировок луча, требуется иерархическая структура, хранящая объёмы тумана. Для нахождения общего влияния всех объёмов тумана, которые находятся перед полупрозрачным объектом, результаты трассировки луча в разных объёмах смешиваются в порядке от дальних к ближним (то есть, дальние объёмы тумана принимаются во внимание первыми). Были опробованы и другие подходы, как например, получение объёмной текстуры, содержащей значения тумана для точек вокруг или перед камерой (то есть, в мировом пространстве или в пространстве камеры соответственно). Было опробовано однородное и неоднородное распределение точек сэмплирования, но aliasing был слишком плох, чтобы принять данный подход.
  Одно потенциально возможное расширение к расчётам общего влияния объёмов тумана на полупрозрачные объекты заключается в расчете значений для каждой угловой точки OBB объекта, и переход между ними в вертексном шейдере в соответствии с относительной позицией вертекса в этом ограничивающем объёме.

8. Мягкие частицы


Частицы обычно используются для отрисовки таких эффектов, как огонь, дым, облака, и т.п. К сожалению, на пользовательских картах, доступных сегодня, даже с включенным MSAA, они страдают от артефактов aliasing’а у пересечений с непрозрачной геометрией сцены. Имея значение глубины всех непрозрачных объектов в мире доступными во фрагментном шейдере, становиться возможным изменять значение прозрачности частицы попиксельно для того чтобы убрать “лесенки” пикселей, как показано в таблице ниже.
Изображение
Таблица 4. Сравнение билбордов и мягких частиц. Частицы отрисованные резкими билбордами. (слева) Мягкие частицы. (справа)

Каждая частица считается как объем с определённым размером, ориентированный к экрану. Для каждого фрагмента шейдер определяет, какое расстояние сквозь объём частицы проходит видовой луч, до того, как он достигнет непрозрачную поверхность геометрии сцены. Деля это значение на размер объема частицы, и ограничивая результат в диапазоне [0; 1], мы получаем процентное соотношение того, насколько геометрия сцены проникает в объём частицы для данного фрагмента. Оно может быть умножено на оригинальное значение альфы, рассчитанное для частицы в данном фрагменте, чтобы мягко убрать влияние частицы на финальный цвет, при приближении к непрозрачной геометрии.

Страницы: 1 2 3 4 Следующая »

#atmospheric crysis

22 октября 2007

Комментарии [7]