Первоначально опубликовано в Гамасутре 10 июля 2015 г.
Более девяти месяцев назад, когда я впервые обратился к The Astronauts, я тоже не думал, что в команде, работающей на Unreal Engine, есть чем заняться в области графического программирования. Но Адриан Хмеларц сделал это, и в ноябре прошлого года я стал восьмым членом стаи.
Наверное, не станет сюрпризом, что я не провел никаких новаторских исследований; поэтому я не буду вдаваться в подробности, описывая изменения, которые я сделал, чтобы помочь выпустить Исчезновение Итана Картера для PlayStation 4, поскольку они в основном относились к рабочему разнообразию: применение общедоступных технологии, исправление ошибок и отчетность и тому подобное. В общем, моей работой было поддерживать художников.
Переделка Итана Картера
Ситуация, в которой мы оказались, была несколько необычной: у нас была (все еще) довольно свежая игра, которую мы должны были переделать на другом игровом движке. И тот, который отличается практически во всех ключевых аспектах: архитектура рендеринга, модель освещения, движок сценариев игрового процесса. Игровой дизайн и ресурсы были вне поля зрения, но у нас все еще был довольно твердый визуальный тест, который нужно было встретить в виде версии игры для UE3, и многое нужно было научиться ориентироваться в UE4, чтобы мы не выпустили «римейк». это выглядит хуже оригинала…
С точки зрения графики, одной из вещей, придававших TVoEC жутковатый, мечтательный вид, было статическое глобальное освещение с мягкими тенями и множеством отражений света. Это означает статические запеченные карты освещения. Однако в UE4 есть отложенный рендерер, оптимизированный для динамического освещения. Добавьте к этому физический конвейер рендеринга UE4, и вы, вероятно, начнете ощущать расхождение целей. Это расхождение оказалось чрезвычайно важным при разработке версии игры для PS4: мы использовали пути кода и рабочие процессы, которые почти никто больше не использовал. Другими словами, мы могли столкнуться с проблемами, которые долгое время оставались незамеченными. Так мы и сделали.
Добавление функций
Обожаю UE4. С ним гораздо приятнее работать, чем с UE3, кажется, что в него вложено гораздо больше предусмотрительности, я полностью поддерживаю отказ от UnrealScript. Но очевидно, что это все еще более молодой двигатель, чем UE3. Большинство функций уже есть, но некоторые еще впереди, другие реализованы частично. Некоторые из них присутствовали в Unreal Engine 3, но еще не вернулись (и, возможно, вообще не вернутся, поскольку, опять же, UE4 идет в другом направлении по сравнению с UE3), и наши художники хотели их вернуть, и хотели их быстро. .
Одним из таких вещей были каналы освещения. У Epic была эта функция в своей дорожной карте, но поскольку это еще не окончательная дата, ее введение было моим первым заданием. И это было очень поучительно, поскольку я впервые познакомился со многими слоями UE4: я вторгался повсюду, от шейдеров до структур данных базового движка.
Другим примером был эффект «экранной двери» для переходов LOD, также известный как переходы LOD с размытием: эффект, предназначенный для скрытия всплывающих окон с использованием эффекта симметричного попиксельного растворения (LOD с постепенным исчезновением отбрасывает пиксели, отображаемые с помощью LOD с постепенным исчезновением), и наоборот). В то время это уже было реализовано для экземпляров статических сеток (то есть листвы), но не для обычных. И снова, это было в дорожной карте движка, но мы хотели это сейчас, поэтому я решил восполнить этот пробел. В конце концов, однако, Epic предоставила собственное решение, которое я интегрировал и заменил своим.
Одна недостающая функция UE3, которую я не мог реализовать разумным образом, - это группы приоритета глубины. Он позволяет отображать примитивы, как если бы они имели отдельные буферы глубины, что полезно для обеспечения того, чтобы объекты переднего плана никогда не пересекались с окружающей геометрией. Однако этот подход не может быть легко использован при отложенном рендеринге, поскольку он затруднит разрешение экранного пространства. Вместо этого я собрал смещение пространства клипа, которое сглаживало объекты переднего плана вдоль оси Z пространства клипа и перемещало их в ближайшую плоскость отсечения, заставляя их рендерить перед всем, не меняя при этом их видимый размер или форму. Далеко не идеально (освещение ведет себя немного иначе), но свою работу сделал.
Теперь все работает по-другому
Как я уже упоминал ранее, существует большое расхождение между тем, что нужно нашей игре, и тем, что UE4 делает лучше всего. PBR был - на самом деле для меня довольно неожиданным - наименьшей из наших забот. С другой стороны, отложенный рендерер доставил мне некоторые головные боли.
В UE4 карты освещения должны содержать только непрямое (отраженное) освещение; установка подвижности источника света на «статический» приводит к тому, что затронутые им карты освещения также включают прямое освещение, но это исключительная ситуация, а не по умолчанию. Такие светильники даже не рассматриваются для динамического освещения. Это означает, что на них нет зеркальных бликов. Совсем нет. Вы, наверное, можете себе представить, насколько плоской и неинтересной выглядела игра из-за этого.
Я «исправил» это, добавив прямое ложное отражение по Фонгу к эмиссионному освещению. Я до сих пор чувствую себя супер грязным из-за этого. Он нарушает принцип сохранения энергии и использует зеркальное распределение, отличное от PBR, но художникам это понравилось.
Теперь единственная проблема, которая оставалась, заключалась в том, что это поддельное отражение не было затенено ... Это, в свою очередь, было исправлено путем испускания дополнительного фактора на тексель в картах освещения, описывающего, сколько света в данном текселе карты освещения было внесено прямым, и сколько - непрямое освещение. Предполагалось, что тексели с нулевым прямым освещением находятся в тени. Безумно и опасно, но для игры на открытом воздухе, когда светит только солнце, это сработало!
Еще одно место, где изменилось поведение движка, - рендеринг полупрозрачной сетки. В игре есть мини-игра-головоломка о настройке хронологии событий с полупрозрачными призраками. Эти призраки не закрывались сами по себе, поэтому рендерились внутренние и фронтальные многоугольники, создавая уродливые артефакты.
Художники исправили это в UE3, выполнив ручное альфа-смешивание, так как это заставило бы движок выполнить некоторое изменение состояния и преобразовать цвет сцены в читаемую текстуру, эффективно захватывая ранее визуализированные сетки в этой текстуре. В UE4 это не будет работать (по крайней мере, не полностью), поскольку разрешение текстуры цвета сцены выполняется для каждого элемента сетки, а не для всей сетки. В результате внутренние многоугольники элемента сетки будут правильно закрыты, но пересечения с соседними элементами все равно будут содержать уродливые артефакты.
Изначально мы использовали голографический материал Тома Лумана; это сработало только частично, так как главный персонаж отбрасывал тех, кто позади него, а призраки часто бывают в непосредственной близости друг от друга, что делает его невозможным. В конце концов, я последовал предложению Кшиштофа Нарковича и добавил для этих персонажей своевременный предварительный проход для глубины меша. Поскольку примитивы уже были отсортированы по глубине, это дало нам точный эффект, который нам нужен.
UE4 также покончил с плоскими отражениями. Оглядываясь назад, я, вероятно, должен был реализовать их, поскольку это избавило бы нас от многих проблем при работе с рендерингом воды, но мы решили придерживаться того, что UE4 дал нам из коробки.
Однако сразу после настройки захватов отражения окружающей среды я узнал, что наше озеро, по-видимому, отражает не одно, а несколько солнц, и все они находятся в неправильном месте. Это произошло из-за смешения кубических карт отражений без учета глубины. Если не считать переноса игры на планету в тройной звездной системе, мне пришлось это исправить. Помните, как я упоминал, что наши цели расходятся с Epic? В итоге я взломал систему захвата отражений, чтобы отбросить пиксели нашего небесного купола, и внедрил предварительно отрендеренную карту небесного куба в конвейер рендеринга, вместо этого притворившись небесным светом.
По прихоти художников
Большую часть времени я просто выполнял просьбы наших художников.
Не хотите, чтобы меши с более низким уровнем детализации имели отдельные наборы карт освещения? Конечно, я заставлю их использовать LOD 0. Не хотите, чтобы какие-либо изменения, которые вы вносили на уровне, приводили к «расформированию» освещения или предварительному просмотру с динамическим освещением? Ладно, сложно, но готово. Вам тонмаппер от 4.7 понравился больше, чем новый от 4.8? Ладно, откатываем обновление. Хотите сэкономить память, сжав карты нормалей с помощью DXT1 вместо BC5? Конечно. Вернуть простую глубину резкости, которую вы знаете по UE3? Да, готово. Вершинный туман на полупрозрачных материалах должен учитывать окклюзию светового вала? Вот и все.
О, тебе не нравится временное сглаживание? Эээ… Позвольте мне проверить наши варианты.
Несмотря на то, что мне это нравилось, нашим художникам не понравилось, как решение Epic с временным АА замораживает субпиксельные движения листвы и размывает детали текстур вблизи. Настройка его параметров не сильно помогла. FXAA был временно нестабильным, так что это тоже не сработало. Поэтому я решил проверить другие варианты.
В конце концов, я интегрировал SMAA T2x. Художникам он понравился больше всего: он демонстрирует разумную временную стабильность и отсутствие чрезмерного размытия деталей. Однако из-за того, что это алгоритм mutlipass (обнаружение краев, вычисление веса смешивания и размытие окрестностей в SMAA 1x, плюс интегрирование скорости и временное разрешение для SMAA T2x - всего пять полноэкранных проходов), он занимает примерно в 4 раза больше время выполнения как FXAA (за один проход), или примерно в 1,5–2 раза по сравнению с TAA Epic. Кроме того, я так и не удосужился правильно определить когерентность движения объекта, поэтому в конце концов мы остановились на FXAA. Для игры он работает достаточно хорошо.
Обновлено 16 июля 2016 г .: версия Redux для Windows в конечном итоге поставлялась с SMAA T2x, и я недавно выпустил код для этой интеграции на Github (убедитесь, что у вас установлен Unreal Engine. и подключены учетные записи Github , иначе ссылка выдаст ошибку 404).
Я уже упоминал, что из-за того, что игра в значительной степени полагается на статическое освещение, мы, вероятно, столкнемся с неизведанными угловыми случаями. Довольно часто определенные настройки контента приводили к сбою в остальном хорошо работающие функции, и я должен был выяснить причину и рекомендовать способ исправить контент соответствующим образом. Например, у нас были порождения частиц, вызывающие мерцание подвижных объектов из-за слишком больших границ группы привязок или из-за того, что положение объекта в материалах разрешалось в кажущееся неправильное местоположение, также из-за чрезмерных границ объекта. В тех случаях вина была полностью на нашей стороне.
Исправление ошибок
Любой игровой движок в мире находится в стадии разработки, и UE4 не исключение. Несмотря на то, что у Epic отличная и очень компетентная служба поддержки, у нее есть миллионы пользователей, и вам, возможно, просто придется подождать, чтобы решить вашу проблему. Наличие в команде программиста движка дает вам преимущество (обычно) более короткое время отклика; эти ошибки обычно не так сложны и не поддаются исправлению в вашей собственной локальной кодовой базе (спасибо за полный исходный код, Epic!), и даже если это не так, программист движка может быть лучше подготовлен для обеспечения надлежащей диагностики Epic. Мы стараемся объединить эти исправления в апстриме, когда это возможно.
Для Итана на PS4 я исправил ряд мелких проблем, таких как неправильные координаты экрана материала после обработки для неполноэкранных окон просмотра, неточная окклюзия для рекламных щитов со смещением в мировом положении, устаревшие образцы в кэше статического освещения после уровня. изменения видимости, некорректная визуализация сложности шейдера на замаскированных сетках, ошибки точности теней на объектах с большими границами вблизи источников света, неработающие переходы LOD при пересечении MinDrawDistance, декали не визуализируются одним глазом в VR…
Конечно, довольно часто бывает, что ошибка выходит за рамки моих возможностей. Здесь я хотел бы поблагодарить Маркуса Вассмера из Epic, который оказал нам бесценную прямую поддержку в решении некоторых действительно серьезных проблем. На самом деле, мы хотели бы поблагодарить всех в Epic, которые помогли нам с нашей игрой. Поддержка, о которой мы просили, была уникальной в том смысле, что нам потребовались некоторые функции, которые частично даже не имеют смысла для UE4 и стали результатом того, что мы переместили игру с UE3 на UE4. И все же Epic помогала нам с каждой подобной проблемой и сделала возможным появление Итана Картера в UE4.
Наконец, хотя это и не были ошибки, я сделал несколько настроек, чтобы улучшить рабочие процессы и диагностику. Основываясь на существующем коде компиляции распределенного шейдера XGE, я создал интеграцию с SN-DBS от Sony, которая значительно улучшила время сборки шейдера (небольшое изменение, например, в шейдере базового прохода дало нам 80 тыс. Шейдеров для компиляции! Обычно, это двухчасовой перерыв в вашем рабочем дне!). Наша версия движка также замораживает переходы LOD при выполнении консольной команды FreezeRendering. Консольная команда r.CompositionGraphDebug выгружает пути к материалам постобработки в журналы, поэтому вам больше не нужно угадывать, какой из них был смешиваемым. Наша версия команды DisplayAll принимает необязательный аргумент noempty для фильтрации всех пустых значений. Я добавил команду stat релевантные огни, чтобы сбрасывать все динамические источники света, которые были визуализированы в последнем кадре. И так далее, и так далее.
Куда это идет отсюда
Вы можете сказать: «Хорошо, для порта пригодился программист графики / движка; а как насчет оригинальных игр? »
Вот где самое интересное!
Подумайте обо всех играх на Unreal Engine 3 предыдущего поколения. У вас есть всевозможные жанры, рассказы, художественные стили; но в визуальном оформлении большинства этих игр есть что-то, что сразу же выдает то, что у них есть UE3 под капотом.
Лично я думаю, что это из-за модели освещения и эффектов постобработки. Не каждый может себе позволить - или даже считать это жизнеспособным - изменить это, но подсознательно наш разум распознает, как работают зеркальные блики, световые лучи, глубина резкости, цветение и т. Д. Это не обязательно плохо, заметьте! Просто мы где-то видели это раньше.
В The Astronauts мы делаем все возможное, чтобы наши игры выглядели индивидуально. Хотя UE4 намного более гибок, чем UE3, и теперь любой игре легче, чем когда-либо, добиться собственного оригинального вида, всегда хорошо иметь расширенный контроль над своим творением. Например, и я знаю, что это может не быть чем-то, что может волновать большинство людей, но то, как отражения в экранном пространстве формируются по бокам экрана в форме трапеции, в настоящее время для меня является мертвой раздачей UE4.
Я понимаю, что возиться с эффектами постобработки и моделью освещения рискованно и амбициозно; но вся эта маленькая группа из 8 человек под названием Астронавты стремится к звездам! ;)
Первоначально опубликовано в Гамасутре 10 июля 2015 г.
