Podcast "ITMO Research_": como abordar a sincronización de contido AR cun espectáculo a escala de todo un estadio

Esta é a primeira parte da transcrición do texto da segunda entrevista para o noso programa (Podcasts de Apple, Yandex.Music). Emitir invitado - Andrei Karsakov (kapc3d), Ph.D., investigador principal do Centro Nacional de Investigacións Cognitivas, profesor asociado na Facultade de Transformacións Dixitais.

Desde 2012, Andrey traballa no grupo de investigación Visualization and Computer Graphics. Participa en grandes proxectos aplicados a nivel estatal e internacional. Nesta parte da conversa, falamos da súa experiencia no soporte de RA para eventos públicos.

Podcast "ITMO Research_": como abordar a sincronización de contido AR cun espectáculo a escala de todo un estadio
foto Isto é Enxeñaría RAEng (Unsplash.com)

Contexto e obxectivos do proxecto

Código de tempo (por versións de audio) - 00:41

dmitrykabanov: Gustaríame comezar co proxecto dos Xogos Europeos. É multicompoñente, varios equipos participaron na preparación e ofrecer realidade aumentada a un público de miles de persoas durante un evento no estadio é unha tarefa bastante seria. En canto á súa participación, foi o software primeiro?

kapc3d: Si, fixemos a parte da programación e brindamos apoio durante o espectáculo. Era necesario rastrexar, supervisar e lanzar todo en tempo real, e tamén traballar co grupo televisivo. Se consideramos este proxecto no seu conxunto, podemos falar das cerimonias de apertura e clausura Xogos Europeos en Minsk, así como sobre a cerimonia de apertura do campionato WorldSkills en Kazán. Era o mesmo esquema de traballo, pero acontecementos diferentes. Houbo un intervalo de dous meses entre eles. Preparamos o proxecto xunto cos rapaces da empresa Sechenov.com.

Coñecémolos por casualidade Festa da Ciencia, que tivo lugar no outono de 2018. Os nosos alumnos de máster mostraron o seu proxecto de curso sobre o tema da RV. Os rapaces achegáronse a nós e preguntáronnos que estabamos facendo no noso laboratorio. Parecía algo así:

— Traballas con VR, pero podes traballar con realidade aumentada?

- Ben, algo así, si.

- Hai tal tarefa, con tales notas introdutorias. Podes facelo?

Raiáronlles un pouco os grelos, non parece haber nada irreal:

- Imos tentar estudalo todo primeiro, e despois buscar unha solución.

Dimitri: Só proporcionan soporte mediático?

Andrew: Eles fan unha pila completa. Dende o punto de vista da xestión e da organización, están totalmente implicados na dirección, posta en escena, selección de escenografía, loxística e outro soporte técnico. Pero querían facer algo especial para os Xogos Europeos. Estes efectos especiais, como a realidade mixta, están feitos para televisión desde hai bastante tempo, pero non son os máis económicos en canto á implantación técnica. Polo tanto, os mozos buscaron opcións alternativas.

Dimitri: Imos discutir o problema con máis detalle. En que consistiu?

Andrew: Hai un evento. Dura hora e media. Debemos asegurarnos de que o público que o ve en directo e os que están sentados no estadio poidan ver os efectos de realidade aumentada en plena sincronización co espectáculo en directo en termos de hora e localización no sitio.

Había unha serie de limitacións técnicas. Era imposible facer a sincronización horaria a través de Internet, porque se temía unha carga excesiva na rede con stands cheos e a perspectiva de que os xefes de Estado asistiran ao evento, o que podería atascar as redes móbiles.

Andrey Karsakov, foto de material da Universidade ITMO
Podcast "ITMO Research_": como abordar a sincronización de contido AR cun espectáculo a escala de todo un estadioTivemos dous compoñentes fundamentais para este proxecto: a experiencia persoal que a xente pode conseguir a través dos dispositivos móbiles e o que pasa nas pantallas de televisión e información do propio estadio.

Se de súpeto unha persoa está vendo episodios de realidade aumentada a través dun dispositivo móbil e ao mesmo tempo aparece na pantalla, debería ver a mesma imaxe.

Necesitabamos dous sistemas practicamente diferentes para estar completamente sincronizados no tempo. Pero a peculiaridade deste tipo de espectáculos é que se trata de eventos complexos nos que interveñen un gran número de servizos técnicos e todas as operacións realízanse segundo códigos de tempo. O código de tempo é un momento específico no tempo no que algo comeza: a luz, o son, a xente que sae, os pétalos do escenario ábrense, etc. Tivemos que adaptarnos a este sistema para que todo comezase no momento oportuno. Outra característica foi que as escenas e episodios con realidade aumentada estaban relacionados co guión.

Dimitri: Pero decidiu abandonar o uso de códigos de tempo debido aos altos riscos de forza maior, ou inicialmente calculou algunhas características de potencia e decatouse de que a carga de todo o sistema sería bastante alta?

Andrew: Se creas un servizo de sincronización para tal público, non é moi difícil. En calquera caso, as solicitudes non fallarán dun día para outro. Si, a carga é alta, pero non é unha emerxencia. A pregunta é se paga a pena gastar recursos e tempo nisto se a rede se apaga de súpeto. Non estabamos seguros de que isto non sucedería. En definitiva, todo funcionou, con interrupcións pola carga, pero funcionou, e sincronizamos segundo o código de tempo segundo un esquema diferente. Este foi un dos retos mundiais.

Dificultades de implementación desde o punto de vista UX

Código de tempo (por versións de audio) - 10:42

Andrew: Tamén tivemos que ter en conta que o estadio non é unha sala de concertos clásica, e sincronizar os sistemas en todo o espazo para dispositivos móbiles. Entón, fai un tempo fun viral historia de realidade aumentada nos concertos de Eminem, despois houbo un caso con Loboda.

foto Robert Bye (Unsplash.com)
Podcast "ITMO Research_": como abordar a sincronización de contido AR cun espectáculo a escala de todo un estadioPero esta sempre é unha experiencia diante de ti: toda a multitude está diante do escenario, a sincronización é bastante sinxela. No caso dun estadio, cómpre comprender de que lado do círculo estás, a posición relativa, para que o estadio encaixe no espazo que existe no entorno virtual. Foi un reto amargo. Intentaron solucionalo de varias maneiras, e o resultado foi un caso próximo ao implantado por Loboda, pero non en todos os aspectos.

Deixamos que o usuario decida onde está. Fixemos marcas para o estadio, onde a xente elixía un sector, unha fila, un lugar. Todo isto en catro "clics". A continuación tivemos que determinar a dirección do escenario. Para iso, mostramos unha silueta de como debería ser aproximadamente a escena desde unha perspectiva personalizada. Combinouno, tocou e xa está: o escenario sentouse. Intentamos simplificar este proceso o máximo posible. Aínda así, o 90% dos espectadores que querían ver o programa non son aquelas persoas que teñan experiencia comunicando coa realidade aumentada.

Dimitri: Houbo unha solicitude separada para este proxecto?

Andrew: Si, unha aplicación para iOS e Android, que levamos á tenda. Houbo unha campaña de promoción separada para iso. Describiuse previamente en detalle como descargar e así por diante.

Dimitri: Debe entender que non hai lugar para que unha persoa poida probar fisicamente e aprender a usar tal aplicación. Polo tanto, a tarefa de "educar" ao público fíxose máis complicada.

Andrew: Si Si. Con UX, collemos moitos golpes, porque o usuario quere obter a experiencia en tres clics: descargado, instalado, lanzado - funcionou. Moita xente ten preguiza para seguir titoriais complexos, ler titoriais, etc. E non tentamos explicar todo ao usuario na medida do posible no titorial: abrirase unha xanela aquí, acceder á cámara aquí, se non, non funcionará, etc. Por moitas explicacións que escribas, por moi detallado que o mastigues, por moito que insiras os gifs, a xente non o le.

En Minsk recollemos unha gran cantidade de comentarios sobre esta parte e xa cambiamos moito para a aplicación en Kazán. Poñemos alí non só aqueles fonogramas e aqueles códigos de tempo que corresponden a un episodio concreto de realidade aumentada, senón que collemos todos os fonogramas e códigos de tempo na súa totalidade. Entón, a aplicación escoitou o que estaba a suceder no momento do lanzamento e, se unha persoa iniciaba sesión no momento equivocado, deu a información: "Camarada, perdón, o teu episodio de AR será en 15 minutos".

Un pouco sobre a arquitectura e o enfoque da sincronización

Código de tempo (por versións de audio) - 16:37

Dimitri: ¿Decidiches sincronizar por son?

Andrew: Si, ocorreu por casualidade. Buscamos opcións e atopamos unha empresa Cifrasoft de Izhevsk. Eles fan un SDK non especialmente sofisticado, pero moi útil, que permite sincronizar o son coa sincronización. O sistema foi posicionado para funcionar con TV, cando pode mostrar algo nunha aplicación baseada no son dun anuncio condicional ou ofrecer unha experiencia interactiva baseada na pista da película.

Dimitri: Pero unha cousa é: estás sentado na túa sala de estar e outra cousa: un estadio con miles de persoas. Como lle saíron as cousas coa calidade da gravación de son e o seu posterior recoñecemento?

Andrew: Había moitos medos e dúbidas, pero na maioría dos casos todo estaba ben recoñecido. Constrúen sinaturas na pista de audio cos seus algoritmos astutos: o resultado pesa menos que o ficheiro de audio orixinal. Cando o micrófono escoita o son circundante, tenta atopar estas características e recoñecer a pista en función delas. En boas condicións, a precisión do tempo é de 0,1-0,2 segundos. Isto foi máis que suficiente. En malas condicións a discrepancia foi de ata 0,5 segundos.

Depende moito do dispositivo. Traballamos cunha gran flota de dispositivos. Para iPhones só hai 10 modelos. Funcionaron ben en termos de calidade e outras características. Pero cos androides o zoo é coma a miña nai. Non en todas partes resultou que a sincronización de son funcionaba. Houbo casos nos que era imposible escoitar diferentes pistas en distintos dispositivos debido a algunhas peculiaridades. Nalgún lugar as frecuencias baixas desaparecen, nalgún lugar as frecuencias altas comezan a sibilar. Pero se o dispositivo tiña un normalizador no micrófono, a sincronización sempre funcionaba.

Dimitri: Fálanos da arquitectura: que se utilizou no proxecto?

Andrew: Fixemos a aplicación en Unity, a opción máis sinxela en canto a multiplataforma e traballo con gráficos. Fundación AR usada. Inmediatamente dixemos que non queriamos complicar o sistema, polo que nos limitamos a unha flota de dispositivos compatibles con ARKit e ARCore para ter tempo para probalo todo. Fixemos un complemento para o SDK de DigitalSoft está no noso GitHub. Creamos un sistema de xestión de contidos para que os guións se executasen segundo a liña de tempo.

Repasamos un pouco o sistema de partículas, porque o usuario pode entrar en calquera momento nun episodio concreto, e necesitamos que vexa todo desde o momento desde o que se sincronizou. Modificamos un sistema que permite que os escenarios se reproduzan con claridade no tempo, para que a experiencia 3D se poida desprazar cara atrás e cara atrás, como nunha película. Aínda que funciona fóra da caixa con animacións clásicas, tivemos que xogar cos sistemas de partículas. Nalgún momento, comezan a aparecer, e se te atopas nalgún lugar antes do punto de desova, aínda non naceron, aínda que parece que deberían estar. Pero este problema é realmente doado de resolver.

Para a parte móbil, a arquitectura é bastante sinxela. Para as emisións televisivas todo é máis complicado. Tiñamos restricións de hardware. O cliente puxo unha condición: "Aquí temos tal ou tal parque de ferraxes, grosso modo, todo hai que traballar nel". Inmediatamente centrámonos no feito de que traballariamos con tarxetas de captura de vídeo relativamente económicas. Pero o orzamento non significa que sexan malos.

Había restricións no hardware, nas tarxetas de captura de vídeo e nas condicións de traballo: como deberíamos recibir a imaxe. Tarxetas de captura - Blackmagic Design, funcionan segundo o esquema de teclas internas - é cando che chega un fotograma de vídeo desde a cámara. A tarxeta ten o seu propio chip de procesamento, onde tamén se insire un marco, que debe ser superposto sobre o entrante. A tarxeta mestúraos: non tocamos nada máis alí e non afectamos o cadro da cámara de vídeo. Ela escupe o resultado á sala de control a través da saída de vídeo. Este é un bo método para superpoñer títulos e outras cousas similares, pero non é moi axeitado para efectos de realidade mixta porque hai moitas restricións na canalización de renderizado.

Dimitri: En termos de computación en tempo real, vinculación de obxectos ou outra cousa?

Andrew: En canto á calidade e a consecución dos efectos desexados. Porque non sabemos o que estamos a poñer a imaxe enriba. Simplemente enviamos información de cor e transparencia enriba do fluxo orixinal. Con este esquema non se poden conseguir algúns efectos como as refraccións, a transparencia correcta e as sombras adicionais. Para iso, debes renderizar todo xunto. Por exemplo, non hai forma de crear o efecto da distorsión do aire por un incendio ou un asfalto quente. O mesmo ocorre coa transferencia do efecto de transparencia tendo en conta o índice de refracción. Inicialmente fixemos contido baseado nestas restricións e tentamos utilizar os efectos axeitados.

Ver esta publicación en Instagram

Clausura dos II Xogos Europeos en Minsk.

Unha publicación compartida por Alena Lanskaya (@alyonalanskaya) o 30 de xuño de 2019 ás 3:19 PDT

Dimitri: Xa tiñas contido propio no primeiro proxecto dos Xogos Europeos?

Andrew: Non, a etapa principal do desenvolvemento de contidos foi realizada polos mozos de Sechenov.com. Os seus artistas gráficos debuxaron o contido básico con animacións e outras cousas. E integramos todo no motor, engadimos efectos adicionais, adaptámolo para que todo funcionase correctamente.

Se falamos do gasoduto, entón para a transmisión televisiva montamos todo en Unreal Engine 4. Casualmente, xusto nese momento comezaron a impulsar as súas ferramentas para a realidade mixta. Resultou que non todo é tan sinxelo. Aínda agora todas as ferramentas están en bruto, tivemos que rematar moito a man. En Minsk traballamos nunha construción personalizada do motor, é dicir, reescribimos algunhas cousas dentro do motor para, por exemplo, debuxar sombras enriba de obxectos reais. Na versión do motor que existía nese momento, non había características que permitisen facelo utilizando ferramentas estándar. Por este motivo, os nosos rapaces fixeron a súa propia montaxe personalizada para proporcionar todo o que fose de vital importancia.

Outros matices e adaptación a WorldSkills en Kazán

Código de tempo (por versións de audio) - 31:37

Dimitri: Pero todo isto nun período de tempo bastante curto?

Andrew: Os prazos foron axustados Proxecto Kazan, segundo Minsk - normal. Uns seis meses para o desenvolvemento, pero tendo en conta o feito de que participaron seis persoas. Ao mesmo tempo, estabamos facendo a parte móbil e desenvolvendo ferramentas para a produción televisiva. Non só houbo unha saída de imaxe. Por exemplo, un sistema de seguimento con óptica, para iso tiñas que crear as túas propias ferramentas.

Dimitri: Houbo algunha adaptación dun proxecto a outro? En mes e medio, foi necesario aproveitar as novidades e trasladar o proxecto con novos contidos a un novo sitio?

Andrew: Si, foi durante mes e medio. Tiñamos planeadas unhas vacacións de dúas semanas para todo o equipo despois do proxecto de Minsk. Pero inmediatamente despois de pechar, os mozos de Sechenov.com achéganse e din: "Ben, imos facer Kazan entón". Aínda conseguimos descansar un pouco, pero cambiamos a este proxecto bastante rápido. Realizamos un traballo técnico. A maior parte do tempo dedicouse ao contido, porque para WorldSkills fixémolo por completo, só o coordinámolo co equipo de produción. Só houbo un guión pola súa parte. Pero era máis fácil: non había necesidade de iteracións adicionais. Cando crea contido vostede mesmo, ve inmediatamente como funciona no motor e pode editar e coordinar rapidamente.


En canto á parte móbil, tivemos en conta todas as sutilezas que tiñamos en Minsk. Fixemos un novo deseño de aplicación, redeseñamos un pouco a arquitectura, engadimos titoriais, pero intentamos que fose o máis breve e claro posible. Reducimos o número de pasos do usuario desde o inicio da aplicación ata a visualización do contido. Mes e medio foi suficiente para completar un proxecto adecuado. Nunha semana e media chegamos ao lugar. Alí era máis doado traballar porque todo o control do proxecto estaba en mans dos organizadores, non había que coordinarse con outras comisións. Era máis sinxelo e sinxelo traballar en Kazán e era bastante normal que houbese menos tempo.

Dimitri: Pero decidiches deixar o enfoque da sincronización como estaba, baseado no son?

Andrew: Si, deixámolo por son. Funcionou ben. Como se di, se funciona, non o toques. Simplemente tivemos en conta os matices da calidade da pista de audio. Cando fixeron a intro, houbo un episodio de adestramento para que a xente o probase antes de que comezase o programa. Sorprende que cando no momento de tocar a pista no estadio hai un aplauso tormentoso, "en directo", o sistema permite sincronizar ben con esta pista, pero se neste momento os aplausos gravados se mesturan coa pista, entón o a pista xa non está atrapada. Tivéronse en conta tales matices e todo estaba bastante ben sincronizado en canto ao son.

P.S. Na segunda parte do número fálase de visualización de datos científicos, modelado de procesos noutros proxectos, desenvolvemento de xogos e do máster "Tecnoloxía de desenvolvemento de xogos de ordenador" Publicaremos unha continuación no próximo artigo. Podes escoitarnos e apoiarnos aquí:

P.P.S. Mentres tanto, na versión inglesa de Habr: unha ollada máis atenta á ITMO University.

Fonte: www.habr.com

Engadir un comentario