Объемный туман в играх что это

Fog (Туман)

Описание

Эффект тумана зависит от трех основных компонент:
1. Цвет тумана (C).
2. Плотность (g).
3. Расстояние (d).

Поскольку объекты находящиеся в дали должны больше поддаваться эффекту тумана, ввели коэффициент d, т.е. расстояние. Окончательный цвет вершины получают интерполированием цвета тумана и текущем цветом: Lerp(Cfog, Ccurrent, f)

Вычислять Cfinal надо только в том случае, если вы используете пиксельный шейдер:

Иначе это сделает за нас direct3d9 установкой следующих стейтов:

или с помощью OpenGL:

Линейный туман

Основное уравнение:
f = (Zfogend – d)/(Zfogend – Zfogstart)
В таком случае частицы тумана распределяются равномерно от точки Zfogstart и до точки Zfogend. d – представляет глубину, или расстояние от видового вектора до начала появления тумана. Вот простенький шейдер для линейного тумана:

Стоит уделить внимание строчке:

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

Второй способ состоит в вычислении расстояния между позицией вершины и видовым вектором:

Экспоненциальный (квадратичный) туман

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

Основное уравнение для экспоненциального тумана:
f = exp(-d*g)
для экспоненциального квадратичного тумана:
f = exp(-(d*g)*(d*g) )

Источник

Туман в Lost in Random

Взгляд изнутри.

В процессе разработки Lost in Random наши художники часто публиковали концепт-арты и другие изображения, позволявшие взглянуть за кулисы создания игры. Кто-то из нас задался вопросом, можно ли сделать что-то подобное и для кода. Хотя в то время ситуация была довольно суматошной, мне понравилась эта идея, ведь я сам люблю изучать внутреннее устройство любимых игр. Я захотел написать техническую статью о том, над чем работал в то время. Год спустя игра была завершена и у меня появилось немного времени на написание краткой статьи об особенно интересном визуальном эффекте и о том, как он помогает в создании внешнего вида нашей игры.

… на внешний вид Random

Lost in Random обладает собственным визуальным стилем. При его создании мы приложили много сил и умений. Когда я пришёл в Zoink на должность программиста графики, визуальная составляющая и окружения игры уже проделали довольно долгий путь. Моя задача заключалась в том, чтобы взять имеющееся и помочь превратить проект в игру, способную работать на целевых платформах. Быстрая разработка с учётом первоначального видения игры была довольно сложной задачей.

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

Один и тот же вид с туманом и без него.

Изначально в проекте использовался High Definition Render Pipeline (HDRP) движка Unity и его встроенный объёмный туман (Volumetric Fog). Они выглядят абсолютно потрясающе, но эти технологии оказались слишком вычислительно затратными для нескольких целевых платформ. Как и ожидалось, самая серьёзная проблема возникла с Nintendo Switch. Switch — замечательная платформа, как геймеру она нравится мне больше всех. К сожалению, оборудование её не такое уж мощное.

Потратив пару месяцев на тестирование различных опций и исследование внутренностей рендереров Unity, мы решили отказаться от HDRP в пользу более простого, но и более производительного Universal Render Pipeline (URP) для всех платформ. Хоть нас и волновало снижение реалистичности освещения, руководству проекта понравился более мультяшный стиль, который создавался упрощённым освещением. Разумеется, это означало, что теперь мы не могли пользоваться туманом HDRP. Поначалу я пробовал портировать этот туман в URP, но это оказалось хлопотной задачей, не оправдывающей усилий.

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

Объёмный туман

Объёмный туман, использовавшийся на мощных платформах, был модифицированной версией Aura 2 — ассета, разработанного Oniric Studio. С технической точки зрения этот ассет очень похож на встроенный в HDRP, но нашим художникам оказалось проще его настраивать нужным им образом. Достаточно было только конвертировать его под URP и добавить функции, которых нам не хватало.

Самым масштабным изменением в Aura 2 стало добавление угасания прямого освещения, присутствующего в тумане HDRP. Оно приглушает солнечный свет, когда игрок углубляется в туман. На скриншотах ниже показан один и тот же вид со включенной и выключенной функцией.

Тума с затуханием прямого освещения и без него.

Этот эффект стал одним из множества изменений, внесённых нами в шейдер Lit. Мы скопировали его из угасания по высоте в LightEvaluation.hlsl конвейера HDRP, которое я перенёс в Lighting.hlsl конвейера URP. Необходимо было только добавить код для нашего менеджера объёмов тумана, чтобы он собирал и усреднял параметры угасания от всех текущих активных объёмов тумана.

Туман в экранном пространстве

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

Туман состоит из трёх слоёв: нижнего, верхнего и слоя скайбокса. Каждый слой имеет собственную высоту, цвет и плотность. Всё, что находится дальше заданного расстояния от камеры и выше высоты скайбокса, использует описанную выше экспоненциальную функцию, применяемую к цвету слоя скайбока. Для всего остального мы вычисляем часть глубины обзора, пересекающуюся между нижней и верхней высоты, и используем её для вычисления видимой высоты в тумане. Затем мы используем нечто напоминающее smoothstep(LowerHeight, UpperHeight, viewHeight) для вычисления обратной величины линейной интерполяции между нижней и верхней высотами, а затем применяем получившееся значение как параметр линейной интерполяции между нижними и верхними цветами. Так туман становится градиентом между этими двумя значениями.

Существует два способа вычисления высоты обзора. Стандартный просто берёт высоту, которая достигнута следованием по лучу длины depth из позиции камеры и через центр пикселя. Это означает, что цветовой градиент между нижней и верхней высотами чётко заметен на небе при большинстве углов обзора. Ещё один способ — вычисление средней высоты, на которую переместился луч. Это придаёт более мягкий внешний вид. Я сложил эти два способа, потому что не был точно уверен, какой конкретно способ имел в виду наш художник, когда объяснял мне требуемый результат. Я подумал, что надо позволить ему протестировать оба способа и убрать «лишний». После тщательного тестирования и сравнения мне сообщили, что нужны оба способа. На самом деле, в некоторых сценах для более динамичного внешнего вида используются объёмы тумана, сочетающие в себе оба способа.

Три режима

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

Наш туман в экранном пространстве также поддерживает упомянутое выше затухание освещения. Это означает, что менеджер подает в шейдер Lit те же данные, что и наша модифицированная версия Aura 2. На самом деле, он не влияет на сам шейдер тумана. Там есть и другие тонкости (например, способ смешения солнечного света с цветом тумана), но в целом это довольно простой шейдер, рассчитанный на создание хорошей картинки без необходимости любой иной информации, кроме как позиции камеры и глубины рендеринга.

Клочья тумана

Моя любимая «фишка» тумана стала счастливой случайностью, используемой только в версии для экранного пространства. Вдоль верхней части объёмов тумана, растянувшихся над землёй, есть анимированная текстура с проплывающими клочьями тумана. При первой реализации этих объёмов я добавил простой шум, чтобы край тумана выглядел слегка нечётким, а не как параллелепипед с ровными краями. Также я сделал его анимированным, чтобы паттерны шума были чуть менее заметными. Позже по просьбе нашего потрясающего художника по окружениям Лео Бриниелссона я заменил функцию шума на текстуру. Я решил, что он просто хочет подобрать собственную функцию шума, не заставляя меня вносить изменения в код. Однако он использовал её, чтобы создать вот это:

Клочья тумана в версии Lost in Random для Switch.

Да здравствует Random!

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

Об авторе

Меня зовут Дэниел «Agentlien» Квик, я разработчик ПО, страстно влюблённый в игры. Сейчас я работаю программистом графики в Thunderful Development над Lost in Random.

Источник

Как добавить эффект тумана и избежать неестественных границ на пересечениях с объектами: опыт авторов Blightbound Статьи редакции

Для реализации этой особенности применяется техника depth fade.

Сооснователь студии Ronimo Games (Awesomenauts) Йост ван Донген опубликовал на сайте Gamasutra текст с описанием принципов техники depth fade, которая позволяет добавить эффект тумана в игру и избежать очевидных границ в местах пересечения с объектами. Также он показал несколько дополнительных примеров использования этой техники в Blightbound. Мы выбрали из текста главное.

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

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

Чтобы решить эту проблему, Донген применил технику depth fade, которая обычно используется для мягких частиц, но имеет и другие области применения. Идея техники состоит в том, чтобы в области пересечения полупрозрачная плоскость стала ещё более прозрачной. Благодаря этому возникает эффект, который по принципу своей работы похож на настоящий туман, так как объекты плавно исчезают в дымке.

Хитрость рендеринга с depth fade заключается в том, чтобы сначала идёт визуализация обычной геометрии — туда не входят прозрачные и полупрозрачные объекты. Это необходимо для «заполнения» буфера глубины (Z-buffer, depth buffer) — благодаря ему игра знает, как далеко от камеры находится каждый пиксель.

Затем при рендеринге объектов с depth fade пиксельный шейдер оценивает расстояние в буфере глубины и сравнивает его со своими показателями. Это помогает определить, насколько близко пиксели находятся к области пересечения объекта и плоскости тумана: чем ближе, тем выше прозрачность. Усиление прозрачности происходит до того момента, пока плоскость тумана не станет полностью невидимой в точке пересечения.

У этой техники есть ещё несколько интересных применений. Если изменить расстояние действия эффекта, то можно легко менять плотность тумана. Кроме того, объекты не должны фактически пересекаться с плоскостью тумана для применения depth fade — они могут располагаться и под ней.

Источник

Как настроить графику в играх, чтобы компьютер не тормозил

И сохранить приличный вид локаций

Современные видеоигры становятся красивее, реалистичнее и… тяжелее.

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

Что вы узнаете из этого материала

Почему игра может тормозить

Производительность в видеоиграх принято мерить значениями FPS — frames per second. Это кадровая частота, то есть количество кадров в секунду. Чем выше FPS, тем плавнее картинка.

Во время игры значения FPS меняются: если нагрузка на компьютер увеличивается в более сложной игровой сцене, количество кадров в секунду падает. Человеческий глаз улавливает малейшие изменения в кадровой частоте: резкое снижение уровня мы воспринимаем как те самые «тормоза».

Объясню на примере. Предположим, вы исследуете игровой уровень, в котором ничего не происходит, — FPS стабильно высокая. Затем начинается динамичная сцена с кучей спецэффектов, и кадровая частота падает, потому что нагрузка на ПК резко повышается. Действие на экране становится более рваным и дерганным, это раздражает.

Чтобы избежать торможения, в играх принято ограничивать «потолок» FPS, даже если компьютер может время от времени выдавать более высокие значения. Глаз привыкает к определенной частоте кадров, поэтому низкая, но стабильная FPS приятнее, чем «плавающая».

Добиться стабильной FPS можно двумя способами: либо занизить настройки графики так, чтобы компьютер с легкостью выдавал 60 FPS, либо сделать их умеренно средними или даже высокими — но выставить ограничение в 30 FPS. В первом случае изображение будет плавным, но не слишком подробным, а во втором — более детализированным и четким, но одновременно и более дерганным.

негласный стандарт для количества кадров в секунду. Если игра ну очень требовательная, достаточно стабильных 30 FPS

Чем мощнее машина, тем больше FPS она успевает обрабатывать. Но требования игр растут с каждым годом: компьютеры, которые были самыми мощными несколько лет назад, уже не так хорошо работают с современным геймплеем. К примеру, на топовом для 2014 года ПК (i7 4770k, GTX 980, 16 ГБ ОЗУ) недавняя Cyberpunk 2077 может тормозить: чтобы этого избежать, игроку придется повозиться с настройками графики, которые позволят увеличить производительность.

30 FPS достаточно, если вы играете в сюжетную или кинематографичную игру: качество изображения будет выше, а игровой процесс не пострадает. Но некоторые игры рассчитаны минимум на 60 FPS — например, многопользовательские шутеры Counter-Strike или Call of Duty, где важна скорость реакции.

Выше 60 кадров в секунду поднимать графику нет смысла: большинство мониторов просто не смогут воспроизвести FPS выше. Дело в том, что у каждого дисплея есть еще и частота обновления экрана, которая зачастую равна 60 Гц: это означает, что картинка на дисплее обновляется 60 раз в секунду. Соответственно, если кадровая частота окажется выше частоты обновления экрана, на мониторе попросту не будет видно разницы.

Одни настройки графики ресурсоемкие, а другие — не очень. Более того, занижение некоторых параметров может практически не сказаться на качестве картинки, но убрать пресловутые «тормоза».

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

Ниже я перечислил самые распространенные настройки графики в порядке их влияния на качество графики. Параметры с припиской «Без потерь» обычно высвобождают немало FPS, но картинку портят не сильно. А там, где указано «С заметными потерями» или «Выжать еще чуть-чуть», придется пойти на компромиссы.

Важно помнить, что советы могут подойти не для всех игр: в разных проектах графика работает по-разному. Эффект от смены параметров может оказаться как слабее, так и значительно сильнее. Чтобы быть точно уверенным в результате и не тратить много времени на настройку, можно воспользоваться специальным гайдом для конкретной игры — например, для Cyberpunk 2077.

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

Источник

Game Engine своими руками #9: Туман

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

В играх туман появился не от хорошей жизни.
С indoor-окружениями (Doom, Quake etc.) все было просто
и радужно, а вот с открытыми пространствами
возникали заморочки. Дело в том, что железо
прошлого было не в состоянии нарисовать
огромные открытые пространства с кучей
полигонов, поэтому пришлось неизбежно
укоротить видимую дистанцию, т.е.
придвинуть линию горизонта чуть ли не
вплотную. Само собой, этот непростительный
поступок нужно было скрыть от всех и вся,
так вот и пришла в чью-то светлую голову
идея закрыть горизонт слоем непрозрачного
тумана. Апогей сей новаторской мысли, можно
было созерцать в нинтендовском Turok’e, в
котором за туманом даже своего ствола
бывало не видно.

Такой вот вездесущий туман называется
пиксельным туманом (pixel fog, иногда
встречается название distance fog), он
распространяется на все объекты сцены и
реализуется с помощью несложного алгоритма,
который использует значения z-буфера в
линейной (часто) или экспоненциальной (редко)
функции для вычисления цвета пикселя. Для
того чтобы быстро определить нужную
цветовую составляющую вносимую туманом в
цвет пикселя, иногда прибегают к помощи
заранее рассчитанных таблиц тумана (fog tables).
Несмотря на свою примитивность, pixel fog
используется и по сей день во многих
современных игрушках.

В следующих двух примерах я покажу, как
инициализировать такой туман в OpenGL и DirectX
приложениях:

// OpenGL
//
void SetupPixelFog (float Color[4], int Mode)
<
float Start = 4.0f, // для линейного тумана
End = 1000.f,
Density = 0.66; // для экспоненциального

// разрешаем использование тумана
glEnable (GL_FOG);

// устанавливаем цвет
glFogfv(GL_FOG_COLOR, Color);

// устанавливаем параметры
if (Mode == GL_LINEAR) <
glFogi(GL_FOG_MODE, GL_LINEAR);
glFogf(GL_FOG_START, Start);
glFogf(GL_FOG_END, End);
>
else
<
glFogi(GL_FOG_MODE, Mode);
glFogf(GL_FOG_DENSITY, Density);
>
>

// разрешаем туман
g_pDevice->SetRenderState(D3DRS_FOGENABLE, TRUE);

// устанавливаем цвет тумана
g_pDevice->SetRenderState(D3DRS_FOGCOLOR, Color);

// устанавливаем параметры
if (Mode == D3DFOG_LINEAR)
<
g_pDevice->SetRenderState(D3DRS_FOGTABLEMODE, Mode);
g_pDevice->SetRenderState(D3DRS_FOGSTART, *(DWORD *)(&Start));
g_pDevice->SetRenderState(D3DRS_FOGEND, *(DWORD *)(&End));
>
else
<
g_pDevice->SetRenderState(D3DRS_FOGTABLEMODE, Mode);
g_pDevice->SetRenderState(D3DRS_FOGDENSITY, *(DWORD *)(&Density));
>
>

Как видишь, все довольно просто, но не все
так хорошо как кажется на первый взгляд. Во-первых,
pixel fog выглядит довольно убого и вряд ли
намного приукрасит твой движок, а во-вторых,
при расчетах pixel fog’а используются значения
z-буфера, которые есть не что иное, как длина
перпендикуляра опущенного из
соответствующей точки 3D-сцены на плоскость
проекции, хотя на самом деле, очевидно, цвет
тумана зависит от расстояния между
фрагментом и глазом наблюдателя. В восьмом
DirectX это было учтено, и система
автоматически использует глазо-релевантные
значения глубины вместо значений z-буфера,
если имеется такая возможность.

Позже, когда железо стало мощнее, кому-то
захотелось, чтобы туман заполнял не все
пространство 3D-сцены, а небольшую его часть,
например, стелился по полу какой-нибудь
комнаты. Так возникло понятие «объемный
туман» (volumetric fog), т.е. туман, заключенный в
какой-то конечный объем.

Первые попытки были очень неловкими и
напоминали, скорее, пародию, нежели,
действительно объемный туман. Так, кажется,
в третьем Tomb Raider’е можно увидеть туман,
выполненный в виде нескольких слоев
полупрозрачной текстуры расположенных
параллельно полу.

После эпохи «туманного застоя»
появился Анрыл, который и принес в массы
шикарно выглядящий объемный туман. Затем
вышел третий Квак, после которого стало
ясно, что отныне наличие объемного тумана в
FPS-играх стало не роскошью, а правилом
хорошего тона.

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

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

Источник