Это первая часть текстовой расшифровки второго интервью для нашей передачи (Apple Podcasts, Яндекс.Музыка). Гость выпуска — Андрей Карсаков (kapc3d), к.т.н., старший научный сотрудник Национального центра когнитивных разработок, доцент Факультета цифровых трансформаций.
С 2012 года Андрей работает в научной группе Визуализация и компьютерная графика. Занимается крупными прикладными проектами на государственном и международном уровне. В этой части беседы мы говорим о его опыте AR-сопровождения массовых мероприятий.
Фото ThisisEngineering RAEng (Unsplash.com)
Таймкод (по аудиоверсии) — 00:41
dmitrykabanov: Я бы хотел начать с проекта «Европейские игры». Он многокомпонентный, в подготовке участвовало несколько команд, а обеспечить дополненную реальность для многотысячной аудитории прямо во время мероприятия на стадионе — достаточно серьёзная задача. С точки зрения вашего участия, это было программное обеспечение в первую очередь?
kapc3d: Да, мы сделали программную часть и обеспечивали сопровождение во время проведения шоу. Нужно было в реальном времени все отслеживать, мониторить и запускать, еще — работать с телевизионной группой. Если рассматривать этот проект в целом, то можно говорить про церемонии открытия-закрытия Европейских игр в Минске, а также про церемонию открытия чемпионата WorldSkills в Казани. Это была одинаковая схема работы, но разные мероприятия. Между ними был промежуток в два месяца. Проект мы готовили вместе с ребятами из компании Sechenov.com.
Познакомились с ними случайно на Science Fest, который проходил осенью 2018 года. Наши магистранты шоукейсились со своим курсовым проектом по теме VR. Ребята подошли к нам и спросили, чем мы занимаемся у себя в лаборатории. Выглядело это примерно так:
— Вот вы с VR работаете, а с дополненной реальностью умеете?
— Ну, вроде как, да.
— Есть такая задача, с такими вводными. Сможете сделать?
Репу немножко почесали, нереального вроде ничего нет:
— Давайте попробуем предварительно все изучить, а далее — найдем решение.
Дмитрий: Они занимаются только медийным сопровождением?
Андрей: Делают full stack. С точки зрения менеджмента и организации — полностью занимаются режиссурой, постановкой, подбором декораций, логистикой и прочим техническим обеспечением. Но им хотелось сделать что-то особенное для Европейских игр. Данные спецэффекты, вроде смешанной реальности, делают для телевидения достаточно давно, но они не самые бюджетные с точки зрения технической реализации. Поэтому ребята искали альтернативные варианты.
Дмитрий: Давайте подробнее обсудим задачу. В чём она состояла?
Андрей: Есть мероприятие. Оно длится час-полтора. Нужно сделать так, чтобы зрители, которые смотрят его в прямом эфире, и те, кто сидят на стадионе, могли увидеть эффекты с дополненной реальностью с полной синхронизацией с живым шоу по времени и расположению на площадке.
Был ряд технических ограничений. Нельзя было делать синхронизацию по времени через интернет, потому что были страхи по поводу избыточной нагрузки на сеть при полных трибунах и перспектива посещения мероприятия главами государств, из-за чего мобильные сети могли глушить.
Андрей Карсаков, фото из материала Университета ИТМО
У нас было два ключевых компонента этого проекта — персональный опыт, который люди могут получить через мобильные устройства, и то, что идёт в телевизионную трансляцию и информационные экраны на самом стадионе.
Если вдруг человек смотрит через мобильное устройство эпизоды дополненной реальности и одновременно попадает на экран, он должен увидеть ту же самую картинку.
Нам нужно было две фактически разные системы полностью синхронизировать по времени. Но особенность таких шоу в том, что это комплексные мероприятия, где задействовано большое количество технических служб и все операции выполняются по тайм-кодам. Тайм-код — это конкретный момент времени, в который что-то стартует: свет, звук, выход людей, открывающиеся лепестки сцены и так далее. Мы должны были подстроиться под эту систему, чтобы всё у нас запускалось в нужный момент. Еще одна особенность была в том, что сцены и эпизоды с дополненной реальностью были сценарно завязаны между собой.
Дмитрий: Но вы всё-таки решили отказаться от использования тайм-кодов, из-за высоких рисков возникновения форс-мажоров, либо изначально посчитали какие-то мощностные характеристики и поняли, что нагрузка на всю систему будет достаточно высокая?
Андрей: Если делать сервис синхронизации на такую аудиторию, то это не сильно сложно. Запросы в любом случае не будут валиться в один момент. Да, нагрузка высокая, но это не аврал. Вопрос в том, стоит ли тратить на это ресурсы и время, если неожиданно сеть погасят. Мы не были уверены, что этого не произойдет. В конечном счете всё работало, с перебоями из-за нагрузки, но работало, а мы — синхронизировались по тайм-коду по другой схеме. Это был один из глобальных челленджей.
Таймкод (по аудиоверсии) — 10:42
Андрей: Еще нам нужно было учитывать, что стадион — это не классическая концертная площадка, и синхронизировать системы по пространству для мобильных устройств. Так, какое-то время назад вирусилась история с дополненной реальностью на концертах Eminem, потом был кейс с Лободой.
Фото Robert Bye (Unsplash.com)
Но это — всегда экспириенс in front of you — вся толпа стоит перед сценой, синхронизация достаточно простая. В случае со стадионом нужно понимать, с какой ты стороны находишься по окружности, относительное положение, чтобы стадион сел в то пространство, которое в виртуальной среде есть. Это был некислый челлендж. Пытались решить его различными способами, и получился близкий кейс к тому, что было реализовано у Лободы, но не во всем.
Мы давали пользователю самому определиться, где он находится. Сделали разметку стадиона, где люди выбирали сектор, ряд, место. Все это — в четыре «клика». Далее нам оставалось определить направление на сцену. Для этого мы показывали силуэт того, как примерно должна выглядеть сцена с пользовательского ракурса. Он совмещал его, тапал и всё — сцена садилась. Мы старались максимально упростить этот процесс. Все-таки 90% зрителей, которые хотели посмотреть шоу, — это не те люди, которые имеют опыт общения с дополненной реальностью.
Дмитрий: Для этого проекта было отдельное приложение?
Андрей: Да, приложение для iOS и для Android, которое мы пушили в сторы. По нему была отдельная промо-кампания. Было предварительно подробно рассказано, как скачать и прочее.
Дмитрий: Надо понимать, что человеку негде физически проверить и поучиться использовать такое приложение. Поэтому задача с «обучением» аудитории усложнялась.
Андрей: Да-да. С UX мы наловили много шишек, потому что пользователь хочет опыт получить в три клика: скачал, установил, запустил — заработало. Многим лень ходить сложными туториалами, читать обучение и прочее. И мы не старались всё максимально объяснить пользователю в туториале: здесь откроется окошко, здесь доступ к камере, иначе не заработает и так далее. Сколько бы ты не писал объяснений, как бы ты подробно не разжевывал, какие бы гифочки не вставлял, народ этого не читает.
В Минске мы собрали большой пул фидбека по этой части, и уже многое изменили для приложения в Казани. Мы загоняли туда не только те фонограммы и те тайм-коды, которые соответствуют конкретному эпизоду дополненной реальности, а брали полностью все фонограммы и тайм-коды. Так приложение слышало, что происходит в момент запуска, и — если человек не в тот момент зашёл — выдавало информацию: «Товарищ, извини, твой AR-эпизод будет через 15 минут».
Таймкод (по аудиоверсии) — 16:37
Дмитрий: Синхронизацию всё-таки решили делать по звуку?
Андрей: Да, это получилось случайно. Мы перебирали варианты и натолкнулись на компанию Cifrasoft из Ижевска. Они делают не особо навороченную, но железно работающую SDK, которая позволяет по звуку синхронизироваться с таймингом. Систему позиционировали для работы с ТВ, когда ты по звуку условной рекламы можешь выводить что-то в приложении или по дорожке фильма давать интерактив.
Дмитрий: Но одно дело — ты сидишь у себя в гостиной, а другое — многотысячный стадион. Как у вас все сложилось с качеством записи звука и его последующим распознаванием?
Андрей: Было много страхов и сомнений, но в большинстве случаев всё распознавалось хорошо. Они строят сигнатуры по звуковой дорожке своими хитрыми алгоритмами — итог весит меньше исходного аудиофайла. Когда микрофон слушает окружающий звук, он пытается найти эти особенности и распознать трек по ним. В хороших условиях точность синхронизации 0,1-0,2 секунды. Этого было более чем достаточно. В плохих условиях расхождение было до 0,5 секунды.
Многое зависит от девайса. Мы работали с большим парком устройств. Для айфонов — это всего 10 моделей. Они работали нормально с точки зрения качества и прочих особенностей. Но с андроидами зоопарк такой, что мама моя. Не везде получалось так, что звуковая синхронизация срабатывала. Были кейсы, когда на разных устройствах, притом разные треки, не получалось услышать из-за каких-то особенностей. Где-то уходят низкие частоты, где-то — высокие начинают хрипеть. Но если в девайсе был нормализатор на микрофоне, синхронизация всегда срабатывала.
Дмитрий: Расскажите, пожалуйста, об архитектуре — что использовали в проекте?
Андрей: Приложение мы делали на Unity — самый простой вариант с точки зрения мультиплатформенности и работы с графикой. Использовали AR Foundation. Мы сразу сказали, что не хотели бы усложнять систему, поэтому ограничились парком устройств, которые поддерживают ARKit и ARCore, чтобы успеть все протестировать. Сделали плагин для цифрасофтовской SDK, он лежит у нас на GitHub. Сделали систему менеджмента контента, чтобы сценарии запускались по таймлайну.
Повозились немного с системой частиц, потому что пользователь может зайти в любое время конкретного эпизода, и нужно, чтобы он увидел все с того момента, с которого он засинхронизировался. Повозились с системой, которая позволяет сценарии воспроизводить чётко по времени, чтобы трехмерный опыт можно было, как в фильме, прокручивать вперёд-назад. Если с классическими анимациями это работает «из коробки», то с системами частиц пришлось повозиться. В какой-то момент они начинают спауниться, и если ты оказываешься где-то до точки спауна, они ещё не родились, хотя вроде должны быть. Но эта проблема, на самом деле, достаточно легко решается.
Для мобильной части архитектура достаточно простая. Для телетрансляции всё сложнее. У нас были ограничения по железу. От заказчика было поставлено условие: «Вот у нас есть такой-то парк железа, грубо говоря, надо, чтобы на нем всё работало». Мы сразу ориентировались на то, что будем работать с относительно бюджетными картами видеозахвата. Но бюджетные — это не значит, что плохие.
Было ограничение по железу, по картам видеозахвата и по условиям работы — как мы должны получать картинку. Карты захвата — Blackmagic Design, работали по схеме Internal keying — это когда к тебе заходит видеокадр с камеры. У карточки есть свой процессинговый чип, куда заводится ещё и кадр, который должен накладываться поверх входящего. Карточка их смешивает — больше мы там ничего не трогаем и не влияем на кадр с видеокамеры. Результат через видеовыход она выплёвывает на пультовую. Это хороший метод для накладывания титров и прочих подобных вещей, но он не очень подходит для эффектов смешанной реальности, потому что там много ограничений на render pipeline.
Дмитрий: С точки зрения вычислений в реальном времени, привязки объектов или чего-то еще?
Андрей: С точки зрения качества и достижения нужных эффектов. Из-за того, что мы не знаем, поверх чего накладываем картинку. Мы просто отдаем информацию о цвете и прозрачности поверх исходного потока. Некоторых эффектов вроде преломлений, корректной прозрачности, дополнительных теней при такой схеме невозможно добиться. Для этого нужно все рендерить вместе. Например, никак не получится сделать эффект искажения воздуха от костра или от горячего асфальта. То же самое с передачей эффекта прозрачности с учетом показателя преломления. Мы изначально делали контент, исходя из этих ограничений, и старались использовать соответствующие эффекты.
Дмитрий: У вас был свой контент уже на первом проекте для Европейских игр?
Андрей: Нет, основной этап разработки контента был за ребятами из Sechenov.com. Их графисты рисовали базовый контент с анимациями и прочими вещами. А мы всё интегрировали в движок, докручивали дополнительные эффекты, адаптировали, чтобы всё правильно работало.
Если говорить про пайплайн, то для телевещания мы всё собирали на Unreal Engine 4. Так совпало, что они как раз в тот момент начали форсить свой инструментарий для смешанной реальности (mixed reality). Оказалось, что всё не так просто. Весь инструментарий даже сейчас сырой, нам много пришлось вручную допиливать. В Минске мы работали на кастомной сборке движка, то есть мы некоторые вещи внутри движка переписывали, чтобы, например, можно было тени рисовать поверх реальных объектов. На той версии движка, которая была тогда актуальна, не было фич, позволяющих это делать с помощью стандартного инструментария. По этой причине у нас ребята делали свою кастомную сборку, чтобы обеспечить все, что было жизненно необходимо.
Таймкод (по аудиоверсии) — 31:37
Дмитрий: Но всё это в достаточно сжатые сроки?
Андрей: Сжатые сроки были по казанскому проекту, по минскому — нормальные. Где-то полгода на разработку, но с учётом того, что было задействовано шесть человек. Параллельно делали мобильную часть, разрабатывали инструментарий для телепродакшена. Там был не только вывод картинки. Например, система трекинга с оптикой, для этого нужно было свой инструментарий делать.
Дмитрий: Была адаптация от одного проекта к другому? За полтора месяца нужно было воспользоваться наработками и переложить проект с новым контентом на новую площадку?
Андрей: Да, это было за полтора месяца. У нас был запланирован двухнедельный отпуск всей команды после минского проекта. Но сразу после закрытия ребята из Sechenov.com подходят и говорят: «Ну что, давайте тогда Казань делать». Мы все-таки успели немного отдохнуть, но переключились на этот проект достаточно быстро. Кое-что доделали по технической части. Большая часть времени была потрачена на контент, потому что для WorldSkills его полностью мы делали, просто согласовывали с режиссёрской командой. С их стороны был только сценарий. Но было легче — не нужно было лишних итераций. Когда ты делаешь контент сам, сразу видишь, как это в движке работает, можешь быстро править и согласовывать.
По мобильной части учли все тонкости, которые у нас были по Минску. Сделали новый дизайн приложения, переработали немного архитектуру, добавили туториалов, но максимально коротко и наглядно постарались сделать. Сократили количество шагов пользователя от запуска приложения до просмотра контента. Полтора месяца хватило, чтобы сделать адекватный проект. За полторы недели вышли на площадку. Там работать было проще, потому что весь контроль над проектом был в руках организаторов, не нужно было согласовывать с другими комитетами. В Казани было проще и легче работать и вполне нормально, что времени было меньше.
Дмитрий: Но подход к синхронизации вы решили оставить, как он и был, по звуку?
Андрей: Да, мы оставили по звуку. Работало хорошо. Как говорится, если работает, не трогай. Мы просто учли нюансы по качеству звуковой дорожки. Когда делали вступление, как раз был тренировочный эпизод, чтобы люди могли попробовать до того, как шоу начнётся. Было удивительно, что когда в момент воспроизведения трека на стадионе идут бурные аплодисменты, «живые», система позволяет хорошо синхронизироваться по этому треку, но если в этот момент вместе с треком примешиваются записанные аплодисменты, то трек перестаёт ловиться. Вот подобные нюансы учли, и по звуку всё достаточно хорошо синхронизировалось.
P.S. Во второй части выпуска мы говорим о научной визуализации данных, моделировании процессов в других проектах, геймдеве и магистерской программе «Технология разработки компьютерных игр». Опубликуем продолжение в следующем материале. Послушать и поддержать нас можно тут:
P.P.S. Тем временем на англоязычной версии Хабра: a closer look at ITMO University.
С 2012 года Андрей работает в научной группе Визуализация и компьютерная графика. Занимается крупными прикладными проектами на государственном и международном уровне. В этой части беседы мы говорим о его опыте AR-сопровождения массовых мероприятий.
Фото ThisisEngineering RAEng (Unsplash.com)
Контекст и задачи проекта
Таймкод (по аудиоверсии) — 00:41
dmitrykabanov: Я бы хотел начать с проекта «Европейские игры». Он многокомпонентный, в подготовке участвовало несколько команд, а обеспечить дополненную реальность для многотысячной аудитории прямо во время мероприятия на стадионе — достаточно серьёзная задача. С точки зрения вашего участия, это было программное обеспечение в первую очередь?
kapc3d: Да, мы сделали программную часть и обеспечивали сопровождение во время проведения шоу. Нужно было в реальном времени все отслеживать, мониторить и запускать, еще — работать с телевизионной группой. Если рассматривать этот проект в целом, то можно говорить про церемонии открытия-закрытия Европейских игр в Минске, а также про церемонию открытия чемпионата WorldSkills в Казани. Это была одинаковая схема работы, но разные мероприятия. Между ними был промежуток в два месяца. Проект мы готовили вместе с ребятами из компании Sechenov.com.
Познакомились с ними случайно на Science Fest, который проходил осенью 2018 года. Наши магистранты шоукейсились со своим курсовым проектом по теме VR. Ребята подошли к нам и спросили, чем мы занимаемся у себя в лаборатории. Выглядело это примерно так:
— Вот вы с VR работаете, а с дополненной реальностью умеете?
— Ну, вроде как, да.
— Есть такая задача, с такими вводными. Сможете сделать?
Репу немножко почесали, нереального вроде ничего нет:
— Давайте попробуем предварительно все изучить, а далее — найдем решение.
Дмитрий: Они занимаются только медийным сопровождением?
Андрей: Делают full stack. С точки зрения менеджмента и организации — полностью занимаются режиссурой, постановкой, подбором декораций, логистикой и прочим техническим обеспечением. Но им хотелось сделать что-то особенное для Европейских игр. Данные спецэффекты, вроде смешанной реальности, делают для телевидения достаточно давно, но они не самые бюджетные с точки зрения технической реализации. Поэтому ребята искали альтернативные варианты.
Дмитрий: Давайте подробнее обсудим задачу. В чём она состояла?
Андрей: Есть мероприятие. Оно длится час-полтора. Нужно сделать так, чтобы зрители, которые смотрят его в прямом эфире, и те, кто сидят на стадионе, могли увидеть эффекты с дополненной реальностью с полной синхронизацией с живым шоу по времени и расположению на площадке.
Был ряд технических ограничений. Нельзя было делать синхронизацию по времени через интернет, потому что были страхи по поводу избыточной нагрузки на сеть при полных трибунах и перспектива посещения мероприятия главами государств, из-за чего мобильные сети могли глушить.
Андрей Карсаков, фото из материала Университета ИТМО
У нас было два ключевых компонента этого проекта — персональный опыт, который люди могут получить через мобильные устройства, и то, что идёт в телевизионную трансляцию и информационные экраны на самом стадионе.Если вдруг человек смотрит через мобильное устройство эпизоды дополненной реальности и одновременно попадает на экран, он должен увидеть ту же самую картинку.
Нам нужно было две фактически разные системы полностью синхронизировать по времени. Но особенность таких шоу в том, что это комплексные мероприятия, где задействовано большое количество технических служб и все операции выполняются по тайм-кодам. Тайм-код — это конкретный момент времени, в который что-то стартует: свет, звук, выход людей, открывающиеся лепестки сцены и так далее. Мы должны были подстроиться под эту систему, чтобы всё у нас запускалось в нужный момент. Еще одна особенность была в том, что сцены и эпизоды с дополненной реальностью были сценарно завязаны между собой.
Дмитрий: Но вы всё-таки решили отказаться от использования тайм-кодов, из-за высоких рисков возникновения форс-мажоров, либо изначально посчитали какие-то мощностные характеристики и поняли, что нагрузка на всю систему будет достаточно высокая?
Андрей: Если делать сервис синхронизации на такую аудиторию, то это не сильно сложно. Запросы в любом случае не будут валиться в один момент. Да, нагрузка высокая, но это не аврал. Вопрос в том, стоит ли тратить на это ресурсы и время, если неожиданно сеть погасят. Мы не были уверены, что этого не произойдет. В конечном счете всё работало, с перебоями из-за нагрузки, но работало, а мы — синхронизировались по тайм-коду по другой схеме. Это был один из глобальных челленджей.
Сложности реализации с точки зрения UX
Таймкод (по аудиоверсии) — 10:42
Андрей: Еще нам нужно было учитывать, что стадион — это не классическая концертная площадка, и синхронизировать системы по пространству для мобильных устройств. Так, какое-то время назад вирусилась история с дополненной реальностью на концертах Eminem, потом был кейс с Лободой.
Фото Robert Bye (Unsplash.com)
Но это — всегда экспириенс in front of you — вся толпа стоит перед сценой, синхронизация достаточно простая. В случае со стадионом нужно понимать, с какой ты стороны находишься по окружности, относительное положение, чтобы стадион сел в то пространство, которое в виртуальной среде есть. Это был некислый челлендж. Пытались решить его различными способами, и получился близкий кейс к тому, что было реализовано у Лободы, но не во всем.Мы давали пользователю самому определиться, где он находится. Сделали разметку стадиона, где люди выбирали сектор, ряд, место. Все это — в четыре «клика». Далее нам оставалось определить направление на сцену. Для этого мы показывали силуэт того, как примерно должна выглядеть сцена с пользовательского ракурса. Он совмещал его, тапал и всё — сцена садилась. Мы старались максимально упростить этот процесс. Все-таки 90% зрителей, которые хотели посмотреть шоу, — это не те люди, которые имеют опыт общения с дополненной реальностью.
Дмитрий: Для этого проекта было отдельное приложение?
Андрей: Да, приложение для iOS и для Android, которое мы пушили в сторы. По нему была отдельная промо-кампания. Было предварительно подробно рассказано, как скачать и прочее.
Дмитрий: Надо понимать, что человеку негде физически проверить и поучиться использовать такое приложение. Поэтому задача с «обучением» аудитории усложнялась.
Андрей: Да-да. С UX мы наловили много шишек, потому что пользователь хочет опыт получить в три клика: скачал, установил, запустил — заработало. Многим лень ходить сложными туториалами, читать обучение и прочее. И мы не старались всё максимально объяснить пользователю в туториале: здесь откроется окошко, здесь доступ к камере, иначе не заработает и так далее. Сколько бы ты не писал объяснений, как бы ты подробно не разжевывал, какие бы гифочки не вставлял, народ этого не читает.
В Минске мы собрали большой пул фидбека по этой части, и уже многое изменили для приложения в Казани. Мы загоняли туда не только те фонограммы и те тайм-коды, которые соответствуют конкретному эпизоду дополненной реальности, а брали полностью все фонограммы и тайм-коды. Так приложение слышало, что происходит в момент запуска, и — если человек не в тот момент зашёл — выдавало информацию: «Товарищ, извини, твой AR-эпизод будет через 15 минут».
Немного об архитектуре и подходе к синхронизации
Таймкод (по аудиоверсии) — 16:37
Дмитрий: Синхронизацию всё-таки решили делать по звуку?
Андрей: Да, это получилось случайно. Мы перебирали варианты и натолкнулись на компанию Cifrasoft из Ижевска. Они делают не особо навороченную, но железно работающую SDK, которая позволяет по звуку синхронизироваться с таймингом. Систему позиционировали для работы с ТВ, когда ты по звуку условной рекламы можешь выводить что-то в приложении или по дорожке фильма давать интерактив.
Дмитрий: Но одно дело — ты сидишь у себя в гостиной, а другое — многотысячный стадион. Как у вас все сложилось с качеством записи звука и его последующим распознаванием?
Андрей: Было много страхов и сомнений, но в большинстве случаев всё распознавалось хорошо. Они строят сигнатуры по звуковой дорожке своими хитрыми алгоритмами — итог весит меньше исходного аудиофайла. Когда микрофон слушает окружающий звук, он пытается найти эти особенности и распознать трек по ним. В хороших условиях точность синхронизации 0,1-0,2 секунды. Этого было более чем достаточно. В плохих условиях расхождение было до 0,5 секунды.
Многое зависит от девайса. Мы работали с большим парком устройств. Для айфонов — это всего 10 моделей. Они работали нормально с точки зрения качества и прочих особенностей. Но с андроидами зоопарк такой, что мама моя. Не везде получалось так, что звуковая синхронизация срабатывала. Были кейсы, когда на разных устройствах, притом разные треки, не получалось услышать из-за каких-то особенностей. Где-то уходят низкие частоты, где-то — высокие начинают хрипеть. Но если в девайсе был нормализатор на микрофоне, синхронизация всегда срабатывала.
Дмитрий: Расскажите, пожалуйста, об архитектуре — что использовали в проекте?
Андрей: Приложение мы делали на Unity — самый простой вариант с точки зрения мультиплатформенности и работы с графикой. Использовали AR Foundation. Мы сразу сказали, что не хотели бы усложнять систему, поэтому ограничились парком устройств, которые поддерживают ARKit и ARCore, чтобы успеть все протестировать. Сделали плагин для цифрасофтовской SDK, он лежит у нас на GitHub. Сделали систему менеджмента контента, чтобы сценарии запускались по таймлайну.
Повозились немного с системой частиц, потому что пользователь может зайти в любое время конкретного эпизода, и нужно, чтобы он увидел все с того момента, с которого он засинхронизировался. Повозились с системой, которая позволяет сценарии воспроизводить чётко по времени, чтобы трехмерный опыт можно было, как в фильме, прокручивать вперёд-назад. Если с классическими анимациями это работает «из коробки», то с системами частиц пришлось повозиться. В какой-то момент они начинают спауниться, и если ты оказываешься где-то до точки спауна, они ещё не родились, хотя вроде должны быть. Но эта проблема, на самом деле, достаточно легко решается.
Для мобильной части архитектура достаточно простая. Для телетрансляции всё сложнее. У нас были ограничения по железу. От заказчика было поставлено условие: «Вот у нас есть такой-то парк железа, грубо говоря, надо, чтобы на нем всё работало». Мы сразу ориентировались на то, что будем работать с относительно бюджетными картами видеозахвата. Но бюджетные — это не значит, что плохие.
Было ограничение по железу, по картам видеозахвата и по условиям работы — как мы должны получать картинку. Карты захвата — Blackmagic Design, работали по схеме Internal keying — это когда к тебе заходит видеокадр с камеры. У карточки есть свой процессинговый чип, куда заводится ещё и кадр, который должен накладываться поверх входящего. Карточка их смешивает — больше мы там ничего не трогаем и не влияем на кадр с видеокамеры. Результат через видеовыход она выплёвывает на пультовую. Это хороший метод для накладывания титров и прочих подобных вещей, но он не очень подходит для эффектов смешанной реальности, потому что там много ограничений на render pipeline.
Дмитрий: С точки зрения вычислений в реальном времени, привязки объектов или чего-то еще?
Андрей: С точки зрения качества и достижения нужных эффектов. Из-за того, что мы не знаем, поверх чего накладываем картинку. Мы просто отдаем информацию о цвете и прозрачности поверх исходного потока. Некоторых эффектов вроде преломлений, корректной прозрачности, дополнительных теней при такой схеме невозможно добиться. Для этого нужно все рендерить вместе. Например, никак не получится сделать эффект искажения воздуха от костра или от горячего асфальта. То же самое с передачей эффекта прозрачности с учетом показателя преломления. Мы изначально делали контент, исходя из этих ограничений, и старались использовать соответствующие эффекты.
Дмитрий: У вас был свой контент уже на первом проекте для Европейских игр?
Андрей: Нет, основной этап разработки контента был за ребятами из Sechenov.com. Их графисты рисовали базовый контент с анимациями и прочими вещами. А мы всё интегрировали в движок, докручивали дополнительные эффекты, адаптировали, чтобы всё правильно работало.
Если говорить про пайплайн, то для телевещания мы всё собирали на Unreal Engine 4. Так совпало, что они как раз в тот момент начали форсить свой инструментарий для смешанной реальности (mixed reality). Оказалось, что всё не так просто. Весь инструментарий даже сейчас сырой, нам много пришлось вручную допиливать. В Минске мы работали на кастомной сборке движка, то есть мы некоторые вещи внутри движка переписывали, чтобы, например, можно было тени рисовать поверх реальных объектов. На той версии движка, которая была тогда актуальна, не было фич, позволяющих это делать с помощью стандартного инструментария. По этой причине у нас ребята делали свою кастомную сборку, чтобы обеспечить все, что было жизненно необходимо.
Другие нюнасы и адаптация к WorldSkills в Казани
Таймкод (по аудиоверсии) — 31:37
Дмитрий: Но всё это в достаточно сжатые сроки?
Андрей: Сжатые сроки были по казанскому проекту, по минскому — нормальные. Где-то полгода на разработку, но с учётом того, что было задействовано шесть человек. Параллельно делали мобильную часть, разрабатывали инструментарий для телепродакшена. Там был не только вывод картинки. Например, система трекинга с оптикой, для этого нужно было свой инструментарий делать.
Дмитрий: Была адаптация от одного проекта к другому? За полтора месяца нужно было воспользоваться наработками и переложить проект с новым контентом на новую площадку?
Андрей: Да, это было за полтора месяца. У нас был запланирован двухнедельный отпуск всей команды после минского проекта. Но сразу после закрытия ребята из Sechenov.com подходят и говорят: «Ну что, давайте тогда Казань делать». Мы все-таки успели немного отдохнуть, но переключились на этот проект достаточно быстро. Кое-что доделали по технической части. Большая часть времени была потрачена на контент, потому что для WorldSkills его полностью мы делали, просто согласовывали с режиссёрской командой. С их стороны был только сценарий. Но было легче — не нужно было лишних итераций. Когда ты делаешь контент сам, сразу видишь, как это в движке работает, можешь быстро править и согласовывать.
По мобильной части учли все тонкости, которые у нас были по Минску. Сделали новый дизайн приложения, переработали немного архитектуру, добавили туториалов, но максимально коротко и наглядно постарались сделать. Сократили количество шагов пользователя от запуска приложения до просмотра контента. Полтора месяца хватило, чтобы сделать адекватный проект. За полторы недели вышли на площадку. Там работать было проще, потому что весь контроль над проектом был в руках организаторов, не нужно было согласовывать с другими комитетами. В Казани было проще и легче работать и вполне нормально, что времени было меньше.
Дмитрий: Но подход к синхронизации вы решили оставить, как он и был, по звуку?
Андрей: Да, мы оставили по звуку. Работало хорошо. Как говорится, если работает, не трогай. Мы просто учли нюансы по качеству звуковой дорожки. Когда делали вступление, как раз был тренировочный эпизод, чтобы люди могли попробовать до того, как шоу начнётся. Было удивительно, что когда в момент воспроизведения трека на стадионе идут бурные аплодисменты, «живые», система позволяет хорошо синхронизироваться по этому треку, но если в этот момент вместе с треком примешиваются записанные аплодисменты, то трек перестаёт ловиться. Вот подобные нюансы учли, и по звуку всё достаточно хорошо синхронизировалось.
P.S. Во второй части выпуска мы говорим о научной визуализации данных, моделировании процессов в других проектах, геймдеве и магистерской программе «Технология разработки компьютерных игр». Опубликуем продолжение в следующем материале. Послушать и поддержать нас можно тут:
P.P.S. Тем временем на англоязычной версии Хабра: a closer look at ITMO University.