Гора в один клик: как создавались пейзажи Wildlands

Подробный разбор приёмов и инструментов разработчиков.

Какой бы ни оказалась в итоге Ghost Recon: Wildlands, одно в ней точно реализовано отлично: ландшафт. Типичные для жанра джунгли в игре сменяются заснеженными горными пиками, соляными пустынями и болотами.

DTF публикует сжатый пересказ выступления программиста графики Гийома Верле (Guillaume Werle) и технического арт-директора Бенуа Мартинеза (Benoit Martinez), которые занимались технологиями и инструментами создания ландшафта для игры.

Прежде всего — небольшое видео с демонстрацией.

Ghost Recon: Wildlands — самый масштабный игровой мир из всех, что когда-либо создавала Ubisoft. Действие происходит в Боливии, и игровая версия страны состоит из 11 совершенно разных «биомов». Реки, озёра и ручьи занимают 16 квадратных километров.

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

В игровом мире есть действующая железная дорога и 200 локаций: лагеря, особенные объекты, аванпосты и 58 полностью процедурно-генерируемых деревень.

После Ghost Recon: Future Soldier мы стали экспериментировать с более масштабными ландшафтами. Взяли реальные топографические данные и «загнали» их в DEM-файл для нашего движка.

Потом (с помощью Houdini) мы собрали инструменты для следующих целей:

1. Автоматизация создания тайленных LOD-мешей.

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

3. Определение маски сплаттинга для распределения материалов по установленным правилам, в соответствии с наклоном, высотой, жёсткостью и прочим, а также другой маски для машины генерации игрового мира вроде flowmap.

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

Мы запускали его на Yeti, движке Future Soldier. Результаты были неплохими, но нам показалось, что он несколько ограничивает наши амбиции, и мы «пересели» на Anvil от серии Assassin's Creed.

Прототип помог нам реализовать две вещи:

— Оптимизировать процесс работы с ландшафтом: оперировать мешами, постоянно перемещая их между редактором и DCC-приложением было непрактично.

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

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

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

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

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

Поскольку игрок в Wildlands может отправиться куда угодно, уровень детализации везде должен быть одинаковым.

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

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

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

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

Вот небольшая демонстрация инструмента лепки высот, в котором используется кисть «копировать/вставить» и «стереть».

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

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

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

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

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

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

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

Результат распределения материалов сохраняется в две текстуры. Первую назвали «сплаттинговой» — она содержит индексы материалов для каждой позиции в карте высот. Вторую — «перспективной», внешне она напоминает скриншот из Google Maps. Когда происходит рендеринг удалённых от игрока частей ландшафта, «перспективная» текстура используется как карта альбедо.

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

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

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

Каждый отдельный материал в управляющей графике PBR-совместим и состоит из нескольких текстур высокого разрешения, созданных с помощью Zbrush и Substance.

Также в каждый материал встроена карта деформации мешей. Сама деформация основывается на тесселяции — благодаря этому разработчикам удалось сделать так, что ландшафт выглядел как «next-gen». Речь идёт всё ещё о прототипе, однако результаты были настолько многообещающими, что разработчики решили уделить ему ещё больше времени.

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

Поэтому ближайшие к игроку 32 материала собираются в комплекс текстур. Затем с помощью специальной таблицы этот комплекс конвертируется из глобального сплаттингового индекса в индекс локального кэша. Из него и берутся текстуры во время рендеринга переднего плана.

На изображении — конечный результат. Дальше он будет пошагово разобран.

Сначала берётся сплаттинговый индекс и переводится в индекс локального кэша. Затем из него сэмплируются все PBR-текстуры.

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

Чтобы избежать неестественного растяжения текстур, на склоны накладываются двухплоскостные проекции. Дважды — по одной на оси X и Y.

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

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

Четыре элемента с двухлинейной интерполяцией находятся рядом друг с другом.

Склоны с двухплоскостными проекциями.

И последний случай — переходная зона, которую всё ещё нужно заполнять данными.

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

Так удалось сделать процесс менее требовательным к ресурсам компьютера. Сейчас примерно в 80 процентах ландшафта используется 4 материала вместо 12.

Тогда возникла новая проблема с сетью дорог. Генерировать их так же, как фрагменты ландшафта, было очень накладно с технической стороны, а если хранить их на диске, то игра может не влезть на Blu-ray.

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

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

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

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

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

Операция эта сложная, особенно если игра запущена на 4k-дисплее. Более того, при создании ландшафта Wildlands используется тесселяция, и выводится множество крохотных треугольников — если использовать однобуферную прорисовку меньшего разрешения, начнет хромать детализация.

Так что разработчики добавили дополнительную 3D-текстуру на этапе обработки через Gbuffer. Пока ландшафт рендерится с UV-развёртками и количеством mip в качестве выходных переменных, демонстрируемый игроку участок виртуальной текстуры можно менять напрямую.

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

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

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

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

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

На изображении — средние значения, сильно зависящие от характера сцены, однако можно с уверенностью сказать, что обработка укладывается в 8 миллисекунд в большинстве случаев. BC-компрессия идет параллельно.

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

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

Инструменты стали данными: они создаются и хранятся так же, как и любые другие элементы игрового мира. Инструмент — это своего рода игровая мета-сущность, которая создаёт сущности более мелкие.

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

Во-первых, инструменты разработчиков Wildlands основаны на условиях. Пользователи редактируют параметры и меняют условия, чтобы создавать контент. Во-вторых, они детерминированы: при одних и тех же условиях всегда будет получаться один и тот же результат. К тому же, с помощью этих инструментов всё создаётся только во время разработки игры, а не по ходу игрового сеанса.

Все инструменты были созданы с помощью Houdini.

Что такое Houdini? Это приложение для создания цифрового контента от SideFX. Его часто используют для создания спецэффектов, но это не наш случай — мы с помощью Houdini создавали рабочие окружения.

Для чего он? Во-первых для прототипов — через Houdini очень удобно быстро испытывать идеи. Во-вторых, как уже было сказано, с помощью него создавались инструменты. А ещё Houdini очень быстро превизуализирует и оптимизирует данные и выдаёт удобную статистику.

Почему Houdini, а не инструменты на C++/GPU? Так быстрее. На компиляцию не нужно тратить время: все инструменты — это HDA (цифровые ассеты Houdini, Houdini digital assets), так что в них легко вносить изменения, после чего модифицированная версия инструмента сразу становится доступна всей команде. Да, специально созданные инструменты могли быть быстрее, но Houdini настолько гибок, что это компенсирует некоторые потери в быстродействии.

Ландшафт в Wildlands — фундамент для всего остального, поэтому в первую очередь нужно было создать оболочку для доступа к ландшафтным данным. На изображении выше — пример части ландшафта (500 метров), перенесённой в Houdini. Для неё уже доступно несколько настроек, а ведь это только базовый слой.

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

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

Вот видео, демонстрирующее, насколько быстро и просто можно создавать инструменты в Houdini.

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

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

Теперь более детально о том, как на ландшафт накладывались остальные слои.

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

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

Поскольку всё обновляется на лету, отпадает необходимость в создании и проверке разных версий. Разработчики вообще отказались от создания версий и резервных копий и остались очень довольны результатом.

Вот видео, демонстрирующее процедурные слои:

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

Сюда же относится железная дорога с тоннелями и мостами.

Всё это работает и в более глобальном масштабе — дороги соединяются, растительность и деревни распределяются по карте и так далее.

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

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

Достаточно расположить на ландшафте несколько ключевых точек и…

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

Данные дорог состоят из следующих элементов:

1. Траектории, которые можно использовать в множестве других вещей вроде ИИ-управления трафиком.

2. Терраформинг. Текстура с картой высот, которая потом накладывается поверх ландшафта.

3. Сплаттинг. Тут получается маска текстуры для обновления данных материалов ландшафта.

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

На видео выше представлена прокладка дорог (без троп) на участке местности.

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

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

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

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

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

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

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

Демонстрация работы Settlement builder:

Инструмент для создания полей может быть использован сам по себе, а может быть включён в Settlement builder, чтобы поля появлялись вокруг поселений.

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

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

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

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

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

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

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

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

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

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

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

Более того, Houdini позволял работать даже со звуком. У дизайнеров звука появился инструмент для определения условий его распространения среди объектов и ландшафта — генерировалась специальная карта. Каждый цвет на ней — индекс отдельного звука.

Программа World Batch позволяет выполнять задачи автоматически, либо даёт доступ к любым данным, используемым в игровом мире.

World Batch основывается на версии языка python, используемой в Houdini — hython. В нём есть система распределения Hqueue от SideFX, в которой данные в виде «задач» отправляются на рендеринг. «Задача» загружает ассет Houdini в формате .otl, затем задаёт параметры, если это необходимо, и запускает процесс рендеринга из этого же .otl.

World Batch можно использовать напрямую — пользователь на карте игрового мира выбирает, что именно он хочет заново обработать, и отсылает «задачу» на свой компьютер или на машины для рендеринга. Также World Batch запускается скриптом и, если пользователь вносит изменения, касающиеся ландшафта, отсылает «задачи» сразу в Anvil на рендеринг.