Сегодня мы хотели бы объяснить новую графическую функцию, которую мы вводим в наши игры в обновлении 1.38. Статья очень техническая — мы попросили наших программистов помочь, и объяснение довольно сложное. Однако мы чувствовали, что, по крайней мере, некоторым людям из нашей аудитории может быть интересно познакомиться с этим материалом — увидеть, что то, что происходит под капотом игрового движка, требует большого количества исследований и напряженной работы наших команда программистов. Мы думали, что помимо технических деталей, предоставление контекста и объяснение компромиссов производительности может быть полезным и важным для большинства игроков.
Ярослав aka Cim (один из наших смелых и опытных программистов, работающих над улучшением графики)
Краткое содержание приведенного ниже текста TL; DR заключается в том, что Screen Space Ambient Occlusion — это крутая новая, но высокопроизводительная техника для обогащения рендеринга нашего игрового мира. Вам не нужно использовать его, если вы чувствуете, что он слишком сильно снижает производительность, или он вам нравится, и вы можете позволить себе потратить несколько кадров в секунду для улучшения восприятия тени и глубины. Эффект может быть незаметным, в основном он работает на уровне подсознания, но как только вы к нему привыкнете, может быть трудно вернуться. Это еще одна веха в нашем плане улучшения освещения / затенения, который мы сейчас выполняем, за которым последует новая обработка света HDR и введение большего количества поверхностей с нормальным отображением в будущих обновлениях.
У этой техники есть свои ограничения и причуды. В последние годы он использовался в нескольких играх AAA, и даже если он не идеален, он помогает системе человеческого восприятия лучше понять сцену, и мы надеемся, что добавление его в технологический комплекс наших симуляторов грузовиков будет полезным. Без сомнения, мы захотим ввести дополнительные способы вычисления затенения, которые улучшат или даже заменит его.
Мы постоянно вынуждены улучшать внешний вид нашей игры со стороны некоторых наших фанатов. При этом всегда есть желание, чтобы игры работали быстрее. Помимо этих иногда конкурирующих запросов, поступающих от игроков, наш собственный художественный отдел постоянно стремится заполучить новые графические игрушки, чтобы сделать нашу игру богаче и лучше. Всякий раз, когда мы вводим в игру новую графическую функцию, мы стараемся сделать это таким образом, чтобы не ухудшить производительность для игроков со старыми компьютерами, мы не хотим сделать игру несовместимой для наших существующих клиентов. Поэтому есть возможность полностью отключить SSAO и несколько настроек его качества / производительности.
Работа наших программистов над новыми методами SSAO / HBAO также потребовала изменений в нашем конвейере художественного творчества. Все 3D-модели в наших играх должны были быть пересмотрены художественным отделом, и все случаи, когда искусственные тени и затемнения уже применялись к модели художником, были изменены. Для некоторых более сложных игровых моделей это было упрощение, которое фактически уменьшило количество треугольников в них настолько, чтобы улучшить производительность рендеринга. В некоторой степени мы обменяли часть предварительных будущих ручных усилий, которые потребуются для создания отдельных красивых 3D-моделей, на этап алгоритмического рендеринга, который унифицирует внешний вид затенения для всей сцены, помогая «закрепить» объекты, такие как здания, фонарные столбы и растительность на местности.
Прежде чем мы начнем, обратите внимание, что SSAO — это общее сокращение от «display area ambient occlusion». Название включает в себя все различные методы окружающей окклюзии (AO) и их варианты, которые работают в экранном пространстве (это означает, что они получают всю информацию во время выполнения из данных, которые отображаются на экране компьютера и в соответствующие буферы памяти). Существует SSAO (технология Crytek 2007, которая дала общее название всем методам), MSSAO, HBAO, HDAO, GTAO и многие другие методы, каждый из которых использует по-разному настроенные подходы, каждый из которых имеет свои преимущества и недостатки. В основе нашего подхода лежит методика, основанная на горизонте, называемая GTAO, которая была представлена Activision в статье 2016 года.
Часть имени ambient occlusion (AO) означает, что мы оцениваем, какая часть входящего света (преимущественно небесного света, но иногда вычисленная окклюзия применяется также и к другим источникам света) перекрывается в определенном месте игрового мира. Представьте, что вы стоите на плоской земле — вы бы видели все небо наверху, так что окклюзия 0%, земля полностью освещена небом. Теперь представьте, что вы находитесь на дне колодца — вы бы видели только небольшой участок неба, это означает, что небо закрывается почти на 100% и вносит лишь небольшой вклад в окружающее освещение в этом колодце, и, естественно, в этом колодце довольно темно. дно колодца. Определенный уровень окружающей окклюзии в определенном месте влияет на вычисления освещения и создает затененные области в складках, отверстиях и других «сложных» местах. Оно может быть от 0% до 100% в зависимости от их окружения.
Детальное и точное вычисление окклюзии требует значительных ресурсов; По сути, вам нужно будет стрелять лучами из любой оцениваемой позиции во всех направлениях и проверять, попадают ли они в небо или нет, а затем усреднять результат. Чем больше лучей вы выстрелите, тем более точную информацию вы получите, но с большими вычислительными затратами. Этот процесс может быть обработан в автономном режиме, например, когда игровая карта сохраняется ее разработчиком. Некоторые игры и движки используют этот подход. Но таким образом вы можете запекать информацию об окружающей окклюзии только для статических неподвижных объектов, потому что в это время нет транспортных средств или анимированных объектов.
Поэтому вместо запекания статической информации (что также потребует много времени и места для хранения, учитывая масштаб нашей карты мира), мы хотим вычислять ее «на лету», во время выполнения. Таким образом, мы можем вычислить его также для взаимодействия с транспортными средствами, открытия мостов, анимированных объектов и т. Д. Однако есть одна загвоздка. Для такого подхода к вычислениям у нас есть только данные, которые видны на экране (вспомните «экранное пространство»), поэтому, как только какая-то часть игрового мира выходит за пределы видимого кадра, ее нельзя использовать для оценки окклюзии. Это ограничение создает различные артефакты, такие как исчезновение окклюзии на стене, первоначально вызванное объектом, который только что оказался за краем экрана и, таким образом, стал невидимым не только для вас, но и для алгоритма, поэтому он перестал участвовать в вычислении окклюзии.
Хорошо, теперь мы знаем, что оценивать (окружающая окклюзия), и мы знаем, какие данные у нас есть (что мы видим на экране). Что мы делаем? Что ж, для каждого пикселя на экране (это 2 миллиона пикселей в разрешении HD, умноженное на четыре (!) При 400% масштабировании!) Наш шейдерный код должен запрашивать значение z-буфера окружающих пикселей, пытаясь получить представление о геометрическая форма окружающей его территории. Мы можем сделать только ограниченное количество этих «нажатий», поскольку при увеличении количества нажатий резко возрастает стоимость производительности, и это операция, которая действительно обременяет 3D-ускоритель. Ограничение на количество нажатий, в свою очередь, влияет на точность окружающей окклюзии (и в определенных ситуациях может создавать неточности и полосы). Представьте, что вы хотите оценить свое окружение на 2-метровой прямой и готовы потратить eight касаний, чтобы приблизиться к нему. Вы запрашиваете линию каждые 25 сантиметров, и любая деталь меньшего размера может оказаться совершенно незамеченной, если только вам не повезет и вы не попадете в точку (или не повезете, потому что вы можете пропустить ее в следующем кадре, и окружение внезапно изменится между кадры и вызывают мерцание). Чем дальше ваш алгоритм исследует, тем он менее точен. Таким образом, вам необходимо ограничить размер анализируемой области вокруг каждого игрового пикселя, что, в свою очередь, ограничивает то, как далеко АО «видит» — вот почему он не подходит для вычисления окклюзии в больших пространствах, например, под арками моста.
Мы упоминали, что выбранная нами техника основана на горизонте. Это означает, что мы не исследуем окружающую среду, снимая лучи в трехмерном мире, вместо этого мы анализируем полусферу выше / вокруг каждого пикселя, чтобы увидеть, насколько далеко она открывается, пока не будет заблокирована, сколько света пропускает окружающая геометрия. используя z-буфер в качестве нашего прокси. Полусфера фактически аппроксимируется несколькими пробегами по линии, вращающейся вокруг данного пикселя. Если мы сможем полностью проследить это полушарие, окклюзии не будет. Если алгоритм выбирает значение в z-буфере, которое блокирует входящий свет, он определяет уровень окклюзии. Алгоритм оптимизирован для производительности, но его ограничение состоит в том, что как только он сталкивается с чем-либо, даже, возможно, с небольшим объектом, он прекращает дальнейшие исследования. Это может вызвать проблему «чрезмерной окклюзии» и может быть замечено как визуальный артефакт, когда какой-либо относительно тонкий объект, такой как столб дорожного знака, вызывает сильное перекрытие на ближайшей стене. Вы можете попытаться обнаружить такие маленькие объекты и пропустить их, что, в свою очередь, может привести к «недостаточной окклюзии» на тонких выступах. Мы выбрали первое.
Есть еще одно интересное и полезное свойство методов, основанных на горизонте. В зависимости от того, какая часть полусферы над заданным пикселем перекрыта, вы можете вычислить направление, которое меньше всего перекрывается. Степень окклюзии можно представить как конус мороженого с различным углом при вершине, ориентированный в этом направлении. Это направление называется «изогнутой нормалью», и мы используем его для различных вычислений света, например, для перекрытия отражения на блестящих поверхностях. Идея состоит в том, что если вы смотрите на поверхность и направление зеркального отражения выходит за пределы этого конуса, мы считаем его (по крайней мере частично) закрытым, уменьшая интенсивность отражения. Лучший способ увидеть этот эффект — посмотреть на более крупные и круглые хромированные детали, такие как топливные баки, с включенным и выключенным SSAO.
Как видите, идея не так уж и сложна, в любом случае для опытного программиста графики;), но требуется много вычислений, что создает некоторую нагрузку на 3D-ускоритель. Итак, мы создали несколько профилей производительности, в каждом из которых используется сочетание методов оптимизации:
- Использование меньшего количества касаний в каждом направлении — это быстрее, но позволяет AO пропускать более крупные объекты, чем при более точной выборке.
- Перепроецирование результатов AO из предыдущего кадра — это позволяет нам скрыть артефакты от недостаточной дискретизации, но может создавать ореолы при сбое перепроецирования (когда то, что вы видите между кадрами, сильно меняется).
- Рендеринг в половинном разрешении — уменьшает количество вычислений до 1/4, но создает менее точную АО — результат может быть слегка размытым затенением
Надеемся, что вся эта информация была для вас интересной и полезной. Мы посылаем вам виртуальную пятерку, если вы прочитаете эту статью до сих пор. Вы заслуживаете печенья и большой чашки горячего шоколада! Если вы все еще хотите получить более подробную информацию по этой теме, не стесняйтесь проверить, например, эта ссылка.
Спасибо за ваше время и поддержку, и мы снова увидимся в следующих статьях из раздела «Под капотом», который мы время от времени приносим для нашего #BestCommunityEver.
Также не забывайте, что скоро заканчивается летняя распродажа Steam! Посетите нашу страницу для разработчиков.
