Продакшн-директор студии 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 была представлена вводная лекция, посвященная публичным выступлениям, открывающая курс, где пользователи смогут в прямом смысле прочувствовать, как заинтересовать публику своим выступлением, научатся успокаивать себя, концентрируясь на отдельных персонажах в зале и окажутся в других интересных ситуациях на сцене.
Также в текущей версии можно тренироваться перед выступлениями в отдельной виртуальной сцене — конференц-зале — записывать и проигрывать своё выступление, прокручивать слайды презентации.
Обучение в виртуальной реальности и функциональность сервиса
Нам давно была интересна тема тренингов в виртуальной реальности и в целом вопросы обучения в виртуальной реальности. В проекте мы изначально решили поднять сразу два больших и важных момента:
- Преимущество подачи обучающего материала в VR.
- Концепция инфраструктуры 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, за что им огромное спасибо.
Итоги
Что было сделано плохо
- Интерактив. Хотелось бы добавить ещё больше экшена в вводную лекцию, усилив общую динамику.
- Контент. Если бы мы знали, сколько проблем возникнет при оптимизации сцен, то смогли бы это сразу учесть, и уровень графики можно было бы поднять на порядок, используя несколько иной пайплайн сборки.
- Эффекты. Не успели нормально отладить эхо в зале. Это отличный эффект для большего погружения, но ряд технических моментов не позволил довести работу до нужного уровня.
- Оболочка. Недостаточное внимание было уделено этому моменту. Можно было раскрыть тему больше, чем есть сейчас, показав различные UI/UX-решения для удобной работы с контентом.
- Подача. Нужно было больше внимания уделить скриншотам проекта. На фоне остальных финалистов материалы смотрятся несколько блёклыми и не особо привлекают внимание.
Что было сделано хорошо
- Концепция. Если говорить о задачах конкурса — инновации в области использования VR — то была выбрана подходящая концепция, через которую мы смогли показать интересные и оригинальные способы использования виртуальной реальности для практических задач.
- Документация. Весь сценарий был чётко прописан и утвержден, после нескольких итераций правок ещё в самом начале работ. Это позволило адекватно оценить сроки разработки и распланировать все ресурсы.
- Графика. Несмотря на то, что проект достаточно сдержан по цветам и насыщению контентом, общее графическое исполнение получилось реализовать на должном уровне.
- Программная часть. В достаточно короткие сроки была реализована своя небольшая система воспроизведения сценария, которая хоть и не имеет внятного представления в редакторе (отсутствует как таковая timeline), однако позволяет разбить сценарий на небольшие фрагменты и отлаживать его в любой точке с возможностью быстрой автоматической «прокрутки» всех предыдущих эпизодов.
- Программная часть. К плюсам можно отнести интеграцию диктофона с использованием встроенного кодека, что позволило сохранять записанный голос в компактном формате. Такой подход перспективен при развитии проекта ввиду того, что в дальнейшем может потребоваться записывать не десятки секунд, а возможно десятки минут, а также осуществлять коммуникацию с тренером в реальном времени по сети.
- Общее впечатление. Несмотря на все минусы, указанные выше, мы довольны результатом. Проект получился цельным, все основные моменты, которые хотелось раскрыть, мы раскрыли.
Будущее
Сейчас мы делаем первые шаги в невероятно интересной сфере — обучении в виртуальной реальности и раскрытии потенциала VR в неигровых областях в целом. Mobile VR Jam стал отличной отправной точкой в этом направлении. Мы получили хорошую обратную связь и сформировали для себя целый массив интересных вопросов, которые ещё предстоит решить на этом пути.
По материалам портала Цукерберг позвонит.