Гэта першая частка тэкставай расшыфроўкі другога інтэрв'ю для нашай перадачы (, ). Госць выпуску (), к.т.н., старшы навуковы супрацоўнік Нацыянальнага цэнтра кагнітыўных распрацовак, дацэнт Факультэта лічбавых трансфармацый.
З 2012 года Андрэй працуе ў навуковай групе Візуалізацыя і камп'ютарная графіка. Займаецца буйнымі прыкладнымі праектамі на дзяржаўным і міжнародным узроўні. У гэтай частцы гутаркі мы гаворым аб яго вопыце AR-суправаджэння масавых мерапрыемстваў.
Фота (Unsplash.com)
Кантэкст і задачы праекта
Таймкод (па ) — 00:41
: Я б хацеў пачаць з праекту «Еўрапейскія гульні». Ён шматкампанентны, у падрыхтоўцы ўдзельнічала некалькі каманд, а забяспечыць дапоўненую рэальнасць для шматтысячнай аўдыторыі непасрэдна падчас мерапрыемства на стадыёне — дастаткова сур'ёзная задача. З пункту гледжання вашага ўдзелу, гэта было праграмнае забеспячэнне ў першую чаргу?
: Так, мы зрабілі праграмную частку і забяспечвалі суправаджэнне падчас правядзення шоу. Трэба было ў рэальным часе ўсё адсочваць, маніторыць і запускаць, яшчэ - працаваць з тэлевізійнай групай. Калі разглядаць гэты праект у цэлым, то можна казаць пра цырымонію адкрыцця-закрыцця. у Мінску, а таксама пра цырымонію адкрыцця чэмпіянату у Казані. Гэта была аднолькавая схема працы, але розныя мерапрыемствы. Паміж імі быў прамежак у два месяцы. Праект мы рыхтавалі разам з хлопцамі з кампаніі .
Пазнаёміліся з імі выпадкова на , які праходзіў восенню 2018 года. Нашы магістранты шоў кейсіліся са сваім курсавым праектам па тэме VR. Рабяты падышлі да нас і спыталі, чым мы займаемся ў сябе ў лабараторыі. Выглядала гэта прыкладна так:
- Вось вы з VR працуеце, а з дапоўненай рэальнасцю ўмееце?
- Ну, здаецца, так.
- Ёсць такая задача, з такімі ўступнымі. Зможаце зрабіць?
Рэпу трошкі пачухалі, нерэальнага накшталт нічога няма:
- Давайце паспрабуем папярэдне ўсё вывучыць, а далей - знойдзем рашэнне.
Зміцер: Яны займаюцца толькі медыйным суправаджэннем?
Андрэй: Робяць full stack. З пункту гледжання менеджменту і арганізацыі - цалкам займаюцца рэжысурай, пастаноўкай, падборам дэкарацый, лагістыкай і іншым тэхнічным забеспячэннем. Але ім хацелася зрабіць нешта асаблівае для Еўрапейскіх гульняў. Гэтыя спецэфекты, накшталт змешанай рэальнасці, робяць для тэлебачання дастаткова даўно, але яны не самыя бюджэтныя з пункту гледжання тэхнічнай рэалізацыі. Таму хлопцы шукалі альтэрнатыўныя варыянты.
Зміцер: Давайце падрабязней абмяркуем задачу. У чым яна складалася?
Андрэй: Ёсць імпрэза. Яно доўжыцца гадзіну-паўтары. Трэба зрабіць так, каб гледачы, якія глядзяць яго ў прамым эфіры, і тыя, хто сядзяць на стадыёне, маглі ўбачыць эфекты з дапоўненай рэальнасцю з поўнай сінхранізацыяй з жывым шоу па часе і размяшчэнні на пляцоўцы.
Быў шэраг тэхнічных абмежаванняў. Нельга было рабіць сінхранізацыю па часе праз інтэрнэт, бо былі страхі наконт залішняй нагрузкі на сетку пры поўных трыбунах і перспектыва наведвання мерапрыемства кіраўнікамі дзяржаў, з-за чаго мабільныя сеткі маглі глушыць.
Андрэй Карсакаў, фота з
У нас было два ключавыя кампаненты гэтага праекту — персанальны досвед, які людзі могуць атрымаць праз мабільныя прылады, і тое, што ідзе ў тэлевізійную трансляцыю і інфармацыйныя экраны на самым стадыёне.
Калі раптам чалавек глядзіць праз мабільную прыладу эпізоды дапоўненай рэальнасці і адначасова пападае на экран, ён павінен убачыць тую ж самую карцінку.
Нам трэба было дзве фактычна розныя сістэмы поўнасцю сінхранізаваць па часе. Але асаблівасць такіх шоу ў тым, што гэта комплексныя мерапрыемствы, дзе задзейнічана вялікая колькасць тэхнічных службаў і ўсе аперацыі выконваюцца па тайм-кодах. Тайм-код — гэта пэўны момант часу, у які нешта стартуе: святло, гук, выхад людзей, пялёсткі сцэны, якія адкрываюцца і гэтак далей. Мы павінны былі падстроіцца пад гэтую сістэму, каб усё ў нас запускалася ў патрэбны момант. Яшчэ адна асаблівасць была ў тым, што сцэны і эпізоды з дапоўненай рэальнасцю былі сцэнарна завязаны паміж сабой.
Зміцер: Але вы ўсёткі вырашылі адмовіцца ад выкарыстання тайм-кодаў, з-за высокіх рызык узнікнення форс-мажораў, або першапачаткова палічылі нейкія магутнасныя характарыстыкі і зразумелі, што нагрузка на ўсю сістэму будзе дастаткова высокая?
Андрэй: Калі рабіць сэрвіс сінхранізацыі на такую аўдыторыю, тое гэта не моцна складана. Запыты ў любым выпадку не будуць валіцца ў адзін момант. Так, нагрузка высокая, але гэта не аўрал. Пытанне ў тым, ці варта марнаваць на гэта рэсурсы і час, калі нечакана сетку патушаць. Мы не былі ўпэўненыя, што гэтага не адбудзецца. У канчатковым рахунку ўсё працавала, з перабоямі з-за нагрузкі, але працавала, а мы - сінхранізаваліся па тайм-кодзе па іншай схеме. Гэта быў адзін з глабальных челенджей.
Складанасці рэалізацыі з пункту гледжання UX
Таймкод (па ) — 10:42
Андрэй: Яшчэ нам трэба было ўлічваць, што стадыён - гэта не класічная канцэртная пляцоўка, і сінхранізаваць сістэмы па прасторы для мабільных прылад. Так, нейкі час таму вірусілася на канцэртах Eminem, потым быў кейс з Лабадай.
Фота (Unsplash.com)
Але гэта - заўсёды экспірыенс in front of you - увесь натоўп стаіць перад сцэнай, сінхранізацыя досыць простая. У выпадку са стадыёнам трэба разумець, з якога ты боку знаходзішся па акружнасці, адноснае становішча, каб стадыён сеў у тую прастору, якая ў віртуальным асяроддзі ёсць. Гэта быў някіслы челендж. Спрабавалі вырашыць яго рознымі спосабамі, і атрымаўся блізкі кейс да таго, што было рэалізавана ў Лабады, але не ва ўсім.
Мы давалі карыстачу самому вызначыцца, дзе ён знаходзіцца. Зрабілі разметку стадыёна, дзе людзі выбіралі сектар, шэраг, месца. Усё гэта - у чатыры «клікі». Далей нам заставалася вызначыць накіраванне на сцэну. Для гэтага мы паказвалі сілуэт таго, як прыкладна павінна выглядаць сцэна з карыстацкага ракурсу. Ён сумяшчаў яго, тапаў і ўсё - сцэна садзілася. Мы імкнуліся максімальна спрасціць гэты працэс. Усё ж 90% гледачоў, якія хацелі паглядзець шоу, — гэта не тыя людзі, якія маюць вопыт зносін з дапоўненай рэальнасцю.
Зміцер: Для гэтага праекта было асобнае прыкладанне?
Андрэй: Так, прыкладанне для iOS і для Android, якое мы пушылі ў сторы. Па ім была асобная прома-кампанія. Было папярэдне падрабязна расказана, як спампаваць і іншае.
Зміцер: Трэба разумець, што чалавеку няма дзе фізічна праверыць і павучыцца выкарыстоўваць такое дадатак. Таму задача з "навучаннем" аўдыторыі ўскладнялася.
Андрэй: Так так. З UX мы налавілі шмат гузоў, таму што карыстач жадае досвед атрымаць у тры зграя: запампаваў, усталяваў, запусціў — зарабіла. Многім лянота хадзіць складанымі тутарыяламі, чытаць навучанне і іншае. І мы не імкнуліся ўсё максімальна растлумачыць карыстачу ў тутарыяле: тут адкрыецца акенца, тут доступ да камеры, інакш не запрацуе і гэтак далей. Колькі б ты не пісаў тлумачэнняў, як бы ты падрабязна не разжоўваў, якія б гіфачкі не ўстаўляў, народ гэтага не чытае.
У Менску мы сабралі вялікі пул фідбэка па гэтай частцы, і ўжо шматлікае змянілі для прыкладання ў Казані. Мы заганялі туды не толькі тыя фанаграмы і тыя тайм-коды, якія адпавядаюць канкрэтнаму эпізоду дапоўненай рэальнасці, а бралі цалкам усе фанаграмы і тайм-коды. Так прыкладанне чула, што адбываецца ў момант запуску, і - калі чалавек не ў той момант зайшоў - выдавала інфармацыю: «Таварыш, прабач, твой AR-эпізод будзе праз 15 хвілін».
Трохі аб архітэктуры і падыходзе да сінхранізацыі
Таймкод (па ) — 16:37
Зміцер: Сінхранізацыю ўсё ж вырашылі рабіць па гуку?
Андрэй: Так, гэта атрымалася выпадкова. Мы перабіралі варыянты і натыкнуліся на кампанію з Іжэўска. Яны робяць не асоба наварочаную, але жалезна якая працуе SDK, якая дазваляе па гуку сінхранізавацца з таймінгам. Сістэму пазіцыянавалі для працы з ТБ, калі ты па гуку ўмоўнай рэкламы можаш выводзіць нешта ў дадатку ці па дарожцы фільма даваць інтэрактыў.
Зміцер: Але адна справа - ты сядзіш у сябе ў гасцінай, а іншая - шматтысячны стадыён. Як у вас усё склалася з якасцю запісу гуку і яго наступным распазнаннем?
Андрэй: Было шмат страхаў і сумневаў, але ў большасці выпадкаў усё распазнавалася добра. Яны будуюць сігнатуры па гукавой дарожцы сваімі хітрымі алгарытмамі – вынік важыць менш зыходнага аўдыёфайла. Калі мікрафон слухае навакольны гук, ён спрабуе знайсці гэтыя асаблівасці і распазнаць трэк па іх. У добрых умовах дакладнасць сінхранізацыі 0,1-0,2 секунды. Гэтага было больш чым дастаткова. У дрэнных умовах разыходжанне было да 0,5 секунды.
Многае залежыць ад девайса. Мы працавалі з вялікім паркам прылад. Для айфонаў - гэта ўсяго 10 мадэляў. Яны працавалі нармальна з пункту гледжання якасці і іншых асаблівасцей. Але з андроіда заапарк такі, што мама мая. Не ўсюды атрымлівалася так, што гукавая сінхранізацыя спрацоўвала. Былі кейсы, калі на розных прыстасаваннях, прытым розныя трэкі, не атрымлівалася пачуць з-за нейкіх асаблівасцяў. Дзесьці сыходзяць нізкія частоты, дзесьці - высокія пачынаюць хрыпець. Але калі ў аксэсуары быў нармалізатар на мікрафоне, сінхранізацыя заўсёды спрацоўвала.
Зміцер: Раскажыце, калі ласка, пра архітэктуру - што выкарыстоўвалі ў праекце?
Андрэй: Прыкладанне мы рабілі на Unity — самы просты варыянт з пункта гледжання мультыплатформеннасці і працы з графікай. Выкарыстоўвалі AR Foundation. Мы адразу сказалі, што не хацелі б ускладняць сістэму, таму абмежаваліся паркам прылад, якія падтрымліваюць ARKit і ARCore, каб паспець усё пратэставаць. Зрабілі плягін для лічбасафтоўскай SDK, ён . Зрабілі сістэму менеджменту кантэнту, каб сцэнары запускаліся па таймлайне.
Павазіліся трохі з сістэмай часціц, таму што карыстач можа зайсці ў любы час пэўнага эпізоду, і трэба, каб ён убачыў усё з таго моманту, з якога ён засінхранізаваўся. Павазіліся з сістэмай, якая дазваляе сцэнары прайграваць выразна па часе, каб трохмерны досвед можна было, як у фільме, пракручваць наперад-назад. Калі з класічнымі анімацыямі гэта працуе "са скрынкі", то з сістэмамі часціц прыйшлося павазіцца. У нейкі момант яны пачынаюць спауніцца, і калі ты апыняешся дзесьці да кропкі спауна, яны яшчэ не нарадзіліся, хоць накшталт павінны быць. Але гэтая праблема, насамрэч, дастаткова лёгка вырашаецца.
Для мабільнай часткі архітэктура дастаткова простая. Для тэлетрансляцыі ўсё больш складана. У нас былі абмежаванні па жалезе. Ад заказчыка была пастаўлена ўмова: "Вось у нас ёсць такі-то парк жалеза, груба кажучы, трэба, каб на ім усё працавала". Мы адразу арыентаваліся на тое, што будзем працаваць з адносна бюджэтнымі картамі відэазахопу. Але бюджэтныя - гэта не значыць, што дрэнныя.
Было абмежаванне па жалезе, па картах відэазахопу і па ўмовах працы - як мы павінны атрымліваць карцінку. Карты захопу – Blackmagic Design, працавалі па схеме Internal keying – гэта калі да цябе заходзіць відэакадр з камеры. У карткі ёсць свой працэсінгавы чып, куды заводзіцца яшчэ і кадр, які павінен накладвацца па-над уваходным. Картка іх змешвае - больш мы там нічога не чапаем і не ўплываем на кадр з відэакамеры. Вынік праз відэавыхад яна выплёўвае на пультавую. Гэта добры метад для накладвання тытраў і іншых падобных рэчаў, але ён не вельмі падыходзіць для эфектаў змешанай рэальнасці, бо там шмат абмежаванняў на render pipeline.
Зміцер: З пункту гледжання вылічэнняў у рэальным часе, прывязкі аб'ектаў ці чагосьці яшчэ?
Андрэй: З пункту гледжання якасці і дасягненні патрэбных эфектаў. З-за таго, што мы не ведаем, па-над чым накладваем карцінку. Мы проста аддаём інфармацыю аб колеры і празрыстасці па-над зыходным патокам. Некаторых эфектаў накшталт праламленняў, карэктнай празрыстасці, дадатковых ценяў пры такой схеме немагчыма дабіцца. Для гэтага трэба ўсё рэндэрыць разам. Напрыклад, ніяк не атрымаецца зрабіць эфект скажэння паветра ад вогнішча ці ад гарачага асфальту. Тое ж самае з перадачай эфекту празрыстасці з улікам паказчыка праламлення. Мы першапачаткова рабілі кантэнт, зыходзячы з гэтых абмежаванняў, і імкнуліся выкарыстоўваць адпаведныя эфекты.
Зміцер: У вас быў свой кантэнт ужо на першым праекце для Еўрапейскіх гульняў?
Андрэй: Не, асноўны этап распрацоўкі кантэнту быў за рабятамі з Sechenov.com. Іх графісты малявалі базавы кантэнт з анімацыямі і іншымі рэчамі. А мы ўсё інтэгравалі ў рухавічок, дакручвалі дадатковыя эфекты, адаптавалі, каб усё правільна працавала.
Калі казаць пра пайплайн, то для тэлевяшчання мы ўсё збіралі на Unreal Engine 4. Так супала, што яны як раз у той момант пачалі фарсіць свой інструментар для змяшанай рэальнасці (mixed reality). Аказалася, што ўсё не так проста. Увесь інструментарый нават зараз сыры, нам шмат прыйшлося ўручную дапілоўваць. У Менску мы працавалі на кастамнай зборцы рухавічка, гэта значыць мы некаторыя рэчы ўсярэдзіне рухавічка перапісвалі, каб, напрыклад, можна было цені маляваць па-над рэальнымі аб'ектамі. На той версіі рухавічка, якая была тады актуальная, не было фіч, якія дазваляюць гэта рабіць з дапамогай стандартнага інструментара. Па гэтай прычыне ў нас хлопцы рабілі сваю кастамную зборку, каб забяспечыць усё, што было жыццёва неабходна.
Іншыя нюнасы і адаптацыя да WorldSkills у Казані
Таймкод (па ) — 31:37
Зміцер: Але ўсё гэта ў дастаткова сціснутыя тэрміны?
Андрэй: Сціснутыя тэрміны былі па , па менскім - нармальныя. Недзе паўгода на распрацоўку, але з улікам таго, што было задзейнічана шэсць чалавек. Паралельна рабілі мабільную частку, распрацоўвалі інструментарый для тэлепрадакшэна. Там была не толькі выснова карцінкі. Напрыклад, сістэма трэкінга з оптыкай, для гэтага трэба было свой інструментарый рабіць.
Зміцер: Была адаптацыя ад аднаго праекту да іншага? За паўтара месяца трэба было скарыстацца напрацоўкамі і перакласці праект з новым кантэнтам на новую пляцоўку?
Андрэй: Так, гэта было за паўтара месяца. У нас быў запланаваны двухтыднёвы водпуск усёй каманды пасля мінскага праекта. Але адразу пасля закрыцця хлопцы з Sechenov.com падыходзяць і кажуць: "Ну што, давайце тады Казань рабіць". Мы ўсё ж паспелі крыху адпачыць, але пераключыліся на гэты праект досыць хутка. Нешта дарабілі па тэхнічнай частцы. Вялікая частка часу была выдаткавана на кантэнт, таму што для WorldSkills яго цалкам мы рабілі, проста ўзгаднялі з рэжысёрскай камандай. Зь іх боку быў толькі сцэнар. Але было лягчэй - не трэба было лішніх ітэрацый. Калі ты робіш кантэнт сам, адразу бачыш, як гэта ў рухавічку працуе, можаш хутка кіраваць і ўзгадняць.
Па мабільнай частцы ўлічылі ўсе тонкасці, якія ў нас былі па Мінску. Зрабілі новы дызайн прыкладання, перапрацавалі крыху архітэктуру, дадалі тутарыялаў, але максімальна коратка і наглядна пастараліся зрабіць. Скарацілі колькасць крокаў карыстальніка ад запуску дадатку да прагляду кантэнту. Паўтара месяца хапіла, каб зрабіць адэкватны праект. За паўтара тыдня выйшлі на пляцоўку. Там працаваць было прасцей, бо ўвесь кантроль над праектам быў у руках арганізатараў, не трэба было ўзгадняць з іншымі камітэтамі. У Казані было прасцей і лягчэй працаваць і нармальна, што часу было менш.
Зміцер: Але падыход да сінхранізацыі вы вырашылі пакінуць, як ён і быў, па гуку?
Андрэй: Так, мы пакінулі па гуку. Працавала добра. Як гаворыцца, калі працуе, не чапай. Мы проста ўлічылі нюансы па якасці гукавой дарожкі. Калі рабілі ўступ, якраз быў трэніровачны эпізод, каб людзі маглі паспрабаваць да таго, як шоу пачнецца. Было дзіўна, што калі ў момант прайгравання трэка на стадыёне ідуць бурныя апладысменты, "жывыя", сістэма дазваляе добра сінхранізавацца па гэтым трэку, але калі ў гэты момант разам з трэкам прымешваюцца запісаныя апладысменты, то трэк перастае лавіцца. Вось падобныя нюансы ўлічылі, і па гуку ўсё дастаткова добра сінхранізавалася.
PS У другой частцы выпуску мы гаворым аб навуковай візуалізацыі дадзеных, мадэляванні працэсаў у іншых праектах, геймдэве і магістарскай праграме.». Апублікуем працяг у наступным матэрыяле. Паслухаць і падтрымаць нас можна тут:
PPS Тым часам на англамоўнай версіі Хабра: .
Крыніца: habr.com