Как Stink Studios создала Джона Льюиса "Моз - монстр - Создатель монстров"

Мэтт Гринхал, технический директор

Техническое образование

Оживление на веб-странице Moz the Monster, звезды рождественской кампании Джона Льюиса 2017 года, представило Stink Studios ряд технических проблем:

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

Ниже мы более подробно рассмотрим, как мы подошли к этим целям ...

Мех в реальном времени

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

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

Альтернативный метод был разработан для использования в реальном времени и представлен в этом техническом документе NVIDIA. Одной из характерных черт этой техники является то, что она создает множество копий оболочки базового меша. Чем больше этих ракушек и чем меньше промежутки между ними, тем меха более мелкий и реалистичный. Мы решили создать базовую сетку для Moz the Monster с ~ 5000 вершинами и допустить до 15 слоев оболочки с общим максимальным количеством вершин 80 000. Числа, которые должны с комфортом отображаться как на нижнем уровне на старых мобильных устройствах, так и с максимальным качеством на графических процессорах более высокого уровня со всеми включенными слоями оболочки.

PBR и кастомные карты меха

Реализовав базовую технику рендеринга меха, нам нужно было адаптировать ее, чтобы создать особый вид меха монстра. Мы собирались использовать Three.js, чтобы предоставить интерфейс для WebGL для рендеринга монстра в браузере. Three.js предлагает поддержку текстур PBR через конвейер шейдеров MeshStandardMaterial. Итак, мы знали, что можем как-то поддержать внешний вид меха, создав изображение BaseColor, чтобы передать серый и коричневый цвет меха и поддержать это с помощью карт Roughness и Normal, чтобы дать правильный световой отклик на окружающие огни и обеспечить базовый уровень детализации базовой сетки. Мы дополнили это картами Ambient Occlusion и Metalness, первая из которых обеспечивает дополнительное затенение в закрытых областях, а вторая - слегка изменяет внешний вид зубов, глаз и ногтей Монстра. Эти карты были основаны на скульпте, созданном в Pixologic ZBrush, который затем был нарисован в Allegorithmic Substance Painter.

Чтобы обеспечить необходимый нам контроль над внешним видом меха, мы создали три дополнительных карты: первая представляла собой простую маску, которая помогала во время рисования меха в опыте и определяла, какие области были мехом, а какие нет. Во-вторых, мы создали карту «Длина меха», которая показывала, какой длины должны быть пряди меха в каждом конкретном месте, и предотвращала появление волосатых глазных яблок у Монстра Моза - смущающий вид. Наконец, мы создали карту «Mottled», которая придавала тонкие изменения оттенка базовому цвету меха, чтобы он выглядел органично даже во время интерактивного процесса рисования.

С этими картами, сложенными вместе, у нас было все необходимое для рендеринга Монстра Моза с помощью меха. Но чтобы выделить основные моменты в прядях и придать им объемность, мы дополнили Ambient и очевидный Spotlight над Moz двумя небольшими картами окружения. Одна 16-битная кубическая карта HDR для обеспечения мягкого освещения по краю меха и одна крошечная 8-битная карта в оттенках серого для создания дополнительных отражений света в его глазах.

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

Деформируемая буровая установка и морфинг-цели

Изначально монстр был смоделирован и анимирован в Lightwave. Отчасти из-за требований к рабочему процессу, а отчасти из-за набора навыков команды мы также использовали Blender как инструмент шлюза для объединения элементов, добавления текстур данных и управления экспортом в Three.js.

Анимация Moz the Monster была довольно простым упражнением по экспорту меша со скелетом с базовой анимацией на основе арматуры. Мы создали восемь дополнительных форм / целей морфинга (на языке Blender / Three.js) для поддержки обычных вещей, таких как моргание глаз, а также более продвинутых функций, таких как добавление дополнительных зубов ко рту монстров и поддержка как тонкой, так и толстой версии. Сами по себе эти функции не вносили слишком много сложностей, но ключевым творческим требованием было то, что дети должны уметь создавать монстров разных форм и размеров. Перед нами стоял выбор: создать множество сеток и арматур, но иметь ограниченный набор анимаций для каждой, или создать одну сетку и арматуру и потратить усилия на анимацию для создания множества интересных анимаций за счет более ограниченной возможности деформировать эту основу. сетка.

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

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

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

Рисование динамических текстур в реальном времени

Другая ключевая часть опыта потребовала от нас предоставить детям возможность рисовать цвета и узоры на их монстрах. Создание этой возможности потребовало преобразования лучей против UV-текстуры, чтобы обеспечить координаты выбора ввода с помощью мыши / касания на нашей UV-карте для монстра. Имея их в руках, мы смогли добавить цвет в пустую текстуру, используя маску кисти. Затем эта текстура была объединена в шейдере фрагментов с другими картами - AO и, в частности, с нашей пользовательской картой Mottled, чтобы сохранить органичный неоднородный вид Moz the Monster.

Двоичный gLTF

В дополнение к довольно большим текстурам, мы знали, что базовая сетка и данные анимации для Monster могут быстро увеличиваться до проблемно больших размеров файлов. Мы провели раннее исследование доступных форматов, чтобы обеспечить обмен данными между нашими пакетами 3D-моделирования и Three.js. gLTF был одним из первых фаворитов. Этот относительно новый формат обещал небольшие размеры файлов с поддержкой всех функций, которые мы искали, и для Blender был доступен как Exporter, так и Importer для Three.js. Ранние тесты анимации скелетного меша и поддержки морфинга выглядели хорошо, поэтому мы продолжили разработку.

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

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

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

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

Оптимизация под мобильные устройства

Произнесите слова «мех в реальном времени», и графические процессоры повсюду трепещут. Техника принципиально сложна для любого устройства. Наше раннее доказательство концептуальной работы продемонстрировало, что мы можем достичь 30 кадров в секунду на устройствах iPhone 6 поколения, если будем поддерживать низкое количество оболочек. В конечном итоге мы решили провести неофициальное профилирование хост-устройства, чтобы определить, какие функции WebGL оно поддерживает. Затем мы сгруппировали устройства в диапазоны - низкие, средние и высокие - и постепенно включили более детальный рендеринг меха и сложность освещения с каждым шагом в диапазоне.

Когда мы доработали нашу спецификацию, обнаружилась пара проблем. Одна сразу очевидная проблема заключалась в том, что мы непреднамеренно вышли за рамки 8 текстур, чтобы определить различные параметры монстра. Многие мобильные устройства и планшеты имеют ограничение в 8 текстурных блоков на сетку. Нам нужно было найти способ упаковать наши текстуры в меньший блок. Но мы уже упаковали наши карты Ambient, Roughness и Metallic в отдельные каналы R, G и B, а также для нашей пользовательской текстуры Transparency / Fur. Решением было объединить карты BaseColor, Normal, MetallicRoughness и TransFur в единую массивную текстуру 8K, по одной в каждом квадранте. Затем мы могли бы использовать UV-ссылки в диапазоне от 0 до 0,5 и от 0,5 до 1 для адресации правильной текстуры. Или мы могли бы, если бы Three.js позволил нам это сделать, чего в стандартной версии нет. Один из наших разработчиков WebGL провел особенно героическое путешествие на поезде домой, настраивая шейдер Three.js Standard, чтобы он соответствовал этим пользовательским UV-ссылкам.

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

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

Заключение

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

Вы можете узнать больше о предыстории проекта, а также о том, как мы создали версию Moz the Monster с дополненной реальностью, на странице нашего тематического исследования здесь:

Https://www.stinkstudios.com/work/john-lewis-moz-the-monster-monster-maker