Get best of the week

ITMO Research_ podcast: como abordar a sincronização do conteúdo de RA com o show na escala de todo o estádio

Esta é a primeira parte da transcrição da segunda entrevista de texto para o nosso programa ( Apple Podcasts , Yandex.Music ). Convidado de lançamento - Andrey Karsakov (kapc3d), Ph.D., pesquisador sênior do Centro Nacional de Desenvolvimento Cognitivo, Professor Associado do Departamento de Transformações Digitais.

Desde 2012, Andrey trabalha no grupo científico Visualização e Computação Gráfica. Ele está envolvido em projetos aplicados em larga escala nos níveis estadual e internacional. Nesta parte da conversa, falamos sobre sua experiência de acompanhamento de eventos de massa em RA.


Foto ThisisEngineering RAEng (Unsplash.com)


Contexto e objetivos do projeto


Código de tempo ( versão em áudio ) - 00:41


dmitrykabanov: Gostaria de começar com o projeto dos Jogos Europeus. É multicomponente, várias equipes participaram da preparação e fornecer uma realidade aumentada para um público de milhares de milhares de pessoas durante o evento no estádio é uma tarefa bastante séria. Em termos de sua participação, este software foi o primeiro?

kapc3d: Sim, fizemos o software parte e fornecemos acompanhamento durante o show. Era necessário monitorar, monitorar e lançar tudo em tempo real, além de trabalhar com um grupo de televisão. Se considerarmos este projeto como um todo, podemos falar sobre as cerimônias de abertura e encerramento dos Jogos Europeus em Minsk, bem como sobre a cerimônia de abertura do campeonato WorldSkills em Kazan. Era o mesmo esquema de trabalho, mas atividades diferentes. Entre eles havia um intervalo de dois meses. Preparamos o projeto junto com os caras do Sechenov.com .

Encontrei-os por acaso no Science Festque ocorreu no outono de 2018. Nossos alunos de graduação mostraram seu projeto de curso sobre o tema da RV. Os caras se aproximaram de nós e perguntaram o que estávamos fazendo em nosso laboratório. Parecia algo assim:

- Então você está trabalhando com VR, mas é capaz com realidade aumentada?

"Bem, mais ou menos sim."

- Existe uma tarefa com essas introdutórias. Consegues fazê-lo?

Arranhamos um pouco os nabos, parece que não há nada de irreal:

- Vamos tentar estudar tudo com antecedência e depois encontraremos uma solução.

Dmitry: Eles lidam apenas com suporte de mídia?

Andrew:Faça uma pilha cheia. Do ponto de vista da gerência e da organização - eles estão totalmente engajados na direção, encenação, seleção de cenários, logística e outro suporte técnico. Mas eles queriam fazer algo especial para os Jogos Europeus. Esses efeitos especiais, como a realidade mista, vêm ocorrendo na televisão há muito tempo, mas não são os mais orçamentários em termos de implementação técnica. Portanto, os caras estavam procurando alternativas.

Dmitry: Vamos discutir o problema com mais detalhes. Como ela era?

Andrew: Há um evento. Dura uma hora e meia. É necessário garantir que o público que assiste ao vivo e os que estão sentados no estádio possam ver os efeitos com realidade aumentada, com total sincronização com o show ao vivo, em horário e local no site.

Havia várias limitações técnicas. Era impossível fazer a sincronização do tempo via Internet, porque havia receios sobre a carga excessiva na rede com estandes completos e a perspectiva de participar do evento pelos chefes de Estado, por causa das quais as redes móveis poderiam congestionar.

Andrey Karsakov, foto do material da ITMO University.
Tivemos dois componentes principais deste projeto - a experiência pessoal que as pessoas podem obter através de dispositivos móveis e o que acontece nas transmissões de televisão e nas telas de informações no próprio estádio.

Se de repente uma pessoa assiste episódios de realidade aumentada através de um dispositivo móvel e simultaneamente atinge a tela, ela deve ver a mesma imagem.

Precisávamos de dois sistemas realmente diferentes para sincronizar completamente com o tempo. Mas a peculiaridade de tais programas é que são eventos complexos, onde um grande número de serviços técnicos está envolvido e todas as operações são executadas de acordo com os códigos de tempo. Um código de tempo é um momento específico no qual algo começa: luz, som, pessoas saem, pétalas de palco de abertura e assim por diante. Tivemos que nos adaptar a esse sistema para que tudo começasse no momento certo. Outra característica foi que cenas e episódios com realidade aumentada foram encenados juntos.

Dmitry:Mas você ainda decidiu abandonar o uso de códigos de tempo, devido aos altos riscos de força maior, ou inicialmente calculou algumas características de energia e percebeu que a carga em todo o sistema seria bastante alta?

Andrew: Se você faz um serviço de sincronização para esse público, não é muito difícil. As solicitações, em qualquer caso, não caem ao mesmo tempo. Sim, a carga é alta, mas isso não é uma emergência. A questão é se vale a pena gastar recursos e tempo com isso, se a rede for subitamente extinta. Não tínhamos certeza de que isso não aconteceria. Por fim, tudo funcionou intermitentemente devido à carga, mas funcionou, e sincronizamos usando o código de tempo de uma maneira diferente. Foi um dos desafios globais.


Desafios de implementação de UX


Código de tempo ( versão em áudio ) - 10:42


Andrei: Também tivemos que considerar que o estádio não é um local de concertos clássico e sincronizar os sistemas no espaço para dispositivos móveis. Então, há algum tempo, uma história com realidade aumentada foi violada nos shows do Eminem, e houve um caso com Loboda.

Foto de Robert Bye (Unsplash.com)
Mas essa é sempre uma experiência à sua frente - toda a multidão está de frente para a cena, a sincronização é bastante simples. No caso do estádio, você precisa entender de que lado você está na circunferência, a posição relativa para que o estádio fique no espaço que está no ambiente virtual. Foi um desafio azedo. Eles tentaram resolvê-lo de várias maneiras, e chegamos a um caso próximo do que foi implementado por Loboda, mas não em tudo.

Deixamos o usuário decidir onde ele está. Eles fizeram o layout do estádio, onde as pessoas escolheram o setor, a fila, o local. Tudo isso em quatro "cliques". Em seguida, tivemos que determinar a direção da cena. Para fazer isso, mostramos uma silhueta da aparência de uma cena do ponto de vista do usuário. Ele combinou, bateu e é isso - a cena se sentou. Tentamos simplificar esse processo o máximo possível. Ainda assim, 90% dos espectadores que queriam assistir ao programa não são as pessoas que têm experiência com a realidade aumentada.

Dmitry: Havia um aplicativo separado para este projeto?

Andrei: Sim, o aplicativo para iOS e Android, que empurramos para o lado. Nele havia uma campanha promocional separada. Foi descrito anteriormente em detalhes como fazer o download e muito mais.

Dmitry:Você precisa entender que uma pessoa não tem onde verificar fisicamente e aprender a usar esse aplicativo. Portanto, a tarefa de "treinar" o público era complicada.

Andrew: Sim, sim. Com o UX, capturamos muitos cones, porque o usuário deseja a experiência em três cliques: baixado, instalado, lançado, funcionou. Muitos têm preguiça de passar por tutoriais complexos, ler treinamento e muito mais. E não tentamos explicar tudo ao usuário no tutorial o máximo possível: uma janela será aberta aqui, o acesso à câmera aqui, caso contrário, não funcionará, e assim por diante. Não importa quantas explicações você escreva, o quanto você mastiga em detalhes, quaisquer que sejam os GIFs inseridos, as pessoas não leem isso.

Em Minsk, coletamos um grande conjunto de comentários para essa parte e já mudamos muito para o aplicativo em Kazan. Dirigimos lá não apenas aqueles fonogramas e códigos de tempo que correspondem a um episódio específico de realidade aumentada, mas também pegamos todos os fonogramas e códigos de tempo completamente. Portanto, o aplicativo ouviu o que estava acontecendo no momento do lançamento e - se a pessoa não tivesse entrado naquele momento - forneceria informações: "Camarada, desculpe, seu episódio de recuperação de dependência será em 15 minutos".


Um pouco sobre a arquitetura e a abordagem da sincronização


Código de tempo ( versão em áudio ) - 16:37


Dmitry: Ainda decidiu fazer a sincronização pelo som?

Andrei: Sim, aconteceu por acaso. Separamos as opções e encontramos uma empresa da Cifrasoft de Izhevsk. Eles não são realmente elaborados, mas um SDK que funciona com ferro de passar, que permite sincronizar o som com o tempo por som. O sistema foi posicionado para funcionar com a TV, quando você pode produzir algo no aplicativo ou fornecer conteúdo interativo com o som da publicidade condicional.

Dmitry: Mas uma coisa é que você está sentado na sua sala de estar, e outra é um estádio com vários mil. Como você gerencia a qualidade da gravação de som e seu subsequente reconhecimento?

Andrew:Havia muitos medos e dúvidas, mas na maioria dos casos tudo era bem reconhecido. Eles constroem assinaturas na trilha sonora com seus algoritmos complicados - o total pesa menos que o arquivo de áudio original. Quando o microfone ouve o som ambiente, ele tenta encontrar esses recursos e reconhecer a faixa por eles. Em boas condições, a precisão da sincronização é de 0,1 a 0,2 segundos. Isso foi mais do que suficiente. Em condições precárias, a discrepância era de até 0,5 segundos.

Depende muito do dispositivo. Trabalhamos com uma grande frota de dispositivos. Para iPhones, estes são apenas 10 modelos. Eles funcionaram bem em termos de qualidade e outros recursos. Mas com os andróides, o zoológico é tal que minha mãe. Em todos os lugares, a sincronização de som funcionou. Houve casos em que em dispositivos diferentes, além de faixas diferentes, era impossível ouvir por causa de alguns recursos. Em algum lugar as frequências baixas saem, em algum lugar alto começam a chiar. Mas se o dispositivo tivesse um normalizador no microfone, a sincronização sempre funcionaria.

Dmitry: Por favor, conte-nos sobre arquitetura - o que foi usado no projeto?

Andrew:Criamos o aplicativo no Unity - a opção mais fácil em termos de multiplataforma e gráficos. Fundação AR usada. Dissemos imediatamente que não gostaríamos de complicar o sistema, por isso nos limitamos a uma frota de dispositivos que suportam ARKit e ARCore para ter tempo de testar tudo. Criamos um plug-in para o Tsifirasoft SDK, que fica conosco no GitHub . Criamos um sistema de gerenciamento de conteúdo para que os scripts sejam executados em uma linha do tempo.

Nós mexemos um pouco no sistema de partículas, porque o usuário pode efetuar login a qualquer momento de um episódio específico e precisa ver tudo a partir do momento em que sincronizou. Mexer com um sistema que permite que os scripts sejam reproduzidos com clareza no tempo, para que uma experiência tridimensional possa ser rolada para frente e para trás, como em um filme. Se der certo com animações clássicas, tive que mexer nos sistemas de partículas. Em algum momento, eles começam a desovar, e se você se encontrar em algum lugar até o ponto de desovar, eles ainda não nasceram, embora pareçam estar. Mas esse problema, de fato, é facilmente resolvido.

Para a parte móvel, a arquitetura é bastante simples. Para transmissão, tudo é mais complicado. Tínhamos limitações no ferro. A condição foi estabelecida pelo cliente: "Aqui temos um parque de ferro, de um modo geral, tudo precisa funcionar nele". Focamos imediatamente o fato de trabalharmos com placas de captura de vídeo de custo relativamente baixo. Mas o orçamento não significa que eles são ruins.

Havia uma restrição no hardware, nas placas de captura de vídeo e nas condições de trabalho - como deveríamos tirar uma foto. Cartões de captura - Blackmagic Design, trabalhados de acordo com o esquema de codificação interna - é quando um quadro de vídeo sai da câmera. O cartão possui seu próprio chip de processamento, que também possui um quadro que deve ser sobreposto no cartão de entrada. O cartão os mistura - quanto mais não tocamos em nada e não afetamos o quadro da câmera de vídeo. O resultado através da saída de vídeo, ela cospe no controle remoto. Esse é um bom método para aplicar legendas e outras coisas semelhantes, mas não é muito adequado para efeitos de realidade mista, porque existem muitas restrições no pipeline de renderização.

Dmitry: Em termos de computação em tempo real, vinculação de objetos ou algo mais?

Andrew:Em termos de qualidade e obtenção dos efeitos desejados. Devido ao fato de não sabermos o que sobrepõe a imagem em cima. Simplesmente fornecemos informações de cor e transparência sobre o fluxo original. Alguns efeitos como refrações, transparência correta, sombras adicionais com esse esquema não podem ser alcançados. Para fazer isso, é necessário renderizar tudo juntos. Por exemplo, não funcionará de maneira alguma para causar o efeito de distorção do ar de um incêndio ou do asfalto quente. O mesmo ocorre com a transmissão do efeito de transparência, levando em consideração o índice de refração. Inicialmente, criamos o conteúdo com base nessas restrições e tentamos usar os efeitos apropriados.


Dmitry: Você teve seu conteúdo no primeiro projeto dos Jogos Europeus?

Andrew: Não, o principal estágio de desenvolvimento de conteúdo foram os caras do Sechenov.com. Seus artistas gráficos desenhavam conteúdo básico com animações e outras coisas. E integramos tudo ao mecanismo, adicionamos efeitos adicionais, adaptamos para que tudo funcionasse corretamente.

Se falamos sobre o oleoduto, então para a televisão coletamos tudo no Unreal Engine 4. Coincidiu que eles naquele momento começaram a forçar suas ferramentas para a realidade mista (realidade mista). Descobriu-se que nem tudo é tão simples. Todas as ferramentas são cruas até agora, tivemos que terminar muito manualmente. Em Minsk, trabalhamos em uma montagem personalizada do mecanismo, ou seja, reescrevemos algumas coisas dentro do mecanismo para que, por exemplo, pudéssemos desenhar sombras em cima de objetos reais. Nessa versão do mecanismo, que era então relevante, não havia recursos que permitissem isso usando ferramentas padrão. Por esse motivo, nossos funcionários fizeram sua montagem personalizada para fornecer tudo o que era vital.


Outras nuances e adaptação ao WorldSkills em Kazan


Código de tempo (para versão em áudio ) - 31:37


Dmitry: Mas tudo isso em pouco tempo?

Andrei: Os prazos eram para o projeto Kazan , para Minsk - normal. Cerca de seis meses para se desenvolver, mas levando em conta o fato de seis pessoas estarem envolvidas. Ao mesmo tempo, eles fizeram a parte móvel, desenvolveram ferramentas para teleprodução. Não havia apenas uma saída de imagem. Por exemplo, um sistema de rastreamento com óptica, para isso era necessário fazer seu próprio kit de ferramentas.

Dmitry: Houve uma adaptação de um projeto para outro? Durante um mês e meio, foi necessário aproveitar os desenvolvimentos e transferir o projeto com novo conteúdo para um novo site?

Andrew:Sim, foi um mês e meio. Planejamos férias de duas semanas para toda a equipe após o projeto de Minsk. Mas imediatamente após o fechamento, os caras do Sechenov.com aparecem e dizem: "Bem, então deixe Kazan fazer isso". Ainda conseguimos relaxar um pouco, mas mudamos para esse projeto com bastante rapidez. Concluiu algo no lado técnico. A maior parte do tempo era gasta em conteúdo, porque para o WorldSkills nós o fizemos completamente, apenas concordamos com a equipe do diretor. Havia apenas um script da parte deles. Mas foi mais fácil - não foram necessárias iterações extras. Quando você faz o conteúdo, vê imediatamente como ele funciona no mecanismo, é possível editar e coordenar rapidamente.


Na parte móvel, levamos em conta todas as sutilezas que tínhamos em Minsk. Eles criaram um novo design de aplicativo, reformularam um pouco a arquitetura, adicionaram tutoriais, mas tentaram torná-lo o mais curto e claro possível. Reduzido o número de etapas do usuário, desde o lançamento do aplicativo até a exibição do conteúdo. Um mês e meio foi suficiente para fazer um projeto adequado. Durante uma semana e meia, fomos ao site. Era mais fácil trabalhar lá, porque todo o controle sobre o projeto estava nas mãos dos organizadores, não era necessário coordenar com outros comitês. Era cada vez mais fácil trabalhar em Kazan e era bastante normal que houvesse menos tempo.

Dmitry: Mas você decidiu deixar a abordagem da sincronização, por assim dizer, pelo som?

Andrew:Sim, deixamos pelo som. Funcionou bem. Como se costuma dizer, se funcionar, não toque. Apenas levamos em conta as nuances da qualidade da trilha sonora. Quando eles fizeram a introdução, houve apenas um episódio de treinamento para que as pessoas pudessem experimentar antes do show começar. Foi surpreendente que quando no momento de tocar uma pista no estádio houver aplausos tempestuosos, "ao vivo", o sistema permita que você sincronize bem nessa pista, mas se os aplausos gravados forem misturados com a pista naquele momento, a pista deixará de ser capturada. Essas nuances foram levadas em consideração e o som estava bem sincronizado.

PS Na segunda parte do assunto, estamos falando sobre visualização científica de dados, modelagem de processos em outros projetos, desenvolvimento de jogos e o programa de mestrado “ Tecnologia para o Desenvolvimento de Jogos de Computador”" Publicaremos a continuação no seguinte material. Você pode ouvir e apoiar-nos aqui:





PPS Enquanto isso, na versão em inglês do Habr: um olhar mais atento à ITMO University .

More articles:


All Articles