Как создавалась The Order 1886

20 февраля 2015 года вышла The Order 1886. Игра, в жанре приключенческий боевик от третьего лица, которая была разработана студией Ready at Dawn (при поддержке SCE Santa Monica), эксклюзивно для платформы PlayStation 4.

Несмотря на то, что игра получила довольно смешанные отзывы от критиков (63 балла на Metacritic) и обычных игроков (пользовательский рейтинг 6.7), нужно действительно постараться чтобы найти обзор или рецензию, в которой не будет отмечена отличная работа художников и дизайнеров. И это неудивительно, ведь даже спустя почти 7 лет, после релиза, The Order 1886 по-прежнему выглядит весьма впечатляюще и может легко составить конкуренцию современным проектам, во всём что касается качества картинки.

В этой статье вас ждёт множество подробностей, связанных с процессом разработки The Order 1886. Вы узнаете какие именно технологии и подходы использовали разработчики, при создании одной из самых красивых и кинематографичных игр в истории современного геймдева.

Студия Ready at Dawn (RAD) была основана в 2003 году, в городе Ирвайн, штат Калифорния (США), бывшими сотрудниками Blizzard Entertainment (Ру Верасурия, Андре Пессино) и Naughty Dog (Дидье Маленфант и др.).

До The Order 1886, студия, в основном, занималась разработкой под платформу PlayStation Portable. За время своего существования, она успела разработать несколько оригинальных игр для таких крупных франшиз Sony, как Jak and Daxter и God of War.

Выпущенные проекты: Daxter (2006), God of War: Chains of Olympus (2008), и God of War: Ghost of Sparta (2010). Последние две игры были портированы на PS3 и выпушены как God of War: Origins Collection (2011).

Разработка проекта стартовала в самом начале 2011 года. На тот момент, в компании было около 45 человек. На самом пике производства количество сотрудников выросло до 140 человек. Всего над проектом успело поработать боле 1500 человек (1458 разработчика и 183 благодарности).

По задумке разработчиков всё должно было происходить в реальном времени, от начального меню до заключительных титров. Это означало полное отсутствие более качественных кинематографических ресурсов. Всё будет работать «в живую» на PS4 с внутриигровым контентом.

Основной проблемой для небольшой (на тот момент) команды стало то, что это был их первый проект подобного уровня (первый оригинальный IP). Было очень сложно сделать резкий переход от разработки под PSP, к разработке под PlayStation 4 (команда пропустила два поколения железа). Необходимо было с нуля написать новый движок и все инструменты. Разработать и внедрить новые методы/подходы к разработке контента, в соответствии с современными стандартами индустрии. Кроме того, для команды это был совершенно новый жанр (как для разработчиков), а новый художественный стиль проекта, требовал значительно более высокого уровня детализации и реализма.

Основные цели на этапе препродакшена:

Движок RAD Engine с самого начала был ориентирован на платформу PlayStation 4, однако он может работать и на платформе Windows (с использованием API DX11). Билд под Windows использовался в основном как инструмент разработки/тестирования и для рендера, который был встроен прямо в Autodesk Maya 2014 (DX11 Viewport 2.0).

Подобный подход позволил использовать Maya как основной редактор уровней, что очень удобно для обычных художников. Материалы, частицы, блики от источников света, всё это и многое другое можно было создавать и редактировать прямо в Maya. Ядро фреймворка, использующееся всеми инструментами, было написано на C++ и Qt.

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

Из множества особенностей RAD Engine можно выделить детальное планирование задач, низкую нагрузку, использование многопоточного буфера команд.

Одной из самых больших проблем при переходе на платформу PS4, стала передача огромных объемов данных, необходимых для хранения ассетов, размер которых стремительно вырос по сравнению с предыдущими играми. Можно сказать, что Многопоточная Система/Конвейер Сборки (Build System) является одним из основных компонентов технологии RAD, и у команды технических специалистов ушло много сил и времени на её разработку (также написана на C++).

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

О подсистеме рендеринга (не углубляясь в технические подробности), расскажет ведущий графический программист Дэвид Ньюбелт (David Neubelt).

В самом начале проекта, у нас было всего 2 графических программиста, в последствии их количество увеличилось до 5. Мы перешли от Light Pre-Pass Rendering, к традиционному отложенному рендерингу c «толстым» G-Buffer'ом, а затем к тайловому отложенному шейдингу (tiled deferred shading) с использованием вычислительного шейдера (compute shader). Примерно в 2012, мы закончили с пробами упреждающего тайлового рендера (tiled forward rendering), который приобрёл популярность благодаря демонстрации Forward+ от AMD.

На тот момент у нас было около 5 или 6 G-буферов для хранения всех параметров материала, необходимых для шейдинга различных BRDF. Переход на Forward Rendering позволил нам облегчить эксперименты с моделями освещения, без необходимости постоянно перестраивать наш G-буфер. Кроме того, он имеет некоторые благоприятные характеристики касающиеся производительности графического процессора PS4, особенно при использовании MSAA (а мы очень любим MSAA!). Мы до сих пор не придумали модель освещения области (area light) в реальном времени, которой мы бы были действительно довольны. Поэтому, к сожалению, у нас ещё нет источников света с динамической областью (dynamic area lights).

Нашей стандартной (используемой по умолчанию) функцией распределения зеркальных микро-граней является модель Кука-Торренса (Cook-Torrance). Мы используем модель Кука-Торранса, в некоторой форме, уже почти 3 года. В качестве терма распределения мы используем GGX распределение из статьи Walter’а от 2007 года. Для обеспечения нормализации BRDF, мы используем G терм (Matching Smith G term) из той же статьи. Для аппроксимации вклада фактора Френеля используется приближение Шлика (Schlick’s approximation) Что касается диффузной составляющей освещения мы используем стандартную модель Ламберта. Чтобы сбалансировать его с нашей «зеркальной моделью» мы умножаем его на величину, обратную зеркальной интенсивности.

Движок позволяет использовать и другие BRDF, в зависимости от контекста:

Движок поддерживает динамические источники освещения и запечённый свет. Карты освещения (Lightmaps) содержат информацию о непрямом освещении от точечных источников света + прямое/непрямое освещение от неба и источников света типа Area lights. Мы запекали их с помощью NVIDIA OptiX на ферме под управлением Linux, на которой установлены видеокарты GTX 780. Работа с освещением будет рассмотрена более подробно ближе к концу статьи.

Поскольку базовая версия PlayStation 4 оснащена всего 8Gb памяти (из них 3.5Gb резервируются операционной системой), разработчикам нужно было уместить все необходимые ресурсы в 4.5Gb. Распределение памяти под разные ресурсы в Order 1886, выглядит следующим образом:

* Весь бюджет на текстуры распределяется между окружением, персонажами и объектами. Именно в этой области разработчикам приходилась выходить за рамки в виде 2 GB памяти.

** Даже у персонажей были данные о картах света.

Весь арт имеющий отношение к окружению имеет плотность текселя (TD) 512 пикселей на единицу (1 единица = 1 метр).

Стандартное разрешение тайловой текстуры для окружения равно 1024x1024.

О разработке продвинутой системы материалов, методах композинга, моделирования, освещения и множестве других интересных вещей, расскажет Нэйтан Фэйл-Лифф (Nathan Phail-Liff), арт-директор проекта.

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

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

Кроме того, визуально мы хотели добиться точного и достоверного рендеринга. Что обычно не ассоциируется с играми (в прошлом). Мы сделали особый упор на попытку получить действительно точные отражения в материалах и освещении. Мы хотели быть уверенными, в том, что наши модели освещения и материалов будут сбалансированными, и будут работать таким образом, чтобы улучшать и дополнять друг друга.

Что касается области окружения, мы также хотели расширить наш набор инструментов, чтобы иметь возможность отображать вручную собранный мир из модульной геометрии и крайне эффективных, тайловых текстур (в основном).

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

Во время работы над The Order 1886, мы разработали много действительно крутых технологий и пайплайнов, но одним из наших крупных успехов стал пайплайн для создания материалов.

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

Итак, коснемся нескольких общих целей.

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

Мне кажется, что создание вспомогательных карт шейдинга, таких как шероховатость (roughness), интенсивность Френеля (fresnel intensity) и отражение (specular), не очень подходит для текстур, создаваемых вручную. Художник может сделать любой ассет, который будет великолепно выглядеть в отрыве от всего, но стоит вам задействовать большую команду, в которой каждый художник создает свои собственные текстуры с нуля, и вы получите явную несогласованность и дрейф качества по мере роста производства.

Лично для меня, идеальная система — это когда художник может cказать:

«Я хочу, чтобы здесь был металл, вот здесь он потускнел, а вот здесь скопилась пыль»

Это по-прежнему очень творческий процесс, просто более интуитивный и понятный, чем управление интенсивностью пикселей на карте.

Так как же мы решили эту проблему? Сначала мы настроили правила для базы данных с шаблонами материалов.

Для нас шаблоны определяют только клиническую реакцию шейдинга в исследуемых материалах. Мы накладывали на них карты типа basic color и specular в качестве основы, не добавляя при этом никаких художественных вариаций.

Наши шаблоны, никогда не войдут в игру, ни в какой форме. Вы можете заметить поперечный скос (cross bevel) на карте нормалей у всех наших шаблонов. Это гарантирует, что ни один художник случайно не использует их в игровом ассете.

Для достижения согласованности шейдинга во всей игре, шаблоны поддерживались только одним художником.

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

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

Здесь показано, как мы стандартизировали наименования материалов. Мы позаботились о том, чтобы каждое название было лаконичным и относительно точным по отношению к реальному материалу. Любые «мусорные» названия вроде «shiny metal» немедленно выбрасывались из библиотеки.

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

На самом деле, такой подход оказался чрезвычайно удобным, поскольку позволил нам начать с небольшого количества вариантов. При необходимости, мы могли вставлять дополнительные шаги, не переименовывая уже существующие материалы. Кроме того, таким образом, мы исключили возможность неприятных «сюрпризов» для художников, использующих существующие шаблоны по цепочке. Мы никогда не начинали с предельных значений (extremes). Как правило, значения 075 и 025 являются базовыми.

Всё это, приводит нас к Библиотеке Общих Материалов (Common Materials Library). Это первый этап, на котором вводятся некие художественные вариации.

Итак, двигаясь вниз по цепочке в нашей общей иерархии материалов, шаблоны (templates), которые я только что описал, наследуются вплоть до того, что мы называем нашими Общими Материалами (common materials).

За эти общие материалы отвечает команда, которая занимается текстурами для окружения.

Все реакции шейдинга (shading response) в каждом пикселе Общего Материала исходят из шаблонов. Унаследованные параметры шейдинга никогда и ни при каких условиях не буду разблокированы.

Общие Материалы всё еще не используются в игре напрямую.

Даже если бы в конкретном окружении можно было использовать определенный Общий Материал (как он есть), художник всё равно унаследует версию уровня (level version).

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

Несколько примеров наиболее распространенных общих материалов из нашей библиотеки:

Хорошо, так как же нам связать все эти чистые шаблоны с каждым пикселем в общем материале? Мы делаем это через нашу Систему Композинга Материалов (System of Material Compositing).

Её можно сравнить с системой слоёв для материалов в Photoshop. Каждый слой поддерживает привязанную (linked) альфа-маску, но вместо одной двухмерной текстуры, как в Photoshop, каждый слой комбинирует полные свойства шейдинга. Художники могут контролировать такие вещи как тайлинг, степень прозрачности, режимы наложения/смешивания, а также вклад каждого канала в шейдинг, например, интенсивность карт Specular, Diffuse или Normal.

На первый взгляд, всё это может показаться дорогим удовольствием, но это не так. Наша система сборки материалов (material build system) превращает все эти слои в однослойную внутреннюю текстуру всякий раз, когда она сохраняется или создается. «Под капотом» эти текстуры упакованы намного эффективней, чем если бы художник вручную создавал каждую карту шейдинга самостоятельно.

Таким образом, если у вас есть, к примеру, 100 составных слоёв, в этом нет ничего страшного. Конечным результатом по-прежнему будет обычный плоский материал в выбранном вами конечном разрешении.

Итак, возвращаясь к нашему обзору иерархии материалов. Вы видели, как начиная с простых шаблонов мы можем создать большую базу данных состоящую из Общих Материалов (более продвинутых в художественном плане).

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

Это невероятно мощный инструмент, так как все усилия нашей команды, направленные на создание тайловых материалов, доведенных до совершенства, одновременно помогают в текстурировании всей игры целиком.

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

В нашем случае Материал = Текстовый ассет. У нас есть свой собственный язык данных, который мы называем radattr, и мы используем его для большинства наших ассетов. Язык radattr поддерживает типы, наследование, мета-данные и UI layouts.

Наследование, по сути, позволяет нам создавать «базовые» ассеты, а затем выводить из них данные для создания новых ассетов. Затем, в новом ассете можно переопределить выбранные значения, что является простым способом создания различных вариаций одного и того же материала. Если в базовый/основной материал вносятся изменения, они распространяются на все дочерние.

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

Производство материалов основано на функциях. → Нет шейдерных деревьев (shader trees)

Наш Material Editor — это инструмент для редактирования в реальном времени. → Можно разместить прямо внутри Maya.

Референсные файлы материалов (reference files) содержат шейдерный код. Когда мы собираем материал, мы извлекаем исходный код и добавляем новый код, специфичный для этого материала. Этот код содержит жёстко-запрограммированные константы для параметров материалов, определение текстуры и семплера, буфер констант для анимируемых свойств и некоторый код который используется для помощи в маршрутизации текстур к любой функции материала, которая их использует.

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

При разработке паплайна для окружения, наши цели заключались в следующем:

Мы не собирались изобретать велосипед, поэтому мы взяли всё то, что хорошо работало в прошлом, и сделали «небольшое» обновление.

Большинство тайловых текстур было создано в Zbrush. Карты Normal и Height наиболее важны для нас, и наилучший результат мы получаем именно в Zbrush.

Из Zbrush мы экспортируем: Color map, Normal map, Height map, ID map

Из этих карт мы создаём: Occlusion map, Composite Masks

Большинство наших Общих Материалов и материалов окружения имеют размер 1024x1024.

Композитные/составные материалы упаковывается в четыре текстурные карты (Color with alpha, Normal, Specular, Roughness).

prp_well_pump_c_tarnished_copper_source

В отличии от функции композинга, которая является в большей степени офф-лайновой, система смешивания слоёв работает прямо в процессе выполнения (at runtime).

Она поддерживает до 4 слоёв на материал, при этом каждый слой имеет полное наследование и поддержку композинга.

Обычно художник берет слой из base material asset, что позволяет ему быстро собирать многослойные материалы из совершенно уникальных ассетов материалов.

Вклад каждого слоя в первую очередь определяется назначенным каналом цвета вершин, который используется вместе с картами наложения/смешивания (blend maps) и картами высот (height maps) для определения конечного альфа-значения (alpha value).

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

Здесь вы можете увидеть пример работы нашей системы слоёв во время выполнения, на одном из наших тестовых уровней. Базовый слой представляет собой тайловый материал кирпича, который сам по себе будет выглядеть скучно и однообразно. Чтобы немного разбавить его однородность и внести разнообразия, поверх кирпича засыпается слой густого цементного раствора. Наконец, у нас есть слой влаги и воды, который добавляется поверх раствора и кирпича. Поскольку действие нашей игры происходит в Лондоне, мы часто используем мокрые кирпичи и камни.

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

Теперь рассмотрим ещё один пример:

А вот и финальный результат.

Обрамления (Skirts) — это меши, которые мы накладываем на непрозрачную геометрию (более известны как декали).

Обрамления использовались для таких вещей, как:

Мы очень часто используем декали на поверхности земли.

Декали рендерятся только над непрозрачными материалами. Они немного дороже чем непрозрачные (opaque), но дешевле прозрачных (transparent) с точки зрения производительности. При этом многослойные материалы тоже могут быть декалями.

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

Мы пришли к выводу, что одно обычное ребро (edge) с разделенными нормалями вершин не работает так как надо. Они выглядят слишком жесткими и нереалистичными, по сравнению с качеством наших материалов. Поэтому, мы перешли к фаскам с двумя ребрами, с кастомным набором нормалей вершин (custom set vertex normals).

После ряда тестов мы сформировали набор пресетов и рекомендаций, для создания фасок в зависимости от масштаба создаваемого объекта.

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

Это же подход мы использовали и при моделировании органики.

Преимущества данного подхода:

· Высококачественные модели без чрезмерного количества полигонов.

· Снижение количества «одноразовых» ассетов с запеченными картами.

Недостатки данного подхода:

· Нужно создать инструменты для работы с Custom Vertex Normal.

· Большинство нормалей должны редактироваться художниками.

· Увеличение количества суб-пиксельных треугольников (sub-pixel triangles)

Итак, мы рассмотрели композинг материалов, многослойные материалы, декали и моделирование. Теперь мы соберем все эти части вместе.

1. Внутриигровая модель без карты нормалей

2. Многослойный материал: базовый слой Varnished wood (Лакированное дерево)

3. Многослойный материал: второй слой Varnished wood dark (Тёмное лакированное дерево)

4. Многослойный атериал: третий слой пыль и повреждения

5. Теперь добавим декали и набор аксессуаров (accessory set). Аксессуары в данном случае являются одноразовыми запеченными ассетами.

Ниже вы можете увидеть, как именно построены наши сцены. Зеленым цветом показаны уникальные «запеченные» ассеты.

Требовалось относительно простое решение для быстрого добавления в движок высококачественных детализированных карт (detail maps). Первоначально, мы изучали готовые решения, но обнаружили, что большинство методов лазерного сканирования слишком шумны и имеют недостаточно высокое разрешение. Мы разработали собственный сканер материалов, основанный на технологии стереофотометрии (photometric stereo techniques), для захвата деталей поверхности (нормалей) с высокой точностью.

Сканер имеет специальный контроллер света, подключенный к ПК. ПК управляет освещением и камерой, для синхронного выполнения снимков. Изображения последовательно сохраняются на ПК, сразу после того, как будут собраны все 10 изображений от 10 различных источников света, запускается программа для расчёта Normal/Albedo.

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

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

Здесь вы можете посмотреть, как одна и так же игровая сцена (круглый стол в Вестминстерском Дворце) выглядит с пост-обработкой и без неё, и понять насколько она важна для нашего проекта.

Вот список всех используемых здесь полноэкранных эффектов. Мы не будем вдаваться в подробности, относительно каждого из них, поскольку, говоря откровенно, в них нет ничего новаторского:

Tone Mapping, Exposureы, Bloom, Fog, Air Density/Fog Blur, Screen Tint, Color Grading, Lens Flare, Lens Dirt, Lens Distortion, Depth of Field, Bokeh, Motion Blur, Chromatic Aberration, Film Grain, Vignette.

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

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

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

Всё это приводит нас к тому, что нам необходима балансировка освещения и экспозиции.

Эта концепция позволила нам разделить локальные источники света и небо между сценами и получить согласованные результаты между экспозицией камеры, интенсивностью неба и эффектами частиц, и всё это должным образом сбалансировать в HDR.

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

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

Здесь вы можете увидеть несколько тестовых сцен, которые использовались нами для стандартизации значений освещения и экспозиции, в самом начале проекта. Это был весьма важный процесс, поскольку нам нужно было точно знать, что у нас есть подходящий HDR подход, который не зависит от каких-то отдельных настроек материалов, для каждой сцены. В частности, это было важно для излучающих (emissive) поверхностей, таких как лампочки, поскольку мы хотели, чтобы они выглядели убедительно как в тёмных, так и в светлых областях игры. Скриншоты были сделаны с помощью рендерера, встроенного в Maya. Они немного устарели, но всё еще неплохо демонстрируют используемый GI пайплайн.

- Середина дня, интенсивность излучения света: 50.000, экспозиция HDR: -4.4

- Облачно, интенсивность излучения отраженного света: 1000, экспозиция HDR: -2.0

- Закат, интенсивность излучения света: 20.000, экспозиция HDR: 2.2

Чтобы показать пример баланса экспозиции и цветокоррекции (grading) в действии, возьмем сцену за круглым столом:

Первая вариант. Сцена взята из более ранней части игры, во время дневного собрания рыцарей.

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

Третий вариант. Вечерняя сценв. Теперь освещение выглядит совсем по-другому. Но, на самом деле это не так. Все, что здесь произошло, это замена неба на его ночную версию, солнечный свет в окнах был выключен, а экспозиция была доведена до нашего ночного диапазона (для интерьеров). Осветительные приборы, которые вы видите, те же что и в дневных сценах, но с более высокой экспозицией камеры и более низким значением окружающего освещения (ambient light) они воспринимаются более яркими.

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

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

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

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

Если у нас появлялись проблемы с производительностью из-за определенного прибора, мы могли быстро решить проблему отредактировав один источник и распространив изменения на все уровни сразу.

Здесь у нас несколько образцов светильников из нашей базы данных. Художники по свету, начинающие работу над новым окружением, могут просто покопаться на нашем «складе» светильников чтобы найти что-то подходящее и потратить больше времени на работу с тоном, композицией и настроением сцены, вместо того, чтобы изобретать колесо снова и снова.

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

По студии ходила шутка, что в нашей базе данных у нас было более 100 уникальных светильников и только 3 уникальных дивана. Суть в том, что это не было шуткой.

Стоит обратить внимание на то, что они так же предварительно упакованы вместе с отбалансированными эффектами на основе частиц. У нас даже были «дождливые» варианты, которые имитировали более высокую плотность дождя и освещение капель рядом с источником света, а также воду, стекающую по плафону самого светильника.

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

Это видео снято на раннем этапе препродакшена, поэтому значения эмиссии света и HDR абсолютно не совпадают с теми что использовались в финальной версии игры. Тем не менее, оно хорошо описывает концепцию того, как мы тестировали и выводили эти гайдлайны.

Здесь, я вкратце (не вдаваясь в технические детали) расскажу о наших функциях объемного освещения (volumetric lighting) и методах их применения.

Учитывая сеттинг: викторианский Лондон времен промышленной революции, мы особенно хотели, чтобы ощущение «густого» воздуха стало ключевым элементом нашего мира.

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

Мы использовали тонны объемных источников в каждой сцене этой игры. Часто, довольно неожиданным образом. Мы ненавидим игровой линейный туман (linear fog) и стараемся как можно чаще заменять его вольюметриками.

У нас часто было около 50 (или более) объемных источников света, поэтому мы старались зарезервировать самые дорогие функции, такие как тени и гобо (gobo), для небольшого количества источников света, которые оказали бы наибольшее влияние на сцену.

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

Теперь быстро пройдёмся по нашим основным типам объемных элементов:

1. Воздушные источники света (Air lights) используются в центре локальных источников света для имитации однократного рассеивания точечного света через среду. В нашем случае, среда управляется плотностью линейного тумана, умноженной на интенсивность самого точечного света. Поскольку такие источники довольно дёшевы (в плане производительности), мы также использовали их в качестве общих объемов тумана (fog volumes), скрывая точку интенсивного излучения за стеной или полом.

2. А вот здесь наш точечный источник света (spot lights) с включенным световым лучом/видимый поток света (light shafts). В них нет ничего особенного, кроме того, что мы чертовски оптимизировали их. Без включенных теней, к концу проекта мы в целом могли обходиться всего лишь 3-4 фрагментами (slices) для любого из них.

3. А вот тот же самый точечный источник света с включенными тенями от световых лучей. Здесь нам требуется большее количество фрагментов, чтобы избежать некрасивой ступенчатости, поэтому такие элементы несколько дороже, и мы должны быть осторожными с их применением.

4. И, наконец, точечный источник света с включенными тенями и текстурным гобо (texture gobo). Для этого, потребуется ещё большее количество фрагментов, поэтому мы использовали их только тогда, когда они действительно были нужны чтобы оказать большое влияние на игрока, например, на фонарях, используемых непосредственно в игровом процессе.

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

Ниже приведено несколько примеров, с целью показать вам, как важна функция объемного освещения для наших сцен.

В качестве динамических источников освещения (работающих в Runtime) наш движок поддерживает следующие типы: Directional (Направленные), Point (Точечные), и Spot (Конусные). Мы используем много динамических источников света и располагаем множеством замечательных функций для получения высококачественных результатов, но они не особо интересны, поэтому мы их пропустим, чтобы сэкономить время. Еще, мы используем капсулы окклюзии (Occlusion Capsules) для затенения окружения, которые рассчитываются во время рендеринга геометрии, «на лету». О них мы поговорим ближе к концу статьи.

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

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

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

1. Финальное изображение. Первое, что вы можете заметить, это множество действительно тонких, но богатых отражений.

2. Render Pass: Dynamic Light. Здесь показано всё динамическое освещение. В основном это мягкие объемные источники и небольшие локализованные источники света вокруг свечей. Фактически, единственная причина, по которой свечи являются динамическими, заключается в том, что они могут иметь анимированное мерцание, а также влиять на SSS-материал воска.

3. Render Pass: Ambient Diffuse. Это диффузная составляющая освещения.

4. Render Pass: Ambient Specular. Большая часть зеркального отражения в этой сцене на самом деле запечена.

5. Render Pass: Reflection Probes. Данный пасс показывает расположение датчиков/зондов для захвата отражений.

6. Render Pass: Reflection AO. И, наконец, зависящая от точки обзора окклюзия окружения для отражений (reflection AO), которая используется в качестве occlusion pass для зондов.

Для запечённого освещения мы используем световые карты (light maps), хранящиеся в виде Spherical Gaussians. Это очень важно для внешнего вида нашей игры, и я остановлюсь на этом, для более подробного рассказа.

В дополнение к нашим стандартным источникам света, у нас есть area lights (плоский источник света/аналогичен софтбоксу) для запеченного освещения, а также небесные и эмиссионные материалы. Ещё у нас есть reflection probes (зонды отражения), которые по сути являются локаторами, которые мы размещаем в сцене для рендеринга отражений в виде кубической карты из этого места. И наконец, у нас есть Reflection AO (окклюзия окружения для отражений), которая тоже упаковывается в формат световой карты.

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

Они по-прежнему являются для нас важной частью уравнения освещения, но определенно имеют некоторые проблемы.

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

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

Кроме того, Reflection AO применяется ко всем динамическим объектам в игре, таким как оружие и персонажи. Здесь вы можете увидеть пример дугового ружья с выключенным Reflection AO.

Его можно убрать из запекания, если это необходимо (для определенных материалов или полигонов) с помощью Vertex Color. Несмотря на то, что Reflection AO хранится в статической карте освещения, она по-прежнему правильно применяется, в зависимости от вида (точки наблюдения).

Преимущества Reflection Probes

· Они отлично захватывают зеркальные отражения.

К сожалению, у них много недостатков.

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

Что касается кубических HDR карт, каждый зонд требует значительных затрат памяти на сэмпл.

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

1. Это изображение отлично иллюстрирует данную проблему. Нельзя сказать, что всё выглядит совсем ужасно, но тут определенно есть тот плоский, тусклый диффузный внешний вид, который часто бывает проблемой при использовании методов освещения в реальном времени.

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

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

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

Так что же мы делаем на самом деле? Вместо того, чтобы сохранять запечённое освещение как сферические гармоники (Spherical Harmonics), мы переключились на формат Spherical Gaussian, что позволило нам сохранять освещение, зависящее от точки наблюдения, в виде фиксированного набора направлений на сфере. Для экономии времени я опущу технические подробности (с ними можно ознакомиться в презентации Advanced Lighting R&D at Ready At Dawn Studios).

1. Данный пример очень хорошо демонстрирует разницу в качестве. Здесь изображено состояние игры, которую мы впервые показали на E3 в 2014 году. Мы долго ломали голову над тем, чтобы заставить SG работать, но они всё ещё не работали.

2. На следующем изображении показана сцена с включенными SG. Здесь слишком много улучшений, чтобы перечислять их все. У нас повсюду много приятно скользящего света, но теперь с правильным затемнением. Ещё лучше то, что на самом деле мы НЕ ПОЛУЧАЕМ света. Все странные светящиеся края от кубической карты в дальней, укрытой стене и на потолке исчезли.

И ещё несколько сцен в качестве примера:

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

Здесь очевидно, что металлические конструкции становятся более читаемыми. Обратите внимание, сколько тонкостей присутствует в поверхностях стеновых панелей. Теперь каждая складка и изгиб взаимодействует со светом.

Теперь воздействие природного света, скользящего по вертикальным поверхностям, ощущается намного сильнее. Хотя, блеск и блики на илистой влажной земле, пожалуй, имеют наибольшее влияние на восприятие картинки.

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

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

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

Здесь вы видите, как при использовании кубических карт, все маленькие блики на позолоченных деталях полностью исчезли.

Из всего этого, можно сделать следующий вывод. Если бы мы использовали только кубические карты, все усилия, которые художник по текстурам приложили к проработке деталей (протестированных в условиях динамического освещения), были бы потрачены в пустую.

Очевидно, что SG карты освещения имеют много преимуществ.

Из недостатков:

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

Учитывая, что в системе используется много приближений, мы предоставили художникам по свету полный контроль над этими пороговыми значениями, чтобы они могли сбалансировать переходы между зондами и SG, а также настроить резкость и интенсивность SG.

Мы смягчили потребление памяти, позволив художникам по свету сами выбирать разные значения для количества зеркальных лепестков (lobe counts), чтобы у них была возможность сбалансировать качество картинки и количество потребляемой памяти в соответствии с потребностями их сцены.

В качестве последнего пункта в рассказе о запекании SG я покажу визуализацию тепловой карты, демонстрирующую смешивание SG и зондов (используется для отладки).

Учитывая, что SG облегчает нагрузку на GPU, по возможности мы старались максимально снизить обрезание SG на 100%.

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

На этом примере хорошо показано как работают капсулы Ambient Occlusion.

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

Ниже показаны основные пассы из которых состоит конечная игровая картинка.

1. Запечённое освещение (Диффузная составляющая).

2. Запечённое освещение (Зеркальная составляющая).

3. Освещение от динамических источников света и солнца.

4. Альбедо.

5. Запеченная Направленная окклюзия. К сожалению, костюм и оружие игрока претерпели некоторые изменения, а карта окклюзии не была запечена заново. Вот почему он весь белый.

6. Динамическая капсула AO

7. Отладочный режим, показывающий количество источников света, пересекающих каждый тайл размером 16x16. В основном, это говорит о том, насколько дорогим будет освещение. Зеленый — это хорошо, синий — это нормально, красный — плохо, а белый означает, что мы не можем с этим работать.

На этом, рассказ о создании The Order 1886 (в рамках данной статьи) подошёл к концу. Несмотря на объём статьи «за кадром» осталось огромное количество материала и интересных подробностей, о которых хотелось бы рассказать. Но... редактор статей DTF уже еле дышит и вот-вот вывалится с какой-нибудь критической ошибкой. Возможно, когда-нибудь свет увидит вторая часть с акцентом на продакшен персонажей и их анимацию.

Подводя некий итог, хотелось бы отметить что опыт Ready at Down наглядно показывает всю важность грамотного планирования, выбора удачных решений на стадии препродакшена и наличия RnD процессов.

В статье использовались материалы следующих докладов:

GDC 2014 Crafting a Next-Gen Material Pipeline for Order 1886
SIGGRAPH 2015 The Environment Art and Material Pipelines of The Order: 1886
SIGGRAPH 2015 Rendering The Alternate History of The Order: 1886
SIGGRAPH 2015 PBS Advanced Lighting R&D at Ready At Dawn Studios

Автор текста: Константин Пономарёв