Особенности разработки обучающего VR-сервиса на Unity

Продакшн-директор студии VR-AR Lab Денис Тамбовцев написал материал о том, как команда разработчиков системы обучения в виртуальной реальности Speech Center, выигравшая одну из номинаций на прошедшем в начале июне соревновании Oculus’ Mobile VR Jam 2015, реализовала Speech Center, с какими трудностями пришлось столкнуться создателям, и какая участь ждёт платформу в дальнейшем.

Совсем недавно закончился Oculus’ Mobile VR Jam 2015, в котором сотни команд разработчиков из разных частей мира создавали проекты для очков виртуальной реальности Samsung Gear VR.

Два проекта студии VR-AR Laboratory вошли в список финалистов, а один из них — Speech Center — выиграл в номинации Silver Prize в категории Apps or Experiences, попутно принеся студии призовые $30 тысяч.

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

Концепция

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

В версии для Oculus’ Mobile VR Jam была представлена вводная лекция, посвященная публичным выступлениям, открывающая курс, где пользователи смогут в прямом смысле прочувствовать, как заинтересовать публику своим выступлением, научатся успокаивать себя, концентрируясь на отдельных персонажах в зале и окажутся в других интересных ситуациях на сцене.

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

Обучение в виртуальной реальности и функциональность сервиса

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

1. Преимущество подачи обучающего материала в VR.
2. Концепция инфраструктуры VR-сервиса.

Преимущества подачи обучающего материала в VR

Если сравнить человека, обучающегося чему-либо перед компьютерным монитором, и человека в очках виртуальной реальности, то какие плюсы могут быть во втором случае?

Погружение

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

Новый уровень визуализации

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

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

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

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

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

Концепция инфраструктуры VR-сервиса

Как доставлять VR-контент пользователям, как не выходя из VR выбирать, сортировать и использовать его? Как его монетизировать? Все эти темы мы разбирали, продумывая оболочку Speech Center.

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

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

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

Разработка

Работа сразу была разделена на три блока, которые велись параллельно:

• проработка сценария для вводной лекции;
• разработка окружения и персонажей для сценария;
• работа над концепцией оболочки сервиса.

Сценарий

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

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

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

Озвучка

Сразу после написания сценария начались поиски студии звукозаписи.

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

Сборка сценария

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

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

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

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

Работу аудиокодеков, предоставляемых операционной системой Android, пришлось синхронизировать с аудиодвижком Unity, что доставило немало хлопот. Следует отметить, что здесь есть ещё над чем поработать, так как в итоге производительность всей системы кодирования аудио влияет также на FPS в приложении.

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

Основная же часть времени в сборке сценария ушла на добавление в сцены графики окружения с персонажами и их отладку.

Окружение

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

У нас был ряд высокополигональных сцен под визуализацию. В очках Gear VR в качестве экрана используется телефон Samsung Galaxy Note 4. Поэтому нам потребовалось оптимизировать контент таким образом, чтобы можно было показывать графику в Unity на мобильной платформе.

Прежде всего необходимо было замерить производительность устройства — например, количество треугольников, «покрытых» простейшим шейдером (unlit texture), которое может отобразить смартфон, не проседая ниже 60 FPS.

Далее измеряются более специфичные вещи — например, в нашей задаче нужно было рассадить персонажей — это Skinned Mesh. По результатам измерений выяснилось, что зал, забитый персонажами в виде Skinned Mesh, не позволяет получить приемлемый FPS. Соответственно, от Skinned Mesh мы отказались в пользу статичных персонажей, «рассаженных» в подготовленные позы.

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

Из этих экспериментов мы получили оценку максимального количества треугольников из расчёта на сцену (помещение) и на персонажа (обычный mesh). Что позволило начать готовить чистовую графику.

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

По итогам данного процесса мы выработали список требований для наших сцен:

• количество треугольников на всю сцену: не более 50 тысяч*;
• общий объём текстур (без lightmap): не более 10 текстур размером 1024×1024 формата XRGB / ARGB (или 40 текстур 512×512 и так далее)*;
• lightmap: не более 10 компрессированных текстур 1024×1024*;
• использование простейших шейдеров, в идеале — Mobile*;
• не более двух динамических источников света, в идеале — один Directional Light;
• использовать для динамического освещения исключительно шейдеры Vertex Lit;
• можно свободно использовать Light Probes, с учетом применения шейдеров Vertex Lit;
• не использовать динамические тени;
• использовать, где можно, lightmaps;
• отсутствие всяческой скелетной анимации — иначе говоря, ни единого SkinnedMeshRenderer в сцене.

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

Сама сборка в Unity осуществлялась стандартным способом:

• использование префабов для всех повторяющихся объектов;
• создание иерархии, группировка объектов по типам;
• отсутствие посторонних или пустых объектов (в сцене должны быть только видимые объекты и «контейнеры», группирующие объекты);
• префабы имеют простейшую иерархию, без ненужных вложенностей.

Концептуальных сложностей в работе над контентом не возникло. Единственное — освоение новой системы «запекания» освещения в Unity. В версии 5, относительно 4, поменялся состав параметров, добавились новые режимы. Со всем этим нужно было разобраться.

Освещение нужно было «запекать» непременно в Unity, так как это позволяло «запечь» light probes, которые задешево дают возможность осветить персонажей в сцене — для этого использовался шейдер с повертексным освещением (vertex lit), который совсем незначительно влияет на производительность (если сравнивать с unlit-шейдерами и с pixel lighting в режиме forward rendering).

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

Отдельно следует отметить опасность неаккуратного использования стандартного шейдера Unity 5. Заявлено, что он сильно оптимизирован в том числе и под мобильные платформы, однако на деле применение ряда параметров (например, коэффициент размытия отражения) приводит к радикальному уменьшению производительности (blur — весьма ресурсоемкая операция).

Также изначально было задумано полностью отказать от постпроцессинга (image effects), так как данная техника способна внести весьма существенные коррективы в результирующий FPS на мобильных устройствах — даже при использовании простейших эффектов. Посему нужные эффекты, а именно: затемнение сцены и насыщение цвета (соотношение цвет / чёрный / белый), — были вшиты в фрагментные шейдеры, то есть, можно сказать, данные «постэффекты» применяются непосредственно при рендеринге геометрии.

Естественно, это не сработает при желании использовать более сложные эффекты — типа Bloom или Depth of Field.

И немного насчёт ограничений использования image effects. При рендеринге под GearVR и Oculus Rift уже применяются вшитые в SDK постэффекты для дисторсии и хроматических аберраций. Эти эффекты корректируют изображение в соответствии с физическими свойствами линз шлема. И если мощности устройства хватает для простых пост эффектов при рендеринге без Oculus SDK при двух камерах, то с Oculus SDK это уже проблематично.

Оболочка

В разработке интерфейса очень полезной оказалась официальная документация, например, Oculus Best Practices, а также референс в виде оболочки для самого GearVR — Oculus Home. Помогла и наша хоть небольшая, но экспертиза в области интерфейсов для VR.

Мы очень быстро прототипировали и отрисовали все элементы оболочки. Каких-то сложностей со сборкой или отладкой тоже не возникло. Работа над этой частью оказалась одним из самых простых этапов работ над проектом.

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

В остальном, создатели Oculus сделали очень удобный API для Unity, который позволяет буквально мгновенно начать разработку под VR, за что им огромное спасибо.

Итоги

Что было сделано плохо

1. Интерактив. Хотелось бы добавить ещё больше экшена в вводную лекцию, усилив общую динамику.
2. Контент. Если бы мы знали, сколько проблем возникнет при оптимизации сцен, то смогли бы это сразу учесть, и уровень графики можно было бы поднять на порядок, используя несколько иной пайплайн сборки.
3. Эффекты. Не успели нормально отладить эхо в зале. Это отличный эффект для большего погружения, но ряд технических моментов не позволил довести работу до нужного уровня.
4. Оболочка. Недостаточное внимание было уделено этому моменту. Можно было раскрыть тему больше, чем есть сейчас, показав различные UI/UX-решения для удобной работы с контентом.
5. Подача. Нужно было больше внимания уделить скриншотам проекта. На фоне остальных финалистов материалы смотрятся несколько блёклыми и не особо привлекают внимание.

Что было сделано хорошо

1. Концепция. Если говорить о задачах конкурса — инновации в области использования VR — то была выбрана подходящая концепция, через которую мы смогли показать интересные и оригинальные способы использования виртуальной реальности для практических задач.
2. Документация. Весь сценарий был чётко прописан и утвержден, после нескольких итераций правок ещё в самом начале работ. Это позволило адекватно оценить сроки разработки и распланировать все ресурсы.
3. Графика. Несмотря на то, что проект достаточно сдержан по цветам и насыщению контентом, общее графическое исполнение получилось реализовать на должном уровне.
4. Программная часть. В достаточно короткие сроки была реализована своя небольшая система воспроизведения сценария, которая хоть и не имеет внятного представления в редакторе (отсутствует как таковая timeline), однако позволяет разбить сценарий на небольшие фрагменты и отлаживать его в любой точке с возможностью быстрой автоматической «прокрутки» всех предыдущих эпизодов.
5. Программная часть. К плюсам можно отнести интеграцию диктофона с использованием встроенного кодека, что позволило сохранять записанный голос в компактном формате. Такой подход перспективен при развитии проекта ввиду того, что в дальнейшем может потребоваться записывать не десятки секунд, а возможно десятки минут, а также осуществлять коммуникацию с тренером в реальном времени по сети.
6. Общее впечатление. Несмотря на все минусы, указанные выше, мы довольны результатом. Проект получился цельным, все основные моменты, которые хотелось раскрыть, мы раскрыли.

Будущее

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

По материалам портала Цукерберг позвонит.