Star Wars Battlefront и искусство фотограмметрии

Как в игре воссоздавались знаменитые локации из киносаги.

В 2016 году на конференции GDC разработчики Star Wars Battlefront из студии DICE подробно рассказали об опыте использования фотограмметрии, начиная от организационного процесса и заканчивая созданием собственных конструкторов уровней.

DTF публикует расшифровку выступления.

Участники:

— Кеннет Браун, технический арт-директор Battlefront.

— Эндрю Хэмптон, ведущий художник по окружению, ответственный за фотограмметрию в Star Wars Battlefront.

Кеннет Браун: Итак, фотограмметрия. Для тех, кто не знает, это использование фотографий для измерений и, в нашем случае, для создания текстур и моделей. По сути процесс выглядит так:

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

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

Потом добавим немного о совмещении обычных ассетов (assets) с фотосканированными, создании ландшафта, наших конструкторах уровней, а в конце будет быстрое подведение итогов.

Сначала о крупных изменениях в индустрии, которые случились, когда мы решили заняться этим проектом. Во-первых, появилось новое поколение консолей. Battlefield 4 вышел на четвёртом поколении консолей, но эта часть Battlefront стала нашим первым эксклюзивом для текущего поколения — Xbox One и PS4.

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

А вот с какими трудностями мы столкнулись.

Во-первых, это «Звездные войны», всеми любимая франшиза. Каждый знает, как выглядят ключевые локации вселенной, так что от нас, как от разработчиков, ожидали очень многого. У нас было много прошлых наработок, которые мы хотели применить. Также фотограмметрия расширила границы качества и скорости, и нам надо было понять, как работать с этой новой технологией в условиях очень сжатого графика разработки. К тому же мы хотели, чтобы игра выдавала 60 кадров в секунду. Не 45-50, а 60, а те, кто «в теме», знают, насколько это непросто. Однако у нас получилось.

Нужно было, чтобы всё это прорабатывалось параллельно. Соответственно, проекты нужно было координировать так, чтобы работа каждого сотрудника продолжала труд другого.

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

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

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

Эндрю Хэмптон: Фотограмметрию мы использовали не впервые. До этого с её помощью создавали элементы экипировки персонажей в BF3 и всякие камни в BF4, но поскольку Battlefront мы хотели сделать настолько хорошо, насколько это возможно, то и фотограмметрию использовали чаще.

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

Вот несколько рендеров игровых ассетов. А борода на правой модели…

КБ: Моя. И я этим очень горжусь.

ЭХ: После Battlefield мы старались использовать сканирование по максимуму — хотели закрыть качественный разрыв между фотосканированными персонажами и их окружением. А целью нашей было, разумеется, создать самую красивую игру по Star Wars, которая ещё шла бы при 60 кадрах в секунду. Времени было крайне мало.

Это уровень из Battlefield 3: Armored Kill, который мы старались сделать выглядящим как можно более реалистично. Фотограмметрией и другими подобными техниками мы тогда не пользовались, ограничившись обычными методами.

Итак, в ходе этой презентации мы расскажем, как от предыдущего изображения перешли к этому:

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

C собой мы брали только самое простое оборудование, поскольку хотели быть мобильными: Canon 6D, 24-миллиметровые линзы, штативы, таблицы цветов и так далее. Погоду мы контролировать, очевидно, не могли, но всё равно старались подгадать лучшие условия. Перед поездками на локации мы тщательно планировали, что нужно снять, чтобы не разбираться на месте впопыхах.

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

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

Каких-то особенных советов у нас нет, всё довольно стандартно, но когда ты работаешь в поле, забыть о них легко. Это оверлаппинг (overlapping), который способен разрушить хороший скан, если о нём забыть, необходимость снимать объекты со всех углов и избегать теней, ведь естественное освещение потом можно легко убрать.

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

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

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

КБ: Я иногда не могу отличить снимки реальной природы от игровых скриншотов. Ребята очень постарались.

ЭХ: Мы собрали много разных видов текстур поверхности земли. Также заметьте, что каких-то особо примечательных объектов тут нет — так и было задумано, ведь мы создавали очень ограниченный набор ассетов. Нужно было убедиться, что их будет легко менять и вращать при создании окружения. Мы даже собственные окопы с Хота копали.

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

Из поездок мы возвращались с огромными объёмами данных, которые приходилось сортировать вручную. Это было ужасно, в будущем надо будет что-то с этим сделать. В итоге с локаций мы возвращались с более чем 100 тысячами фотографий, 2 тысячами ассетов и 14 часами видеосъемки. Напомню, всё это мы разбирали вручную, на что уходило много времени.

КБ: Итак, у нас есть данные, пора с ними работать. Прежде чем перейти к описанию рабочего процесса, давайте разберёмся с вопросом, который нам задавали многие — неужели с фотограмметрией работа идет быстрее? Кто-то говорил, что нам придётся тратить в два раза больше времени, а кто-то считал, что работа ускорится вчетверо. Так что мы составили такой график:

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

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

Теперь непосредственно к рабочему процессу.

Сначала берутся исходные фотографии и прогоняются через Photoshop с плагином Camera Raw. Там мы убираем виньетку, но оставляем дисторсию (lens distortion), потому что Agisoft с ней легко справляется. Затем калибруем цвета, исходя из таблицы. Этот этап, кстати, удалось серьёзно улучшить — специалисты из EA Capture Lab разработали новый метод более точной и быстрой цветопередачи. Также это хороший пример этапа, который стоит бы автоматизировать.

После того, как снимки откалиброваны, с ними можно работать. Также мы натягиваем маски (masks) на все ассеты, чтобы их изолировать — так получаются более стабильные результаты. «Запекание» (baking) объектов мы делали высокополигональным (high-poly), а местности — ультраполигональным. Стоит заметить, что во втором случае файлы получаются просто огромными.

Блендинг (blending) мы использовали мозаичный, а не обычный, поскольку в Agisoft так получались более чёткие результаты. Также в Agisoft, да и при фотосканировании в принципе, UV-развёртки (UVs) будут очень рваными. Чтобы исправить это, мы использовали стороннюю программу Zbrush, либо можно попробовать высокополигональное «запекание».

Меши мы брали либо высокого разрешения, либо низкого, если прогоняли их через программу MeshLab. Также некоторые меши дорабатывались художниками через Topogun. Детальные текстуры мы добавляли позже, чтобы на UV-развёртках было как можно меньше растяжения. С UV-развёрткой вообще надо было работать осторожно, чтобы текстуры деталей правильно друг с другом совмещались, иногда мы даже делали дополнительную UV-развёртку для подгонки.

Через XNormal мы работали с цветами, касательными и объектными нормалями (tangent/object normal), картами высот, AO и шероховатостей. Объектные пространственные нормали мы использовали как маску, чтобы убирать естественное освещение и тени, вместе с картами AO и шероховатостей. Есть и другие техники, но нас в этой все устраивало.

Углубимся немного в процесс удаления естественного освещения. 16-битная глубина — ваш лучший друг, поскольку именно так получается максимум информации о цветах. Также пользуйтесь плагином Camera Raw, чтобы убирать как можно больше из исходных снимков — там даже есть слайдер для теней, который хоть и не всегда эффективен, но всё равно полезен. Как только тени убраны, двигаемся к освещению, не забывая про карты объектных пространственных нормалей, они тоже — ваши лучшие друзья.

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

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

Теперь у нас есть базовые данные.

Пара слов о плотности текселов (texels). Для тех, кто не знает, тексели — это элементы изображения текстуры. Изначально они были для нас проблемным моментом, потому что мы получали данные в высоком разрешении. И такие, мол, ну давайте использовать 8K- или 16K-текстуры, ведь чем больше, тем лучше. Я продемонстрирую это на скриншотах — все они сделаны в разрешении 1080р, чтобы показать отношение между текселями и экранными пикселями.

Итак, 1080р, внизу вы видите линейку с цифрой 512 — это количество пикселей на этом участке экрана. Работа эта очень ранняя, и белые квадраты на камне это текстуры на 512 текселей, а красные, кажется, на 32. Вообще же на этом кадре 25 текселей приходятся на один пиксель, то есть гораздо больше, чем можно сгенерировать.

Тут их всё равно слишком много.

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

Ещё одна сторона: мы получаем очень качественные данные — нам просто не нужно такое высокое разрешение. На картинке вы видите два камня с 4K-текстурами, ассеты которых занимают 55 мегабайт. Затем 1K-текстуры, занимающие 3,7 мегабайт. Разница практически незаметна.

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

На четвёртом поколении консолей у нас есть 800 мегабайт памяти для текстур, а одна 8K-текстура занимает 90 мегабайт, так что без сжатия никуда.

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

Так выглядит наш комплекс текстур с обычными параметрами отражения и цвета — в середине расположена сама текстура. А в выделенной ячейке — умножающая функция (чтобы индекс был от 0 до 5 для большей вариативности). Мы загоняем туда текстуру в градации серого, показатели цветов которой умножаются на эту функцию и в результате получается пять разных вариантов обработки. Например, для коры исходный показатель яркости — 25%, если умножить его на функцию, получится 1, то есть второй индекс, если начинать с нуля.

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

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

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

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

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

Что делать тогда? Как выровнять качество ассетов? Сейчас я и расскажу, как мы совместили фотосканированные ассеты с обычными.

Эта технология помогла нам сократить разрыв между фотосканированными ассетами и обычными, сделать качество картинки более ровным. В детали о том, как работает PBR (Physically Based Rendering), я вдаваться не буду. Замечу, что у нас была возможность поучиться у тех, кто уже работал с PBR — Criterion, Guerilla games, Dontnod и так далее. Одной из проблем перехода на новую технологию стало то, что когда на неё переключаются все, это может затруднить рабочий процесс. Кому-то она не нравится, для кого-то просто непривычна — в итоге разработчики начинают работать с ней на полную катушку гораздо позже. Однако были и те, кто легко переключились на PBR и повели за собой остальных. Тут дело ещё в том, что с PBR нет никакого компромисса — его в студии используют либо все, либо никто.

Теперь о пользе, которую приносит PBR. Главное: все ассеты подходят друг к другу. Однако их всё равно нужно подгонять в зависимости от сцены. PBR основан на физике, а не на 100% соответствует всем её законам, поэтому нужно было искать идеально подходящие именно для нас физические значения, на которых основывался рендеринг. Ещё мы постоянно обновляли информационную базу PBR, чтобы качество результатов было стабильным.

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

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

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

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

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

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

Вот два примера с отключенной и включенной деформацией мешей. Кстати, помимо неё мы применили деформацию ландшафта и высот, что мы тоже подхватили у разработчиков Dragon Age. Форму для деформации на ландшафте мы выделяли с помощью маски. Для нас эта функция, как бы тривиально она не звучала, была крайне важна — у нас ведь по картам ходили огромные AT-AT, и мы хотели, чтобы они оставляли следы на поверхности, особенно на снежном Хоте.

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

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

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

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

Ландшафт стал последней серьезной головоломкой.

ЭХ: У движка Frostbite есть серьёзная система создания ландшафта. Для Battlefront мы делали пространства площадью примерно 8 на 8 километров, из которых игрокам было доступна только область площадью 1 на 1 километр. Затем мы ставили на задний план дополнительные меши ландшафта. Отмечу, что все текстуры были сняты с реальных локаций. Еще мы ограничили количество слоев, чтобы производительность оставалась на высоком уровне, так что приходилось отбирать только самые важные типы поверхностей.

Во времена Battlefield 3 и 4 мы часто работали с WorldMachine, и она нам отлично подходила. Но, поскольку в Battlefront мы использовали много фотосканированных персонажей и объектов, нужно было убедиться, что их ассеты правильно соединяются с реалистичным окружением.

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

На изображении вы видите наши расширенные декорации. Всё это — меш, состоящий примерно из 70 тысяч треугольников. Во время работы над Battlefield мы создавали уровни на узких ограниченных участках, но раз уж мы решили, что Battlefront будет выглядеть реалистично, то надо было сделать правдоподобными и отдалённые части окружения вплоть до 40 километров от центра карты. Пришлось поработать с туманом и прочими подобными эффектами.

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

В нашем случае чёткие изображения получались при низком ISO и высоких значениях диафрагмы. Снимки были немного зернистые, но это гораздо менее проблематично, чем если бы грани объектов на них были замылены (blurred). И ещё раз повторюсь: мы не снимали сложные поверхности вроде травы, это просто того не стоило.

Вот несколько примеров наших снимков снега:

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

Теперь немного о тесселяции (tessellation) ландшафта. В Battlefield её не было, так что для нас она в новинку. Качество картинки значительно выросло, особенно деталей при приближении, так что пути назад у нас нет, мы лучше пожертвуем чем-то еще. Тесселяции было достаточно на дистанции 15 метров от игрока — на первый взгляд немного, но когда во время игры ты бегаешь в столь детальном окружении, этого вполне достаточно. А дистанция тесселяции ведь серьезно сказывается на производительности.

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

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

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

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

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

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

КБ: Вообще, наши художники работают очень быстро — то, что вы видели, снято в замедленном времени.

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

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

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

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

КБ: Теперь поговорим о том, что мы из всего этого вынесли. Крайне удачным оказалось то, насколько мы были подготовлены перед началом продакшена. На пре-продакшен ушли месяцы, но зато перед началом самого продакшена у нас были практически готовы конструкторы уровней. Практически. Это было очень правильное решение, потому что, как бы мы ни любили делать прототипы, отвечать на вопросы менее креативных сотрудников было непросто. Что значит «насколько интересным будет этот элемент», нам уже весело! Конструкторы уровней полностью решили эту проблему — за весь продакшен я ни разу не слышал фразу «это, конечно, круто, но давай посмотрим, когда оно будет готово».

ЭХ: Да, поскольку наши поездки на локации были хорошо спланировали, в результате мы получили чёткие и структурированные ассеты.

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

ЭХ: Было очень важно закреплять планеты за определенными дизайнерами — они сначала ездили на локации, собирали данные, обрабатывали их, а потом сами же и создавали из них уровни. Мне кажется, такая структура рабочего процесса оказала ключевое влияние на стабильность результатов работы.

КБ: Работа с PBR принесла очень весомые плоды. Кстати, насчет унификации показателей и поддержания стандартов PBR — у меня есть небольшая история. В случае Эндора все значения яркости были на 30% больше, чем надо, но заметить это было сложно, потому что экспозиция все компенсировала. В результате, уровень оказался неожиданно тёмным, и мы долго не могли понять, почему. Только после pics capture мы увидели, что яркость завышена. Так что всегда проверяйте все значения.

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

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

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

Вопрос: Привет, мне стало интересно, как вы делали грани деревьев, мох или кромки сугробов. Это все деформация или просто карты?

ЭХ: Ну, деревья до 20-метровой отметки это всё обычные меши с деформацией…

КБ: Он же о мхе.

ЭХ: А, о мхе?

КБ: Да, и вопрос это очень интересный.

ЭХ: Ну, это обыкновенные карты.

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

Вопрос: Привет, очень крутую работу вы проделали. Расскажите немного о том, как вы оперировали топографическими данными и делали блендинг между ландшафтом и объектами с вашими комплексами текстур.

ЭХ: Ну, топографические данные мы искали очень долго. Много где за них просят деньги, и немаленькие. Но есть сайты вроде opentopography.org, которые отдают данные бесплатно, если указать их в титрах. Они собирают данные из остальных бесплатных источников, при этом постоянно появляются более точные топографические снимки — за этим нужно следить, чтобы работать со свежей информацией. А что касается блендинга…

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

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

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

КБ: А их больше и нет.

ЭХ: Да, мы показали вам все элементы сцены.

Вопрос: Привет, вы не думали использовать фотограмметрию для неприродных объектов, например, индустриальных или архитектурных?

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

КБ: Но иметь доступ к этим объектам было очень важно для создания правильных пропорций.

ЭХ: Безусловно.

Вопрос: Отличная презентация! У меня два вопроса. Когда вы снимали обычные предметы реквизита, не получалось ли, что вы тратили слишком времени на столь мелкие объекты?

ЭХ: Да не особенно. Мы делали от 200 до 300 снимков одного предмета реквизита — несколько оборотов вокруг него, на разной высоте. Этот диапазон цифр мы и определили как самый подходящий.

КБ: Можно вспомнить о программах вроде Reality Capture — самой передовой на рынке, мы ей пользовались, и результаты впечатляют. У них есть такая функция: можно сделать несколько снимков, а потом импортировать дополнительные, что позволяет сканировать постепенно. Так что процесс получается более гибкий.

Вопрос: Теперь второй. Вот у вас есть данные, и вы начинаете с ними работать. Было ли такое, что они оказались чрезмерно обработанными, как это иногда делает MoCap? Что вы делали в таких случаях?

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

КБ: Это еще зависит от того, какую цель себе поставить. Мы стремились к максимальной правдоподобности объектов, так что старались их не трогать.