Screen space ambient occlusion что это
Как работает затенение в компьютерных играх
С появлением 3D-игр у их создателей серьезно прибавилось проблем: о сглаживании мы уже говорили, также мы говорили и о фильтрации текстур. Теперь же поговорим о еще одном эффекте, который позволяет серьезно улучшить реалистичность картинки — о Ambient Occlusion (AO), или о затенении.
В оптике можно выделить три простых градации освещенности — тень (источник света не виден), полутень (источник света виден частично) и освещенное место (источник света виден полностью). Казалось бы — все просто, рассчитать границы тени и полутени можно в два счета с помощью обыкновенных лучей. Однако полученная в результате картинка наводит на мысль, что мы где-то что-то забыли: 
Таких черных теней не бывает (ну на Земле по крайней мере), так что сразу становится очевидным, что мы забыли — рассеяние света: суть в том, что в реальном времени фотоны могут отражаться от различных поверхностей и в итоге попадать туда, куда напрямую фотоны от источника не долетают: именно поэтому в тени хоть и темнее, чем на свету, но не черным черно. На Земле таким «рассеивателем» фотонов выступает сама атмосфера.
Но тут возникает вопрос — а как это рассчитать-то? Увы — алгоритма, дающего 100% точное рассеяние света в real-time, нет, однако есть множество хорошо приближенных к реальности алгоритмов, отлаженных настолько, что они спокойно используются в видеоиграх.
Для начала — общая для всех алгоритмов теория: можно ввести так называемую среднюю освещенность всей сцены, своеобразную аппроксимацию непрямого освещения. Но вот проблема в том, что в местах, где есть тень, такая аппроксимация будет давать повышенную яркость. Поэтому можно несколько усложнить ее — снижать яркость в тех местах, куда отраженному свету труднее добраться. То есть для каждого фрагмента сцены мы находим так называемый заграждающий фактор: количество свободных «путей» для фотона деленное на все количество путей фотона до данного участка, и на основе этих данных и средней яркости сцены можно рассчитать яркость конкретного участка.
Однако тут мы получаем очередную проблему — отрисовка геометрии происходит постепенно, поэтому заграждающий фактор также в процессе отрисовки может серьезно меняться. Можно, конечно, рассчитать AO на этапе загрузки сцены, но тогда затенение не коснется динамических объектов (персонажей, машин и т.д.) — а это нехорошо. И тут приходит идея использовать для отрисовки затенения экранное пространство (Screen Space), что в итоге выливается в простейший алгоритм AO — SSAO.
SSAO
Этот алгоритм появился еще в Crysis 10 лет назад. Его суть проста: после построения геометрии у нас остается Z-буфер, или буфер глубины, который включает в себя абсолютно всю информацию о геометрии сцены — а значит никаких проблем сделать AO нет.
Хотя, конечно, кого я обманываю — проблемы есть, и самая серьезная — недостаточная производительность современных видеокарт: для того, чтобы получить более-менее неплохую карту затенения, для каждого фрагмента сцены нужно обсчитывать порядка 200-250 направлений, что позволяет «закопать» любой GPU. Поэтому делается хитрее — используется 8-32 «луча», направленные на выбранный фрагмент сцены, которые каждый раз поворачиваются на случайное значение. В итоге получается терпимое качество картинки с не очень большими затратами на расчеты:
В дальнейшем алгоритм был доработан — стали использоваться карты нормалей, что снизило сложность вдвое и позволило в итоге вдвое увеличить число выборок. Ну и финальный штрих — стали использовать размытие, дабы сгладить шум от случайных выборок.
HBAO и HBAO+
Nvidia не была бы Nvidia, если бы не стала развивать затенение дальше, представив в 2008 году HBAO — Horizon Based Ambient Occlusion. От SSAO это затенение отличалось тем, что оно основано на физической модели, где аппроксимируется интеграл освещенности фрагмента сцены со значениями выборки буфера глубины. Итоговое качество оказывается выше SSAO при большом числе выборок, но мы опять же упираемся в производительность. Поэтому HBAO рендерится обычно в более низком разрешении, что приводит к мерцанию картинки.
Проблема мерцания была исправлена в HBAO+ простым методом, который сейчас активно использует Sony в 4К играх на PlayStation 4 Pro: для рассчета HBAO+ используется шахматный рендеринг, то есть для обработки затенения используется часть предыдущего кадра и половина нового: это требует меньше затрат GPU, но при этом позволяет рендерить затенение в исходном разрешении, что и убирает мерцание.
HDAO
AMD в стороне не остались, и стали использовать собственное затенение (которое, к слову, также работает и на Nvidia) — HDAO (High Definition AO). Увы — AMD не делится алгоритмом, однако известно, что в его основе лежит Gather4 — технология, которая собирает 4 текселя в один регистр. То есть, как и с HBAO, по сути происходит рендеринг в пониженном разрешении. В итоге, в среднем картинка с HBAO и HDAO сравнима по качеству, но опять же — все достаточно сильно зависит от игры: к примеру, в Far Cry 3 с HDAO трава выглядит красивее:
На этом все. Советы для игроков простые: если компьютер хорошо тянет игру без AO, то можно попробовать включить SSAO или HBAO — обычно это снижает fps не более чем на 10%. Если же и с ними производительность отличная — можно попробовать HBAO+ и HDAO. Ну и для самых топовых видеокарт современности можно порекомендовать набирающее обороты VXAO — оно крайне требовательно к ресурсам (в том числе и к видеопамяти), поэтому даже в FHD оно будет доступно лишь пользователям старших Nvidia GTX 900ой и 1000ой линейки, а также владельцам старших AMD RX, Fury и Vega.
Screen space ambient occlusion с учетом нормалей и расчет одного отражения света.
В этой статье я расскажу, как я с нуля делал SSAO (Screen Space Ambient Occlusion — расчёт фонового освещения в экранном пространстве) с учетом нормалей. Сразу следует отметить, что это наиболее простая и прямолинейная реализация «в лоб», не претендующая на оптимальность или новизну. Статья будет полезна в первую очередь тем, кто имеет желание разобраться, как это работает.
Как-то захотелось мне поупражняться с графикой, и я решил сделать SSAO с нуля, опираясь на мои опыты с трассировкой лучей и на полученные ранее знания о том, как в целом это должно работать. В общем, поставил задачу написать к своему движку демку, с использованием всяких разных технологий. Решено было также поизучать deferred shading и screen-space local reflections, но об этом как-нибудь в другой раз. В этой статье сконцентрируюсь на SSAO.
Для самых нетерпеливых, вот результат:
1. Немного теории
Что нам говорит Википедия, по поводу ambient occlusion:
Получается, что нам нужно рассчитать, сколько света доходит до конкретной точки из полусферы, ориентированной по нормали в этой точке. Я даже как смог нарисовал в фотошопе картинку:
Сверху расположена камера, которая смотрит на нашу сцену.
Разными цветами показаны точки на объекте, их нормали и полусферы, по которым мы будем собирать затенение.
Точка, обозначенная фиолеовым ничем не затенена.
Точка, обозначенная желтым — затенена совсем чуть-чуть.
Точка, обозначенная голубым — затенена практически наполовину.
А вот точка на заднем объекте, обозначенная оранжевым, по идее, с точки зрения камеры частично перекрыта передним объектом, но так как она находится относительно далеко от объекта, то по факту передний объект эту точку не затеняет. С этим нам придется бороться отдельно, чтобы избежать неприятных артефактов в виде темных силуэтов объектов.
Таким образом, нам нужно рассчитать затенение для каждой точки, учитывая расстояние до объекта, который её перекрывает. Это и будет наш ambient occlusion.
Я решил в отличие от «традиционного» SSAO (например того, который, если я правильно помню, использоваться в первом Crysis) рассчитывать это не в screen space, а во view space. Минус этого подхода в большей сложности вычислений (хотя тоже, надо смотреть, проверять и сравнивать), плюс — в более точном AO.
2. Подготовка
Итак, для расчета ambient occlusion нам понадобятся две текстуры: глубины и нормалей.
Как я уже сказал, нормали будут во view space. Как сохранять и восстанавливать нормали — ваше дело, я, например, использую хитрую функцию, которая записывает нормаль в две компонеты. Подробнее об этом в последнем разделе «Ништяки». Пока, пускай у нас будут две функции в шейдере:
Выглядеть текстура с нормалями будет примерно вот так:
Текстура с глубиной у нас будет хранить «стандартную» глубину OpenGL.
Значения глубины, приведенные к интервалу [-1..1] и возведенные в 64-ю степень, у меня выглядят как-то так:
Но, так как мы будем использовать view space нам нужно будет восстанавливать положение точки во view space по глубине. О том, как это сделать смотрите в последнем разделе «Ништяки». Пока, пускай у нас будут четыре функции в шейдере:
Также, для того, чтобы придать разнообразия нашему расчету AO, нам понадобится текстура с шумом. Самая обычная текстура с шумом, я даже показывать её здесь не буду. В дополнение к этой текстуре нам специально для неё нужны будут текстурные координаты. Такие, чтобы текстура рисовалась на экране тексель в пиксель. По большому счету, это не обязательно, но очень желательно, чтобы выборки были «более случайными».
Итого, на входе во фрагментный шейдер у нас есть три текстуры и два набора текстурных координат.
Итого, кусочек шейдера у нас уже есть:
Теперь можно приступить непосредственно к расчету нашего затенения.
3. Расчет SSAO
Общая идея такова: в данной точке получить положение и нормаль, затем сгенерировать несколько случайных направлений на полусфере, заданой нормалью, и проверить затенения в них. Результат собрать и поделить на количество выборок. Таким образом мы хотим контролировать как минимум три параметрa:
1) количество выборок;
2) минимальное расстояние, на котором мы проверяем затенение (оно нужно нам, чтобы избавиться от некоторых неприятных артефактов);
3) максимальное расстояние, на котором мы проверяем затенение;
Вот пару картинок для сравнения параметров: количество выборок — чем больше, тем более плавное и красивое затенение у нас получается:
Максимальное расстояние — чем оно больше, тем «шире» и мягче у нас затенение:
Для тестовой сцены (Crytek Sponza) я использовал такие параметры:
К сожалению, мне пока не пришло в голову, как можно избавиться от этих параметров и вычислять их, исходя из того, что у нас есть на экране. Буду рад, если кто-то подскажет, куда двигаться в этом направлении.
Итак, у нас все есть для того, чтобы рассчитать затенение каждой точки на экране. Для начала нам нужно найти нормаль в этой точке и её положение (не забывайте, что мы работает во view space). Делается это просто чтением нормали из текстуры и восстановлением положения по глубине:
Теперь, чтобы не городить все в теле функции main(), заведем специальную функцию, которая рассчитывает затенение в данной точке. Я пафосно назвал её performRaytracingInViewSpace:
Ну, и собственно, чтобы не томить, остаток шейдера:
В результате у нас будет затенение данной точки. Если нужно освещение, мы просто вычитаем затенение из единицы:
То есть здесь мы просто подсовываем в эту функцию начальные параметры для текущей точки и некую псевдослучайную величину, которую мы потом обновляем (читаем из текстуры шума по новым координатам).
Таким образом, весь секрет у нас в функции расчета затенения. Давайте рассмотрим её поближе.
Здесь нам нужно сгенерировать случайное направление на полусфере, заданой нормалью в точке. Я это делаю очень просто: нормализую значение из текстуры шума, и если оно лежит в другой полуплоскости от нужной нам нормали, то умножаю на –1. Выглядит это вот так:
Так как нам нужна вся полусфера, и у нас нет какого-то предпочитаемого направления, то эта функция очень даже подходит. Если нужно делать выборки в некоем конусе — в движке есть функция для этого (могу показать, если сами не найдете).
Теперь у нас есть случайное направление, по которому мы будем делать выборку. Мы сдвигаем точку в этом направлении на случайную величину между MIN_SAMPLE_SIZE и SAMPLE_SIZE и проецируем её в screen space. После чего получаем некие новые текстурные координаты и глубину в интервале [0..1].
Далее, мы смотрим, какая глубина у нас находится по новым текстурным координатам, делаем новую выборку из текстуры глубины. Затем проверяем: если новая глубина оказалась больше, чем та, которую мы получили после проецирования, значит новая точка лежит дальше нашей и перекрывать её не может, перекрытия нет — возвращаем ноль из функции:
А дальше, когда мы определили, что новая точка лежит ближе к камере, чем наша спроецированная, начинается магия затенения. Что у нас есть на входе:
— глубина нашей спроецированной точки (которая гарантировано больше, чем новая глубина);
— глубина, которую мы получили после выборки (которая гарантирована меньше, чем глубина спроецированной точки).
Что нам нужно вычислить:
— насколько сильно объект (на точку которого мы наткнулись) перекрывает нашу исходную точку.
Что нам нужно учесть:
— чем ближе новая точка к спроецированной, тем сильнее перекрытие;
— если новая точка сильно «далеко» от спроецированной, тем меньше перекрытие.
Итого: нам надо сравнить две нелинейных глубины, которые, скорее всего, близки к единице. Можно еще раз восстановить линейную глубину, а можно сделать небольшой хак и получить значение, которое характеризует глубину. После некоторых экспериментов, я пришел к выводу, что функция вида
лучше всего подходит для получения такой оценки.
Итого, у нас есть два значения оценки глубины, возьмем между ними разницу, которая будет характеризовать расстояние одной точки от другой:
Так как мы хотим контролировать степень затенения, можем ввести некий коэффециент для этой разности. В финальном варианте получается так:
Для тестовой модели я использовал значение DEPTH_DIFFERENCE_SCALE равным 3.33333. Все зависит от масштабов того, что мы рисуем и на чём хотим вычислять затенение.
Теперь у нас есть расстояние между точками, давайте вычислим степень затенения. Опять таки, после многочисленных экспериментов, я пришел к выводу, что лучше всего описывает затенение функция вида:
Чтобы сделать его более мягким и приятным, еще можно учитывать расстояние, на которое мы делали выборку (приведенное к промежутку [0..1]). Итоговая формула выглядит вот так:
Вот как влияет масштаб расстояний (тот, который DEPTH_DIFFERENCE_SCALE)
При уменьшении расстояние (при DEPTH_DIFFERENCE_SCALE + Показать
В этой текстуре, как видно, хранится цвет, которые отражается от окружающих объектов. Воспользуемся:
На первый взгляд различий немного, но приглядитесь к правой картинке: освещение намного мягче, и на стенках есть небольшие отсветы от «штор». В общем, при минимальных затратах получилось использовать интересную технику.
5. Выводы
Итого, что у нас получилось:
1) рассчитать некое подобие глобального освещения, не передирая исходные коды шейдеров;
2) рассчитать первое отражение света с минимальными затратами и изменениями в алгоритме;
3) ну и наконец, разобраться в том, как это работает.
6. Ништяки
Как и обещал, в последней части я выкладываю куски кода:
Запись и восстановление нормалей (взято отсюда):
Восстановление положения во view space из глубины и проецирование обратно:
clipPlanes — это расстояние до ближней и дальней плоскости отсечения (то, что мы скармливаем в функцию установки перспективной проекции).
texCoordScales — компоненты обратной матриции проекции взятые со знаком минус.
Вообще, в демке много чего есть, кроме затенения и отражения света:
Ссылки по теме
Как я уже говорил в начале, данная реализация является самой простой и прямолинейной. Вот ссылки на некоторые другие техники, которые используются в играх:
Графика в играх: окклюзия, сглаживание, фильтрация — Как и с чем её едят
Приветствую всех Стопгеймеров! Давайте начистоту, вы ведь тоже заходите в только купленную игру, но сперва кликаете на графические настройки? Кто ради чего, кому-то ради самоутверждения надо глянуть на ультра-автонастройку благодаря своему мощному «железу», а кто-то просто лезет туда ради интереса.Однако, задумывались ли вы, чем отличаются FXAA и TXAA, или 8х и 16х анизотропная фильтрация? Как-раз в этом блоге, группа Abuse Reviews сейчас вам расскажет и покажет, что же это за фильтрации такие, как они работают и с чем их едят. Поехали!
P.S.
прошлом блоге количество материала в ролике было урезано, здесь эта ошибка была учтена, очень старался для вас.Приятного просмотра)
Давайте начнём с самого-самого простого
Разрешение экрана
Мало кто не знает, что разрешение — это количество отображаемых пикселей по горизонтали и вертикали. От этой настройки также зависит качество картинки и то, как сильно будут выражены «лесенки» в переходах между разными плоскостями\поверхностями. Но почему же возникает этот графический артефакт? Дело в том, что все графические элементы в играх состоят из пикселей, но таких проблем с прямыми линиями не происходит, но стоит только чуть её наклонить, как появляются «лесенки». Возникает это из-за отсутствия плавного перехода между цветами, которое обеспечивает сглаживание, вот о нём мы сейчас и поговорим.
Сглаживание
Самое главное его предназначение — борьба с теми самыми «ступеньками», которые все так не любят. Сглаживание обеспечивает нам плавный переход между цветами, за счёт чего изображение получается куда комфортнее, устраняя «ступеньки». Да, картинка однозначно становится красивой, но всегда приходится чем-то жертвовать, а именно производительностью. За счёт появления новой задачи, процессору и видеокарте приходится рендерить(обрабатывать) все эти дополнительные оттенки, которое даёт нам сглаживание. Но, к счастью, существует много видов сглаживания, которые предоставляют нам разработчики в настройках. Их то мы сейчас и рассмотрим:
Этот вид сглаживания не слишком сильно нагружает процессор, потому что он обрабатывает лишь те части кадра, которые выглядели бы неровными, а выбирает он эти части независимо от того, где и как они располагаются. Это самый быстрый и менее затратный в плане ресурсов метод сглаживания. Отличие от прошлого метода сглаживания заключается в нескольких аспектах. В первую очередь, FXAA применяется к изображению в том разрешении, в котором вы играете, также размывает картинку сильнее, что выглядит совсем не лучше, чем MSAA, зато расходует на порядок меньше ресурсов, из-за чего этот вид сглаживания почти не вредит вашему FPS
Пожалуй, это лучший вид сглаживания, который сильно похож на MSAA, но с некоторыми дополнениями. Дело в том, что TXAA учитывает и берёт в расчёт предыдущие кадры и сглаживает последующие путём усреднения цветов.
Да, это не вид сглаживания, но избавляется от лесенок этот способ довольно неплохо, но при одном условии, которое свойственно не каждому пк. Ведь не у всех есть 2\4К мониторы, которые позволяют увеличить разрешение больше 1920х1080. За счёт уменьшения пикселей «лесенки» остаются, но становятся куда меньше, однако это влияет на производительность больше всего из перечисленных способов. Так что этот метод подойдёт только обладателям мониторов с очень высоким разрешением и мощным железом. Забавно слушать легенды о том, что если поставить 2к или 4к разрешение в игре на FullHD мониторе, то картинка станет лучше. Решил я это проверить на примере GTA V и что-то не увидел разницы до и после, ни в фреймрейте, ни качестве. 
Проблем никогда не бывает мало. В этом случае нет никаких исключений, ведь кроме «ступенек» встречается такой артефакт, как разрыв картинки. Это происходит, когда ваши монитор и видеокарта пытаются работать синхронно, но по какой-то причине эти парни не могут этого сделать, причиной является частота кадров и частота обновления монитора. К примеру, вы находитесь в какой-то загруженной локации, а ваша видеокарта старается держать стабильную частоту, в то время как монитор обновляет изображение на одной и той же частоте. Если они не синхронизируются между собой, то как раз и появляется такой разрыв. И для решения этой проблемы предназначен следующий параметр:
Вертикальная синхронизация 
Этот параметр заставляет работать видеокарту на той же частоте, что и монитор, однако из-за этого возникают уже другие проблемы, к примеру, частота кадров может сильно падать из-за того что в игре появляется слишком много объектов, которые приходится обрабатывать. Но и для этой беды есть решение, которое называется — горизонтальная синхронизация. Принцип действия заключается в том, что модуль, встроенный в монитор заставляет экран обновляться сразу же при получении нового кадра, что способствует идеальному совпадению частот видеокарты и монитора. Благодаря всему этому, производительность компьютера не уменьшается, а монитор и видеокарта работают максимально слаженно.
На этом о проблемах картинки и артефактах — всё
Тесселяция
Тут стоит обратить внимание на контур головы 47-го
А вот она создана не для того чтобы исправлять косяки в картинке, а улучшать её и делать более насыщенной и реалистичной. Многие из нас знают, что 3д-объекты в играх состоят из полигонов (мелких частиц). Тесселяция подразумевает разбиение полигонов на более мелкие части, чтобы генерировать больше деталей у объекта. Это особенно удобно для выделения высоты и глубины объектов. Также она способствует созданию более закругленных объектов без острых форм и углов.
Окклюзия окружения (Ambient Occlusion)
Лично я занимаюсь созданием 3д-моделей в Cinema 4D и довольно хорошо знаком с этой фичей. 
Она позволяет создавать искусственные тени, таким образом, в идеале, геймдизайнеры и создатели 3д-анимаций предпочитают использовать движки, поддерживающие функцию глобального освещения, которое позволяет создавать освещение идентичное реальному, а всё благодаря вычислениям точных оттенков каждого из пикселей, в зависимости от общего количества света, попадаемого на него. Знаю, что звучит это сложновато, но как же это преобразовывает картинку… словами не описать. Такое освещение очень подходит для различных кинематографичных сцен в мультфильмах или кат-сцен в играх, но это оказывает очень сильную нагрузку на железо, но на то у нас и есть окклюзия окружения, которая создаёт искусственные тени там, где они должны располагаться.
Для начала стоит разобраться с освещением в играх. В них источником света является естественное освещение, которое является упрощённой версией глобального освещения, где расположение теней зависит от того, есть ли перед источником естественного освещения какое-либо препятствие, но это даёт нам более плоские тени в меньшем количестве, чем хотелось бы. Тут и наступает триумф окклюзии окружения, ведь она определяет расположение дополнительных теней с поммощью трассировки лучшей, а именно вычисляет, сколько солнечных лучшей блокируется рядом со стоящими объектами. То есть, если один объект загораживает другой, то поверхность второго объекта, разумеется, будет находиться в тени. Впадины, углубления и тому подобное начинает больше выделяться с помощью окклюзии.В огромном большинстве случаев этот параметр уже «вшит» в графические настройки, что не позволяет включать и выключать его. Но это всё окклюзия окружения в общем. Наверняка вы все сталкивались с такими параметрами освещения как SSAO,HBAO и HDAO?
Она взяла своё начало со времён первого Crysis, благодаря компании Crytek, по-сути оно заключается в вычислении глубины каждого пикселя и пытается вычислить количество преград от каждой из выбранных точек. Алгоритм SSAO призван упростить вычислительную сложность алгоритма Ambient occlusion и сделать его подходящим для работы на графических процессорах в режиме реального времени. Вместе с тем качество результирующего изображения у SSAO является худшим, чем в первоначальном Ambient occlusion, так как SSAO использует упрощённые методики рендеринга(обработки изображения).
Имеет тот же принцип работы, что и SSAO но несколько усовершенствованный. Просто вычисления глубины производятся с большим числом выборок, но приходится жертвовать производительностью.
Одно основывается на другом. Таким же образом как SSAO отличается от HBAO, HDAO от HBAO отличается точно тем же, ну и ещё эта окклюзия была представлена нам компанией AMD.
Ну а что по кинематографичности?
Глубина резкости
Неплохо так нагружает вашу систему, но и так же неплохо придаёт картинке кинематографичности, а всё благодаря фокусу на конкретных объектах, благодаря чему, остальные объекты размываются. Но это может привнести неудобства, как например при игре в PUBG, во время выглядывания из окна (ну вы знаете, когда упираешься лицом в стену как идиот и видишь всё что происходит за ней) иногда замыливается вид в окне, а фокус идёт на стену или оконную раму. Очень раздражает. Однако кинематографичность, опять же, дарит нам положительные впечатления об игре.
Ну и последнее о чём хотелось бы рассказать
Анизотропная фильтрация
А вот этот параметр уж точно видел каждый, но далеко не все понимают как это работает. Объясню быстро и просто. Во имя сохранения FPS разработчики используют нехитрый трюк с понижением качества текстур и моделей по мере отдаления от них. Зачастую мы можем наблюдать размытие текстуры пола вдали от себя, но если мы включим фильтрацию, то границы между различными уровнями детализации размываются. Плюс такой фильтрации в том, что вы можете со спокойной душой ставить значение 16х, ведь этот параметр почти не оказывает давления на процессор и видеокарту.
Ну а на этом всё. Если вам понравился этот блог и вы узнали что-то новое, обязательно жмите на плюс, а также интересно узнать, нравится ли вам качество видеоформата, если вы его глянули? Большое спасибо вам за внимание, всем удачных каток и стабильного FPS!