[Перевод] Создание сцены из Star Wars в Unreal Engine 4
Все изображения в статье кликабельныВведение
Привет, меня зовут Джейсон Льюис (Jason Lewis). Думаю, что меня можно назвать руководителем этого группового проекта. Я главный художник по окружениям в Obsidian Entertainment. Другие художники, работавшие со мной над этим проектом, тоже работают в Obsidian. Это помощники главного художника, художники среднего класса и джуниоры. Даже люди из отдела QA дополнили сцену своими художественными навыками. Всего в работу в разной степени внесли свой вклад 17 человек. Это был наш личный проект, мы создавали его только потому, что все мы — большие фанаты «Звёздных войн». Глядя на современные работы по Star Wars, мы решили, что настало время поучаствовать и создать качественный фанатский арт-проект. Кроме того, что мы поклонники Star Wars, некоторые из нас хотели под хорошим предлогом изучить Unreal 4.
Сам я работаю в игровой индустрии уже более 20 лет, и побывал во многих студиях, от небольших стартапов в начале карьеры до самых крупных издателей и разработчиков, таких как Sony и EA. В течение этих лет я создал множество игр, самыми заметными из них стали Enter the Matrix и The Matrix Path of Neo [Shiny Entertainment], SOCOM 4 [Zipper Interactive и Sony Computer Entertainment], Medal of Honor Warfighter, DLC Battlefield 4 [EA] и Armored Warfare [Obsidian Entertainment]. В 1999 и 2000 годах я немного отдохнул от игр, поработав над телевизионным анимационным сериалом Starship Troopers. Как я сказал выше, над проектом работали и другие художники, большинство из них имеют уже более 10 лет опыта. Я хочу упомянуть некоторых из них. Это Терри Хесс (Terry Hess), ещё один главный художник, работавший над несколькими играми Call of Duty. Он также создавал Medal of Honor и Battlefield 4 в EA. Крейг Маршке (Craig Marschke), тоже главный художник серии Call of Duty из надолго запомнившейся эры Novalogic. Кен Лесэнт (Ken LeSaint) и Тэд Клевенджер (Thad Clevenger), ещё двое главных художников из разных отраслей индустрии. Брайан Лёлё (Brian Leleux), один из основных художников по освещению в Obsidian, и другие.
Наша сцена из Star Wars началась с того, что я просто хотел воссоздать в 3D «Тысячелетний сокол». Я большой фанат «Звёздных войн», и я всегда хотел смоделировать «Сокола» в компьютерной графике, но до недавнего времени у меня не было такой возможности. Сначала он был простой моделью 3ds Max, но потом я подумал, что было бы неплохо посмотреть на него в реальном времени. Тогда у меня не было опыта работы с Unreal 4, и я решил, что это будет отличным проектом для знакомства с UE4. Поэтому моей целью стало создание самой высокодетализированной модели «Сокола» в реальном времени, и мне кажется, у меня получилось. Исключением может стать модель из последней VR-демо ILM X-Labs, показанной на GDC несколько месяцев назад. Возможно, их сцена немного более детализированная, или наши сцены идут «нос в нос», но, насколько я могу судить по видео в Интернете, их корабль более точно повторяет оригинальную модель. Я же допускал вольности в детализации, чтобы модель лучше выглядела в сцене.
Сначала «Тысячелетний сокол» должен был просто стоять в стыковочном отсеке 94, чтобы игрок мог перемещаться вокруг него в реальном времени. Потом я подумал, что неплохо бы добавить интерьер отсека, и, может быть, часть окружающего его города Мос-Эйсли. Уже после этого я подумал, что можно добавить их бар из Мос-Эйсли. В этот момент я осознал, что с таким объёмом проекта я не смогу завершить его в одиночку, поэтому я пригласил несколько художников, работающих со мной в Obsidian, помочь в свободное время с проектом. Получив множество восторженных откликов, я разделил работу между волонтёрами, исходя из предполагаемых затрат времени и труда.
Сейчас мы закончили проект примерно на 90%, наша цель — завершить проект и выложить его в Интернет для свободного скачивания. Это на самом деле не игра, а, скорее, интерактивный художественный объект. Пользователь может побегать по окрестностям с бластером (или с секретным оружием, которое нужно найти). Нам не удалось заручиться помощью художников по персонажам, поэтому единственные персонажи в окружении, кроме вас — это куча дроидов-механиков и несколько дроидов питания. Также мы работаем над VR-версией, потому что некоторые участники группы уже познакомились с VR-устройствами Oculus и Vive. Мы решили, что будет здорово создать версию, работающую в VR, поэтому сейчас пытаемся завершить и её тоже.
Эта сцена — настоящий эксперимент, показывающий, насколько детализированные сцены (с точки зрения детализации полигонов и текстур) можно запускать на современном компьютерном графическом оборудовании с приемлемой частотой кадров. В результате нам удалось достичь довольно высокого количества полигонов и размеров текстур. Мы применили модульность, но на макроуровне. Здания — это экземпляры объектов, весь стыковочный отсек трижды повторно использован в уровне, несколько раз использованы некоторые пропсы, но мы не создавали модулей на микроуровне (нет наборов стен, потолков, лестниц и т.д.), почти все ассеты уникальны. Для создания композиции мы изучили несколько сцен из четвёртого эпизода Star Wars и попытались как можно лучше скопировать их с учётом ограничений, накладываемых свободной навигацией в реальном времени. Но основной упор в окружении мы сделали на стыковочных отсеках и кораблях внутри.
С точки зрения потребления ресурсов сцена достаточно «тяжёлая». Один мой «Сокол» «весит» примерно 700 000 треугольников, ещё около 500 000 ушло на стыковочный отсек и окружающие его пропсы. Есть несколько частей города, в которых количество полигонов зашкаливает за миллион. Пока мы тестировали использование ОЗУ графических карт с объёмом до 4,1 ГБ с максимальными настройками. Из-за временны́х ограничений у нас не хватило времени на создание LOD, поэтому мы передаём данные из памяти и в память небольшими частями (чанками) на основании положения игрока. Несмотря на большое количество полигонов и размер текстур, со всеми протестированными графическими процессорами сцена работала достаточно хорошо. Сейчас мы получаем 45–60 FPS на GeForce GTX 970, 980 и Titan X. Если уменьшить размер пула памяти и обеспечить более «агрессивное» мип-текстурирование, получится достичь приемлемой частоты кадров и на GTX 760 с 2 ГБ.
Мы не выполняли этап макетирования в традиционном смысле. Сначала мы создали всю сцену без текстур, а не делали низкодетальные версии ассетов для грубого макета уровня. С самого начала мы строили все модели в финальном уровне детализации, затем выполнили базовую компоновку, и перешли к созданию освещения и материалов/текстур. В процессе создания всё равно было несколько итераций, но мы решили, что пропуск этапа моделирования макетов позволит нам двигаться быстрее. Был момент, когда сцена слишком разрослась, и нам пришлось немного отмасштабировать её, чтобы нам хватило времени и имеющихся рук.
Наша сцена содержит огромное количество ассетов, и мне кажется, что благодаря этому она выглядит такой уникальной и захватывающей. Мы разбили ассеты на три категории: здания и структуры, корабли и пропсы. Как я и говорил, мы разделили их между добровольцами с учётом времени и сил, которые они хотят вложить в работу. Для ассетов пропсов я с самого начала подготовил рабочий процесс, чтобы достичь высококачественного результата с малыми затратами времени. Большинство участников воспользовалось моим процессом. Почти все мы пользуемся 3ds Max, поэтому процесс вкратце выглядел так:
- Создание финальной низкополигональной сетки.
- Создание высокополигональной сетки для запекания (высокополигональные сетки обычно использовались только для генерирования граней со скосами в картах нормалей. Мелкие детали карт микронормалей рисовались или вылепливались скульптингом в Zbrush, Quixel или Substance Painter).
- Запекание карт нормалей Tangent Space/карт Ambient Occlusion и Curvature Maps.
- Добавление микродеталей в карты нормалей, AO и Curvature Maps.
- Финальный проход текстурирования (большинство из нас использует Quixel Suite, некоторые — Substance Painter)
Здания и крупные структуры моделировались в финальном низкополигональном состоянии и импортировались в UE4 без запекания, потому что в основном на них накладывались повторяющиеся (tileable) текстуры штукатурки или металла. В большинстве материалов зданий используются текстуры, спроецированные в пространстве мира, что позволяет избавиться от затратного по времени работы с UV. Необходим только быстрый и простой проход UV для запекания освещения.
С «Тысячелетним соколом» совершенно другая история. Во-первых, нам нужно было разбить этот знаменитый корабль на несколько частей, у каждой из которых был свой уникальный материал. Финальный «Сокол» состоит из 50 уникальных сеток. Из-за большого размера и высокого уровня детализации описанные выше процессы текстурирования здесь не подходят, потому что повторяющиеся материалы не обеспечат нужного уровня чёткости, которого я пытался достичь. Однако наложение на каждую из этих 50 частей уникальной текстуры быстро бы загрузило графический процессор даже с 4 ГБ или 6 ГБ памяти, потому что все они должны иметь разрешение 4K, чтобы плотность текселей не разрушалась при близости камеры игрока к кораблю. Чтобы решить эти проблемы, я решил попробовать применить систему слоёв материалов Unreal 4. Если вы незнакомы с системой Layered Material, объясню: она позволяет создавать основные материалы с повторяющимися текстурами, определяющими разные типы поверхностей. В едином базовом материале можно соединить и смешать такие основные материалы через маски, находящиеся в пространстве сеток 0–1 UV. Это решает проблему с памятью графического процессора благодаря использованию повторяющихся текстур размером 1K для определения всех типов поверхностей, и одной текстурной маски размером 4K для каждой части «Сокола» вместо трёх текстур 4K для каждой части корабля. Наложение повторяющихся материалов слоями с масками смешивания обеспечивает гораздо лучший уровень чёткости по сравнению с результатами использования традиционных повторяющихся материалов. Недостаток системы слоёв материалов заключается в бóльшей по сравнению с традиционной настройкой материалов трате ресурсов на пиксель, что приводит к повышению нагрузки на графический процессор.
Выше я слегка коснулся создания материалов, и сейчас мы рассмотрим его более подробно. Процесс работы над материалами в основном зависит от того, к какой категории отнесена его сетка (структуры/корабли/пропсы). Для зданий и структур мы используем повторяющиеся материалы с текстурами в пространстве мира. Система привязки в пространстве мира UE4 работает достаточно хорошо и позволяет нам создавать такие ассеты быстрее. При этом не тратится время на сложные UV, которые требуют очень аккуратной настройки, чтобы при наложении не было много швов. Проецирование в пространстве мира отлично смешивает изогнутые поверхности. Конечно же, иногда возникают случайные швы, но они не вызывают проблем. Преимущества в скорости намного перевешивают возникающие случайные швы или ошибки проецирования. В дополнение к повторяющимся материалам все текстуры также смешиваются с глобальной картой нормалей и картой AO, определяющими базовую форму и силуэт каждой из структур.
Самый большой корабль в окружении, «Тысячелетний сокол», использует вышеупомянутую систему слоёв материалов. Я пробовал экспериментировать с использованием системы слоёв для ассетов пропсов меньшего размера, но понял, что время на настройку и дополнительная нагрузка на графический процессор от такой системы себя не оправдывают. Для ассетов, которые меньше набора деталей нашего главного героя, такая система не нужна. Художник, создававший имперский челнок, сначала планировал использовать систему слоёв материалов, как в «Соколе», но он потратил много времени на свою модель, поэтому решил выполнить стандартный рабочий процесс с диффузными картами, картами нормалей, шероховатостью и металлическим блеском. Система слоёв материалов хоть и очень эффективна, но занимает немного больше времени по сравнению с традиционной настройкой текстур.
В ассетах пропсов используются довольно простые настройки материалов: базовая диффузная карта/карта нормалей и одна текстура в градациях серого для шероховатости, металлического блеска, AO и карты отражений. В шейдер мы поместили множители для отражений и шероховатости, чтобы настраивать значения матовости/глянцевости любой текстуры без возврата к переработке текстур. Кроме того, мы используем на уровне множество излучающих материалов, создающих красивые области яркого света, дополняющие действительное освещение. Также для материалов мы часто использовали трюк с узлом flipbook UE4. Можно создать текстурный атлас анимированных спрайтов, сообщить flipbook, сколько строк и столбцов в атласе, и он будет циклически менять эти кадры спрайтов. С помощью узла умножения можно настроить скорость воспроизведения этих спрайтов узлом flipbook. Я использовал flipbook для всего анимированного освещения на панелях управления и консолях.
В основном наши текстуры создавались процедурно с помощью Quixel Suite (и небольшой помощью Substance Painter). Большинство из нас хорошо владеет Quixel, потому что мы используем его в Obsidian. Часть добровольцев сделала для сцены Мос-Эйсли набор преднастроенных «умных» материалов, которым мы поделились с остальной командой, чтобы ещё больше ускорить создание текстур. Приблизительно 70% текстур сделано в Quixel/Substance, остальные — это фототекстуры из Интернета и личных коллекций. Большинство повторяющихся текстур для таких поверхностей, как стены зданий, штукатурка, грязь, песок и земля, взято из фотографических карт.
После первого грубого прохода освещения в этой сцене я быстро осознал, что создание освещения для этого окружения будет довольно большой задачей. Поэтому когда один из наших художников по освещению в Obsidian предложил заняться светом, я сразу передал всю работу по освещению ему. Вот что он может сказать по освещению в сцене Мос-Эйсли:
Небольшие источники света в «Соколе», проходах, на панелях и т.д. используют узел материала для управления силой bloom и запечённого глобального освещения (Global Illumination, GI) каждого подматериала отдельно. Поэтому освещение вдоль проходов может иметь бóльшую силу отражения света по сравнению с источниками света на панелях. Их значение bloom занижено и для усиленного bloom при постпроцессинге больших источников, таких как солнце и огни стыковочного отсека.
В остальной части сцены, поскольку она на 95% находится под открытым небом (или представляет собой интерьеры с проёмами), я работал с одним доминирующим направленным светом, стремясь к значению освещения реального мира с точными цветовыми температурами*. Как только доминирующий источник света был настроен, я перешёл к работе с настройками Lightmass (я использовал многие настройки из форумных тем об архитектурной визуализации, из редактора и без изменений файлов .ini). Сделав первое запекание, я посмотрел, где нужно разместить дополнительное освещение для увеличения освещённости в углах, а где нужно ещё больше глобального освещения. После завершения окружения я начал работать над интерьерами. Основная часть источников света в сцене для окружения была статической, потому что мне нужна была только их цветовая информация (без отражений) для дополнительного GI или для выделения разных областей. Все источники света, влияющие на игрока, являются статическими для дополнительных запекаемых элементов, но с динамическими тенями для тех ассетов, которым они требуются. Динамические GI или AO не использовались, потому что они были довольно проблематичными, когда я начинал работать с освещением. Туман создавался с помощью обоих типов тумана, имеющихся в UE4. Атмосферный туман хорошо срабатывает, когда нужно придать статическому скайбоксу больше глубины и цвета, связанного со временем суток. Туман, основанный на высоте (height based fog), придаёт ощущение пыльной сцены, расположенной в низине. Этот туман ни к чему не привязан и используется во всей сцене, а также в паре объёмов некоторых интерьерных пространств. У глобального тумана вносились изменения в зернистость, bloom, хроматическую аберрацию, виньетирование, тональную компрессию и выдержку. В отдельных интерьерных объёмах использовались те же настройки с незначительными изменениями цвета и выдержки.
*Метод заимствования значений освещения из реального мира в UE4 не всегда идеален, потому что часть значений освещения невозможно воссоздать в редакторе. Также есть другие факторы, вносящие изменения в замеры, такие как кубические карты, туман и другое освещение, поэтому в течение разработки уровня освещение менялось. Но мне всё равно понравилось начинать с замеров базового освещения, потому что обычно оно довольно быстро создаёт нужное впечатление и позволяет художественно изменять его позже, в процессе финального прохода.
РекомендацииМожно дать много полезных советов менее опытным людям, если они не знают с чего начать или на чём сосредоточиться, начиная большой или малый проект. Вот набор советов, собранный мной и другими добровольцами, работающими над этим проектом:
- Чтобы быстро выполнять работу и сохранять хороший темп, сосредоточьтесь сначала на общей картине. Широкими мазками кисти создайте формы и композицию, а уже потом переходите к мелким деталям. В деталях легко запутаться, и начав с них, вы затормозите процесс разработки и отодвинете во времени реализацию своих целей! Найдите способы производства, походящие именно вам. Я видел много форумных постов о правильных и неправильных способах работы, но лучше игнорируйте их. Нет ничего правильного или ошибочного в творчестве. Будьте открыты к другим методикам, которым вас учат, потому что они могут повысить ваши навыки. Но в конечном итоге, если процесс подходит вам и результат имеет нужный вам уровень качества, вы поймёте, что всё делали правильно!
- Понимание физически корректного рендеринга (PBR) может сделать всё гораздо проще при сборке сцены. Использование любого из современных инструментов для текстурирования (таких как DDO или Substance Designer/Painter) значительно ускорит процесс текстурирования и позволит вам быстро получить достаточно точные материалы. Унифицирование и подстройка материалов под сцену поможет вам, когда настанет время работы с освещением. Оно тоже является чрезвычайно важным аспектом окружения (но здесь я могу быть пристрастен). Не бойтесь погрузиться в техническую сторону создания окружений. Осознание влияния освещения на материалы, разницы между двумя проекциями кубических карт, тремя типами источников света и создаваемыми ими различными типами теневых карт сделает работу с освещением гораздо менее мучительной. При создании освещения также помогает знание теории цвета, потому что она позволяет улучшить сцену благодаря использованию соотношения цветов в имеющихся ассетах текстур. Нужного настроения сцены можно достичь просто сочетанием цветов, не изменяя интенсивность освещения.
- Мы не советуем новичкам начинать с проектов такого размаха. Он может только подавить их. Начинайте с небольших проектов, работайте с друзьями и коллегами, чтобы распределить задачи. Даже если каждый внесёт в сцену один-два ассета, постарайтесь взять от каждого элемента максимум. Разберитесь с процессом создания настоящих PBR и используйте универсальные материалы, украшенные декалями, чтобы вдохнуть в них жизнь. Неэффективная структура может сэкономить ваше время, но тогда проект сложнее будет запустить на компьютерах среднего уровня. Качество и скорость всегда в разных сторонах спектра, поэтому сделайте выбор в самом начале проекта и соответственно планируйте работу.
- Цитата художника, работающего над имперским челноком: «Я работал над челноком «Лямбда» и решил сделать его немного отличающимся от всех других. Я выполнял более традиционные высокополигональное и низкополигональное запекание. Оглядываясь назад, я уверен, что можно полностью пропустить высокополигональный этап и с самого начала работать над финальной сеткой». Экономия времени стоит того, если вы не планируете показывать красивую высокополигональную модель в своём портфолио. Для получения хороших скосов, обычно достигаемых запеканием высокополигональных моделей, можно использовать разные другие техники. В Maya и Max есть способы использования шейдера для получения скруглённых углов твёрдых поверхностей, которые сэкономят вам кучу времени. Также существуют потрясающие новые инструменты, позволяющие просто создавать скосы всех твёрдых граней и быстро изготовлять высокополигональные объекты.
- Убедитесь в точности пропорций. Если они не совпадают, ассет будет выглядеть неправильным. Даже если игрок не сможет точно сказать, в чём ошибка, он будет осознавать, что с ассетом что-то не то.
Пусть у ваших ассетов будет История. Нужно не просто сделать дверь и покрасить её красным. Подумайте, что случилось с этой дверью. Какого цвета она была раньше? Сколько раз её перекрашивали? Кто или что пользовалось этой дверью? Их одежда была из металла или из ткани? Дверь открывалась пинком или аккуратно? Всё это создаёт историю двери. Она сделает ваш ассет бесконечно интереснее. При этом ассеты вместе создадут гораздо лучшую композицию.
Спасибо, что нашли время познакомиться с нашим проектом. Если вам интересно, как проект эволюционировал с самого начала, у нас есть об этом статья на polycount, показывающая, как выглядел проект на ранних этапах.
Если же вам захочется скачать его, ссылки представлены ниже. Проект довольно требователен к системе: для приемлемых FPS мы рекомендуем не менее 16 ГБ системной ОЗУ и графическую карту не хуже Nvidia GTX760 (или аналогичной версии AMD). Для больших FPS и разрешений до 2560×1440 или 2560×1600, мы рекомендуем использовать как минимум Nvidia GTX970 и выше (или их аналог производства AMD).
Проект можно скачать здесь:
- Зеркало 1
- Зеркало 2
- Зеркало 3
- Зеркало 4
Комплект скриншотов в сверхвысоком разрешении можно скачать здесь.
Комментарии (1)
MikeLP
20 октября 2016 в 15:05
0↑
↓
Хорошая работа проделана. Очень похоже на то что сейчас есть в Star Wars Battlefront.
