Что такое качество ssao
Normal-oriented Hemisphere SSAO для чайников
Привет, хабрапользователь! После небольшого перерыва можно опять браться за трехмерную графику. В этот раз мы поговорим о таком алгоритме глобального затенения, как Normal-oriented Hemisphere SSAO. Интересно? Под кат!
Но сначала чуть-чуть новостей
Я отказался от использования XNA, мощностей DX9 мне стало не хватать: конечно, в целом ничего не поменялось, но написание кода стало куда менее костыльным. Все последующие примеры будут реализованы с помощью фреймворка SharpDX.Toolkit: не пугайтесь, это духовный наследник XNA, еще и OpenSource и с поддержкой DX11.
Классически — теории
Самой важной частью в графическом движке любой игры (которая имеет претензии на реалистичность) — это освещение. Сейчас невозможно полностью смоделировать освещение в игре real-time так, как это происходит в нашем, реальном мире. Условно говоря, не в real-time приложениях: освещение считается “пусканием” фотонов из источника света в нужных направлениях и регистрации этих фотонов камерой (глазом). Для подобных процессов в реальном времени требуется апромиксация, например: у нас есть некоторая поверхность и источник света, и для того что-бы создать освещение – требуется рассчитать “освещенность” каждого пикселя принадлежащей поверхности, т.е. учитывается только прямое влияние источника света на тексель. В данной апромиксации не учитывается непрямое освещение, т.е. в случае с real-time фотон может отразиться от какой-либо поверхности и повлиять на совершено другой “тексель”. Для единичных, небольших источников света это не особо критично, но стоит взять большой источник света и “бесконечно удаленный”, например, солнце (небо выступает как мощный «рассеиватель» света от солнца), то сразу возникают проблемы, примерно такие:
В реальном же мире, на подобной сцене не было бы такой черной черноты в местах теней. Развивая дальше тему, можно ввести некоторое значение ambient, которое будет отображать общую освещенность всей сцены, своеобразная аппроксимация непрямого освещения. Но дело в том, что подобное освещение на всей сцене везде одинаково, даже в тех местах, где непрямой свет будет оказывать наименьшее влияние. Но и тут можно схитрить и усложнить апромиксацию путем затенения тех участков, куда отраженному свету сложнее всего добраться. Таким образом мы подошли к понятию называемым “глобальное затенение” (ambient occlusion). Суть такого подхода заключается в том, что мы для каждого фрагменты сцены находим некоторый заграждающий фактор, т.е. кол-во не загражденных направлений падения “фотона” деленное на общее кол-во всевозможных направлений.
Рассмотрим следующую картинку:
Тут у нас есть две рассматриваемые точки, которые образуют вокруг себя окружность с радиусом R. И для того, чтобы определить степень загражденности взятого фрагмента достаточно найти площадь незагражденного пространства и разделить на общую площадь окружности. Если мы подобную операцию проделаем для всех точек сцены – мы получим глобальное затенение. Выглядеть оно будет примерно так (для трехмерного случая):
Но теперь нужно подумать, как подобный алгоритм внедрить в пайп-лайн рендера графического конвейера. Сложность возникает в том, что отрисовка геометрии происходит постепенно. В следствии чего, первый объект в сцене не будет знать о существовании других. Можно, конечно, заранее рассчитать AO (на этапе загрузки) для сцены, но в таком случае мы не будем учитывать динамически изменяемую геометрию: физические объекты, персонажей, etc. И тут на помощь приходит работа с геометрией в экранном пространстве (Screen Space). Я его уже упоминал, когда рассказывал об SSLR-алгоритме. Этим можно воспользоваться и считать AO в экранном пространстве. Тут появляется самая классическая реализация SSAO, придумали его классные ребята из крайтек ровно 8 лет назад. Их алгоритм заключался в следующем: после рисования всей геометрии у них был в наличии буфер глубины, который несет в себе информацию об всей видимой геометрии, строя сферы для каждого текселя они считали кол-во затенения для сцены:
Тут, кстати, возникает еще одна сложность. Дело в том, что мы не можем учесть абсолютно все направления в real-time, во первых, потому, что пространство дискретно, а во вторых на производительности можно ставить крест. Мы не можем учесть даже 250 направлений (а именно столько необходимо для минимально-вменяемого качества изображения). Для того, чтобы сократить кол-во выборок – используют некоторое ядро направлений (от 8 до 32), которое вращают каждый раз на случайное значение. После этих операций нам доступен AO в реал-тайме:
Самое тяжелое в алгоритме SSAO это определение заграждения, ведь это чтение из float-текстуры.
Чуть позже была придумана модификация алгоритма SSAO: Normal-oriented Hemisphere SSAO. Суть модификации в том, что мы можем увеличить точность алгоритма за счет учета нормалей (по сути нужен GBuffer). Для пространства выборок мы будем использовать не сферу, а полусферу, которая ориентирована по нормали текущего текселя. Такой подход позволяет увеличить кол-во полезных выборок в двое.
Если посмотреть на рисунок, то можно понять, о чем я говорю:
Завершающим этапом алгоритма будет размытие изображения AO для того, чтобы убрать шум, вызванным случайными выборками. В конечном счете – реализация нашего алгоритма будет выглядеть так:
С теорией пока все ясно, можно перейти к практике.
Зона, свободная от теории
Советую прочитать эту статью, там я рассказывал про суть работы Screen Space пространством. Но, а в практике я приведу особо важные участки кода с нужными комментариями.
Самое первое, что нам понадобится, это информация о геометрии: GBuffer. Т.к. его построение не входит в тему статьи – о нем подробно расскажу как-нибудь в другой раз.
Второе — это полусфера со случайными направлениями:
Тут важно отметить, что в шейдере у нас не будет трассировки, т.к. мы сильно ограничены в инструкциях, взамен этому – мы будем считать факт нахождения конечной точки в какой-либо геометрии, поэтому необходимо учитывать больше ближней геометрии, чем дальней. Для этого достаточно взять набор точек с нормальным распределением в полусфере. Это можно получить честным нормальным распределением, можно просто дважды умножить вектор на случайное число от 0 до 1, а можно воспользоваться небольшим хаком: задавать длину какой-либо функцией, например квадратичной. Это нам даст более лучший “сорт” ядра.
Третье – это набор каких-нибудь случайных векторов, для того, чтобы разнообразить конечные выборки, у меня оно генерируется в случайным образом:
Но выглядит оно примерно так:
Не стоит использовать подобную текстуру больше чем 4×4-8×8, потому, что подобное вращение ядра дает низкочастотный шум, который размыть в будущем куда проще.
Теперь поглядим на тело шейдера SSAO:
Тут мы получаем нелинейную глубину, получаем мировую позицию и нормаль, получаем набор случайных векторов растянутых на весь экран. Стоит сразу заранее сказать про два хака.
Первый заключается в том, что мы сдвигаем позицию текселя на нормаль умноженную на некоторое маленькое значение, это необходимо для того, чтобы избавится от ненужных пересечений из-за дискретности screen space пространства:
А второй заключается в том, что в алгоритме нам необходимо сравнивать значения глубины, а нелинейная глубина на средних-дальних дистанциях находится в окрестностях единицы. По-хорошему мы должны эту глубину линеализировать, но т.к. подобные значения используются только для сравнения – можно ввести некоторое оценку нелинейной глубины:
Отдельно стоит сказать, что хорошо бы сделать unroll-цикла, т.к. кол-во выборок заранее известно, подобный код будет работать быстрее.
Дальше начинается сам алгоритм:
Вращаем ядро и ориентируем это ядро по нормали в текстеле:
И передаем функции расчета заграждения:
Берем сэмпл и проектируем его в экранное пространство (получаем новые значения UV.xy и нелинейную глубину):
Функция проекции выглядит следующим образом:
Константы 0.5f напрашиваются, чтобы их зашили в матричку.
После этого мы получаем новое значение глубины:
Факт заграждения мы определяем как: “видна ли точка наблюдателю”, т.е. если точка не лежит в какой-либо геометрии – то assessReaded будет всегда строго меньше assessProjected.
Ну и с учетом того, что в экранном пространстве полно такого явления как information lost, мы должны регулировать кол-во затенения в зависимости от дистанции “проникновения” в геометрию. Это необходимо для того, что мы ничего не знаем о геометрии за видимой частью экранного пространства:
Ну и финальный этап, это размытие. Я лишь скажу то, что нельзя размывать буффер SSAO без учета неоднородности глубины как это делают многие. Так же, хорошо бы учесть и нормали при размытии, примерно так:
Коэффициенты depthFactor и normalFactor учитываются в коэффициентах размытия.
Взамен заключения
Для более подробного изучения – я оставлю полный исходный код тут, а для любителей увидеть своим глазом демо тут.
Кстати, в демо я намерено оставил NORMAL_BIAS равным нулю, чтобы увидеть проблему, кроме того, в GBuffer рисуется только геометрия и нет normal-маппинга, из-за чего на дальних дистанциях происходит z-fighting.
В будущих статьях постараюсь осветить другие алгоритмы real-time ao, такие как HBAO, HDAO, HBAO+, если будет интересен к этой теме, конечно.
Что такое качество ssao
Думаю, с понятием разрешения знакомы уже более-менее все игроки, но на всякий случай вспомним основы. Все же, пожалуй, главный параметр графики в играх.
Изображение, которое вы видите на экране, состоит из пикселей. Разрешение — это количество пикселей в строке, где первое число — их количество по горизонтали, второе — по вертикали. В Full HD эти числа — 1920 и 1080 соответственно. Чем выше разрешение, тем из большего количества пикселей состоит изображение, а значит, тем оно четче и детализированнее.
Влияние на производительность
Очень большое.Увеличение разрешения существенно снижает производительность. Именно поэтому, например, даже топовая RTX 2080 TI неспособна выдать 60 кадров в 4K в некоторых играх, хотя в том же Full HD счетчик с запасом переваливает за 100. Снижение разрешения — один из главных способов поднять FPS. Правда, и картинка станет ощутимо хуже.
В некоторых играх (например, в Titanfall) есть параметр так называемого динамического разрешения. Если включить его, то игра будет в реальном времени автоматически менять разрешение, чтобы добиться заданной вами частоты кадров.
Вертикальная синхронизация
Если частота кадров в игре существенно превосходит частоту развертки монитора, на экране могут появляться так называемые разрывы изображения. Возникают они потому, что видеокарта отправляет на монитор больше кадров, чем тот может показать за единицу времени, а потому картинка рендерится словно «кусками».
Вертикальная синхронизация исправляет эту проблему. Это синхронизация частоты кадров игры с частотой развертки монитора. То если максимум вашего монитора — 60 герц, игра не будет работать с частотой выше 60 кадров в секунду и так далее.
Есть и еще одно полезное свойство этой опции — она помогает снизить нагрузку на «железо» — вместо 200 потенциальных кадров ваша видеокарта будет отрисовывать всего 60, а значит, загружаться не на полную и греться гораздо меньше.
Впрочем, есть у Vsync и недостатки. Главная — очень заметный «инпут-лаг», задержка между вашими командами (например, движениями мыши) и их отображением в игре.
Поэтому играть со включенной вертикальной синхронизацией в мультипеере противопоказано. Кроме того, если ваш компьютер «тянет» игру при частоте ниже, чем заветные 60 FPS, Vsync может автоматически «лочиться» уже на 30 FPS, что приведет к неслабым таким лагам.
Лучший способ бороться с разрывами изображения на сегодняшний день — купить монитор с поддержкой G-Sync или FreeSync и соответствующую видеокарту Nvidia или AMD. Ни разрывов, ни инпут-лага.
Влияние на производительность
В общем и целом — никакого.
Сглаживание(Anti-aliasing)
Если нарисовать из квадратных по своей природе пикселей ровную линию, она получится не гладкой, а с так называемыми «лесенками». Особенно эти лесенки заметны при низких разрешениях. Чтобы устранить этот неприятный дефект и сделать изображения более четким и гладким, и нужно сглаживание.
Здесь и далее — слева изображение с отключенной графической опцией (или установленной на низком значении), справа — с включенной (или установленной на максимальном значении).
Технологий сглаживания несколько, вот основные:
Влияние на производительность
От ничтожного (FXAA) до колоссального (SSAA). В среднем — умеренное.
Качество текстур
Один из самых важных параметров в настройках игры. Поверхности всех предметов во всех современных трехмерных играх покрыты текстурами, а потому чем выше их качество и разрешение — тем четче, реалистичнее картинка. Даже самая красивая игра с ультра-низкими текстурами превратится в фестиваль мыловарения.
Влияние на производительность
Если в видеокарте достаточно видеопамяти, то практически никакого. Если же ее не хватает, вы получите ощутимые фризы и тормоза. 4 гигабайт VRAM хватает для подавляющего числа современных игр, но лучше бы в вашей следующей видеокарте памяти было 8 или хотя бы 6 гигабайт.
Анизотропная фильтрация
Анизотропная фильтрация, или фильтрация текстур, добавляет поверхностям, на которые вы смотрите под углом, четкости. Особенно ее эффективность заметна на удаленных от игрока текстурах земли или стен.
Чем выше степень фильтрации, чем четче будут поверхности в отдалении.
Этот параметр влияет на общее качество картинки довольно сильно, но систему при этом практически не нагружает, так что в графе «фильтрация текстур» советуем всегда выставлять 8x или 16x. Билинейная и трилинейная фильтрации уступают анизотропной, а потому особенного смысла в них уже нет.
Влияние на производительность
Тесселяция
Технология, буквально преображающая поверхности в игре, делающая их выпуклыми, рельефными, натуралистичными. В общем, тесселяция позволяет отрисовывать гораздо более геометрически сложные объекты. Просто посмотрите на скриншоты.
Влияние на производительность
Зависит от игры, от того, как именно движок применяет ее к объектам. Чаще всего — среднее.
Качество теней
Все просто: чем выше этот параметр, тем четче и подробнее тени, отбрасываемые объектами. Добавить тут нечего. Иногда в играх также встречается параметр «Дальность прорисовки теней» (а иногда он «вшит» в общие настройки). Тут все тоже понятно: выше дальность — больше теней вдалеке.
Влияние на производительность
Зависит от игры. Чаще всего разница между низкими и средними настройками не столь велика, а вот ультра-тени способны по полной загрузить ваш ПК, поскольку в этом случае количество объектов, отбрасывающих реалистичные тени, серьезно вырастает.
Глобальное затенение (Ambient Occlusion)
Один из самых важных параметров, влияющий на картинку разительным образом. Если вкратце, то AO помогает имитировать поведения света в трехмерном мире — а именно, затенять места, куда не должны попадать лучи: углы комнат, щели между предметами и стенами, корни деревьев и так далее.
Существует два основных вида глобального затенения:
SSAO (Screen space ambient occlusion). Впервые появилось в Crysis — потому тот и выглядел для своего времени совершенно фантастически. Затеняются пиксели, заблокированные от источников света.
HBAO (Horizon ambient occlusion). Работает по тому же принципу, просто количество затененных объектов и зон гораздо больше, чем при SSAO.
Влияние на производительность
Глубина резкости (Depth of Field)
То самое «боке», которое пытаются симулировать камеры большинства современных объектов. В каком-то смысле это имитация особенностей человеческого зрения: объект, на который мы смотрим, находится в идеальном фокусе, а объекты на фоне — размыты. Чаще всего глубину резкости сейчас используют в шутерах: обратите внимание, что когда вы целитесь через мушку, руки персонажа и часть ствола чаще всего размыты.
Впрочем, иногда DoF только мешает — складывается впечатление, что у героя близорукость.
Влияние на производительность
Целиком и полностью зависит от игры. От ничтожного до довольно сильного (как, например, в Destiny 2).
Bloom (Свечение)
Этот параметр отвечает за интенсивность источников света в игре. Например, с включенным Bloom, свет, пробивающийся из окна в помещение, будет выглядеть куда ярче. А солнце создавать натуральные «засветы». Правда, некоторые игры выглядят куда реалистичнее без свечения — тут нужно проверять самому.
Влияние на производительность
Чаще всего — низкое.
Motion Blur (Размытие в движении)
Motion Blur помогает передать динамику при перемещениях объекта. Работает он просто: когда вы быстро двигаете камерой, изображение начинает «плыть». При этом главный объект (например, руки персонажа с оружием) остается четким.
Технологии графики в современных играх, часть 1: Новомодные свистелки-перделки
Вступление
Ты вступление не читаешь. Тебе оно не интересно.
Мне тоже не интересно описывать, что я за хрен с горы и нафига тут вылез. Но надо.
Короче, крути вниз.
Всем привет.
Наблюдая в недавнем стриме по MATRIX: Path of Neo за тем, как Вася с Максом рассуждают на тему LOD’ов, я понял одну интересную вещь: в современных играх меню с настройками графики представляет собой что-то совершенно непотребное. Оно либо жутко кастрировано, либо открывает для пользователя такую простыню непонятных слов, в которой и чёрт ногу сломит. 
Ладно, я — сам работаю в игрострое. Так что мне-то понятно, какая настройка за что отвечает. Но порой тоже не без трудностей. А вот простых игроков, наверное, при чтении всех этих названий одолевает тихий ужас.
Причём, мир не стоит на месте, и новые графические «фичи» появляются каждый год, а то и месяц. Недавно — вон, свет увидел TressFX.
Так что дальше будет только больше, и без посторонней помощи разобраться во всём этом техническом безобразии в скором времени уже просто не получится.
Разработчики игр упрощают это дело, как могут, по максимуму убирая из меню всё лишнее. Вот только беда в том, что это вовсе не «лишнее», и надобность той или иной технологии зависит от того, насколько мощное у игрока железо.
В консолях это самое железо известно заранее, и игроделы могут просто сами подобрать оптимальные параметры, скрыв их от глаз игроков. Но вот сделать такое для ПК — в принципе невозможно.
Тем временем, меню всё разрастается и разрастается…
Не удивлюсь, если через пару лет в сингле какого-нибудь ААА-шутера в туториал добявят объяснение графических настроек. А пока — я постараюсь помочь всем интересующимся сориентироваться во всём этом многообразии.
Сразу извиняюсь за возможно «не такой» формат повествования.
Вообще, это далеко не первый мой рассказ на подобную тему. Но обычно подобные темы я обсуждаю с другими такими же «CG-гиками» (коллегами по цеху). А вот в блогах на SG — я пишу впервые. Так что местами могу «не попасть» в то, как тут принято.
Постараюсь не разводить нудятину и осветить тему без излишних технических подробностей. Так что надеюсь обойти стороной всякие вертексные/пиксельные шейдеры, шейдерные модели, graphics pipeline и т.п. Но если что — ссаными тряпками прошу не закидывать.
Как говорится, «это мой первый пост, не судите строго».
Итак, ближе к делу. Рассказ о технологиях пойдёт в порядке их «свежести». А начнём с…
AMD TressFX
Эта технология — просто идеальный пример одного тренда, который прослеживается в игровой индустрии испокон веков. Суть его вот в чём: игровая индустрия сама по себе не придумывает практически никаких технологий.
Просто время идёт, мощности железа растут. И со временем, пускай и с какими-то упрощениями, становится возможным делать в реалтайме то, что раньше было доступно только в «тяжёлом» рендере… ну, то есть, в том, что геймеры именуют «CGI-роликами».
Иными словами, практически все технологии, появившиеся в играх — всего лишь упрощённое заимствование того, что уже давным-давно широко используется в кино и изучено вдоль и поперёк.
Собственно, что такое TressFX? А очень просто: это всего лишь готовый кусок программного кода от AMD, с помощью которого можно считать волосы на видеокарте.
Вообще 3D-шники умеют делать волосы уже много-много лет. Ты их не раз видел во всяких 3D-мультиках. 
Просто раньше это делалось на проце и требовало этих самых процов дофига. Естественно, ни о каком реалтайме — и речи быть не могло.
Поэтому в играх причёски в любом случае делались такими полигональными «лоскутками», на которых волосы были просто текстурой. 
Предыдущие картинки взяты из легендарного в среде 3D-шников making-of’а модели «Varga» от Paul Tosca.
В самом making-of’е картинок ещё больше, и есть gif’ки, позволяющие посмотреть модельку со всех сторон.
А теперь гигагерцы выросли, видюхи растолстели. И игровые программисты могут просто взять этот готовый TressFX и воткнуть его в игру: волосы будут считаться в реалтайме на GPU. Считай, ничего делать не надо: покрутил пару параметров, настроил длину — и очередная пара косичек готова.
Причём, на видеокарте считается не только то, как эти волосы выглядят, но и их физика. То есть, как движется каждый волосок.
В будущем это даст гораздо большую реалистичность стрижек у персонажей: они будут выглядеть, прям как настоящие. Но пока что видюхи попросту не настолько сильные, чтоб держать в кадре хотя бы две таких причёски.
Ну то есть даже на топовом Радеоне на расчёт одной такой шевелюры уходит столько же ресурсов, сколько на всю остальную сцену. В результате — игра тормозит, а волосы глючат (и выглядят хуже, чем сделанные по старинке). Что недавно вышедшая Лара наглядно продемонстрировала.
Так что на сегодняшний момент TressFX нужна не столько игрокам, сколько разработчикам. Это банально проще: не париться с созданием геометрии и текстур, а считать волосы по физике, «в лоб».
GPU Particles (частицы на видюхе)
Всё очень просто: видеокарта лучше справляется с задачами, которые легко распараллелить.
Ну то есть, считать много всего однотипного — это к видюхе. Считать что-то одно сложное — это к процу.
В DirectX 11 появилась такая штука (DirectCompute), которая позволяет разработчикам игр самостоятельно считать на GPU практически что угодно.
Естественно, благодаря этому те вещи, которые сами по себе хорошо параллелятся — первым же делом и были перенесены с проца на видюху. Что позволило увеличить детализацию этих «вещей» в несколько раз.
Ярчайший пример — системы частиц. У нас в кадре есть дофига маленьких-маленьких объектов. Вроде песчинок, снежинок, капель воды… Так вот. Раньше мы их считали на проце, поэтому приходилось исхитряться. Например, рисуя вместо одной частицы текстуру, где их 100.
А теперь — мы их считаем на видюхе, так что можем делать это по-честному. Вместе со всей физикой. Это позволяет нам ворочать в кадре буквально миллионами частиц, создавая просто ошеломительные эффекты. 
Интерактивное онлайн-демо с адским числом частиц прямо в браузере (требуется DX11 + нужно установить Unity Web Player)
Некоторые считают, что GPU-частицы, как и другие новомодные фичи — исключительно прерогатива DX11. На самом деле — современный OpenGL может всё то же самое, а местами — даже больше. В чём легко убедиться, погуглив на ютубе.
Так что. Тот факт, что современные игры выпускаются с упором на DirectX — это даже не какой-то заговор Мелко-Мягких, а банальная инерция игроделов.
С технической точки зрения ничто не мешало уже FarCry 3 или Crysis 3 работать не на DirectX, а на OpenGL. А он, вообще-то, кросс-платформенный. То есть, разработчики один раз пишут шейдер, который одинаково отработает и на Windows, и на MacOS, и на Linux.
А учитывая, какие операционки используются на PS4 и грядущем Steam Machines — улавливаешь мысль? Очень скоро произойдёт…
Ну да ладно, это уже совсем другая история. 
Voxel Cone Tracing
Tesselation
Что это нам даёт? Ну, вообще-то, сама по себе тесселяция ничего не даёт. Но зато, если её комбинировать с другими технологиями — можно сделать тот самый «ГРАФОН. 111», на который фапают графодрочеры.
В самом простом случае — да, можно добавить к тесселяции другую технологию (vector displacement), которая по специальной текстуре рельефа «выдавит» точки на тесселированом объекте. Это позволит добавить, собственно, рельеф, сделав прям-таки фотореалистично детализированный уровень. 
Но ведь двигать точки на поверхности можно не только по заранее сделанной фиксированной текстуре. Вместо текстуры величину смещения можно получать по какому-нибудь хитрому алгоритму. То есть прямо во время игры, при отрисовке каждого кадра для каждой точки вычисляется, куда её сместить… хм, не совсем понятно, наверное?
Давай так. Вот у текстуры — есть разрешение. Рано или поздно, когда ты приблизишься — увидишь пиксели. А у алгоритма разрешения нет. То есть, приближать/отдалять можно сколько угодно, не теряя при этом ни детализации, ни производительности. Таким способом (он называется procedural displacement) можно из одной плоскости… выдавливать целые ландшафты. И сколь близко бы ты на него ни смотрел — он всегда будет очень детализированным.
Можешь прикинуть такие масштабы в новом Масс Эффекте?
Или такой пример. Представь, что при замерзании твоего персонажа на нём прямо по форме тела вырастают сосульки. Не внезапно появляются изниоткуда, а именно вырастают. Причём разработчикам для этого достаточно всего лишь 1 раз сделать материал с этим алгоритмом, и потом можно его применять вообще на любой объект.
На любой. То есть, целые уровни можно замораживать, просто накинув на все объекты этот материал.
И алгоритм для смещения может быть любым. Например, он может учитывать текущее время и благодаря этому заставлять этот рельеф двигаться. Ну допустим, у персонажа прямо будет видно, как пульсирует вена.
В общем, тесселяция напару с процедурным дисплейсментом открывает для разработчиков прям-таки безграничный арсенал выразительных средств.
Кроме того, использование тесселяции позволяет вообще отказаться от технологии LOD (Level of Detail), о которой я упоминал в начале. Проще говоря, разработчики за те же деньги смогут сделать больше объектов на уровне. То есть, не только сами объекты при близком разглядывании будут более детализированными, но и уровни в целом будут более разнообразными. Но это только если делать игру исключительно с расчётом на DX11 и соответствующее железо.
Так что если твой комп тянет тесселяцию — лучше по умолчанию её включать. Игра так будет не только более красивой, но и работать может быстрее.
Realtime Ambient Occlusion
High Definition Ambient Occlusion — AO высокого разрешения.
Реализация от AMD. Картинка натуральнее, чем с HBAO. Что лично меня как поклонника AMD/ATI — радует.
Но вот со скоростью — те же непонятки. На видюхах от AMD — быстрее, чем HBAO, но медленне, чем SSAO. На видюхах от нвидии — бывает по-разному. В том числе бывает, что HDAO быстрее, чем «родной» HBAO.
В общем, обычно HDAO/HBAO — медленнее и качественнее, чем SSAO. Качество картинки в любом случае улучшается так: SSAO — HBAO — HBAO+ — HDAO (хотя лично я считаю, что первые два надо поменять местами). Но вот какой вариант быстрее — проще самому попробовать в игре.
Как-то так. На сегодняшний день — это все технологии, которые я могу причислить к относительно новым.
Пока что практически ни одна из них не используется широко. Но именно их существование подталкивает игровую индустрию вперёд. Разработчики игр видят те возможности, которые открывают эти новомодные «фичи». Но они вынуждены ориентироваться на среднестатистическое железо, поэтому пока не спешат внедрять всё и сразу.
Игроки же потихоньку это самое железо обновляют, приближая тот момент, когда все эти технологии станут «стандартным набором» и тем самым спровоцируют появление новых.
В общем, как всегда: поживём — увидим.
Bonus: DirectX 11 vs OpenGL 4
Многие годы DirectX царственно восседал на троне неоспоримого лидера по графическим прибамбасам. Чем Microsoft и жила. В эпоху Windows XP «играть в игры» было практически синонимом «пользоваться Windows». Да что уж там, ситуация сохраняется по сей день. Когда говорят «ПК», то по умолчанию подразумевается Windows 7 со встроенным в неё DirectX’ом.
На консолях есть свои графические библиотеки — но на то они и консоли. А на ПК безраздельно правит DirectX…
Однако в последнее время эта его «безраздельность» нехило так пошатнулась. Дело в том, что, действительно, OpenGL всегда не дотягивал до возможностей DirectX, из-за чего игроделы выбирали последнего. OGL всегда «как бы мог» всё то же самое, но со скрежетом. Всегда проигрывал по скорости. Всегда «не дотаягивал» по качеству итоговой картинки или количеству параметров.
Всегда.
До релиза OpenGL 4.
С его появлением в индустрии, можно сказать, пройдена точка невозврата. Если сравнивать DX11 и OGL 4 — то выясняется, что в конкретно этих двух версиях уже начинает лидировать OpenGL. Не с диким отрывом, нет. Потихоньку-помаленьку… вот тут рендерится быстрее, вот там возможностей больше, вот здесь код чище.
Но в сумме набирается, что сегодняшний OGL не только не уступает по возможностям перед DirectX, но в чём-то даже превосходит. Об этом я вскользь упоминал в разделе про GPU-партиклы. Но решил на этом остановиться поподробнее.
Ведь, пробежавшись взглядом по статье, я заметил, что все описанные в ней технологии, кроме TressFX, есть параллельно и на DX, и на OGL. А аналог TressFX в принципе можно сделать и на нынешнем OGL.
Относительно недавно даже появился специальный игровой движок — Unigine. Его, как говорится, «killing feature», на которую упирают создатели — это то, что он обеспечивает совершенно идентичную картинку на всех платформах. На Windows он использует DirectX, на остальных — OpenGL.
Собственно, та самая демка, которая демонстрирует прелести тесселяции, которую все видели — она сделана на Unigine:
С появлением движка Unigine — на ютубе стали вылазить сравнительные сплит-скрин бенчмарки одной и той же сцены на DX и на OGL. И, глядя на них, начинаешь замечать едва видимые, но отличия. Вот тут свет считается точнее, вот там расфокус размывается правильнее, вот здесь тесселяция плотнее, а линзовые эффекты физически корректнее.
А потом выясняется, что на некоторых конфигурациях OGL ещё и быстрее.
В общем, все и так поняли, что я хочу сказать. Оставлю свои эмоции в стороне и просто предоставлю одно из таких видео: