Создание 3D-моделей для мобильной игры: опыт Playkot

Сложности работы с аутсорсерами и ограничения платформы.

На конференции DevGAMM 2017 разработчики Age of Magic из компании Playkot рассказали о создании 3D-моделей персонажей для мобильной игры на всех этапах разработки: от идеи до оптимизации. Редакция DTF расшифровала выступление.

Даниил Козловский: Я арт-лид в проекте Age of Magic. Это игра для мобильных устройств от Playkot, которая напоминает карточную. Но у нас настоящие герои со своими способностями и внешним видом. Их можно собирать и прокачивать в сюжетной кампании, PvP и других активностях.

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

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

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

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

При переходе от 2D к 3D моделлер может неправильно уловить пропорции, исказить характер или силуэт. Поэтому мы стали использовать 3D-скетч — быстрый, черновой «скульпт», который делает сам концепт-художник в программе ZBrush. На его пропорциях и силуэте будет базироваться финальная модель. Скетч делают без лишних деталей и подробных текстур.

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

Мы получаем 3D-скетч на пятый день работы над персонажем, а готовый продукт — только через месяц. Весь период производства модели мы спокойны за её качество и за то, как она впишется в мир игры.

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

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

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

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

Антон Ивичев, глава 3D-продакшна: я расскажу, что идёт после 3D-скетча и какие критерии качества мы предъявляем к финальной высокополигональной модели.

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

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

У высокополигонального «скульпта» более 20 миллионов полигонов, а на его создание уходит пять дней. Здесь помогает использование заранее заготовленных деталей (таких как руки и ноги) и то, что многие модели делаются на аутсорсе.

Следующий этап — создание упрощенной версии героя. В Age of Magic она состоит из 4-6,5 тысяч полигонов. Именно эту модель позднее добавят в игру, поэтому необходимо продумать точки артикуляции и оптимизировать её с сохранением визуального качества.

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

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

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

Затем идет риггинг, а потом — скиннинг — привязка низкополигональной модели к скелету. На первом этапе автоматизировать процесс помогут скрипты, а на втором— плагин ngSkinTools.

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

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

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

Начнем со сборки. На мобильных устройствах «размер» приложения влияет на скорость загрузки, на то, как быстро разряжается телефон или планшет и на то, как много людей скачают вашу игру. Если взять готовые ассеты, то каждый персонаж будет «весить» около 73 мегабайт. Умножаем это на 70 героев и получаем порядка пяти гигабайт. Это слишком много для мобильной игры.

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

В случае с Android всё гораздо сложнее. На этой операционной системе работает множество устройств, для каждого из которых оптимален свой формат компрессии. Мы собираемся написать специальный скрипт, который займётся созданием сборок на разные устройства. Для этого в Unity есть возможность выбрать Texture Compression. Скрипт же позволит Google Play проверять все возможные версии приложения, и предлагать ту, которая поддерживается устройством.

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

Для компрессии анимации и звука мы используем встроенные средства Unity. Инструмент Keyfame Reduction даёт очень хороший результат: он «сжимает» исходные данные в шесть-восемь раз. Если важен момент проигрывания звука, то мы используем Vorbis, потому что MP3 запускается с задержкой порядка 30 миллисекунд.

В итоге каждый персонаж занимает до 5 мегабайт. 70 героев в таком случае будут «весить» около 350 мегабайт.

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

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

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

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

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

Вопрос из зала: Можете ли вы подробнее рассказать о сроках выполнения работ на каждом этапе?

Даниил Козловский: Процесс создания концепт-арта у нас занимает неделю или полторы, в зависимости персонажа. Этому, конечно, предшествуют некоторые дизайнерские поиски.

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