Esta es la primera parte de la transcripción del texto de la segunda entrevista de nuestro programa (, ). Invitado del problema - (), Ph.D., investigador principal del Centro Nacional de Investigación Cognitiva, profesor asociado de la Facultad de Transformaciones Digitales.
Desde 2012, Andrey trabaja en el grupo de investigación Visualización y Gráficos por Computadora. Participa en grandes proyectos aplicados a nivel estatal e internacional. En esta parte de la conversación hablamos de su experiencia en soporte de AR para eventos públicos.
Galleria (Unsplash.com)
Contexto y objetivos del proyecto.
Código de tiempo (por ) — 00:41
: Me gustaría empezar con el proyecto de los Juegos Europeos. Es multicomponente, en su preparación participaron varios equipos y ofrecer realidad aumentada a miles de espectadores durante un evento en el estadio es una tarea bastante seria. En términos de su participación, ¿fue primero el software?
: Sí, hicimos la parte de programación y brindamos apoyo durante el show. Fue necesario rastrear, monitorear y lanzar todo en tiempo real, y también trabajar con el grupo de televisión. Si consideramos este proyecto en su conjunto, entonces podemos hablar de las ceremonias de inauguración y clausura. en Minsk, así como sobre la ceremonia inaugural del campeonato en Kazán. Era el mismo esquema de trabajo, pero eventos diferentes. Hubo una diferencia de dos meses entre ellos. Preparamos el proyecto junto con los chicos de la empresa. .
Los conocimos por casualidad , que tuvo lugar en el otoño de 2018. Nuestros estudiantes de maestría presentaron su proyecto de curso sobre el tema de la realidad virtual. Los chicos se acercaron a nosotros y nos preguntaron qué estábamos haciendo en nuestro laboratorio. Se parecía a esto:
— Trabajas con VR, pero ¿puedes trabajar con realidad aumentada?
- Bueno, más o menos, sí.
- Existe tal tarea, con tales notas introductorias. ¿Puedes hacerlo?
Se rascaron un poco los nabos, no parece que haya nada irreal:
- Intentemos estudiarlo todo primero y luego encontrar una solución.
Dmitry: ¿Solo brindan apoyo mediático?
Andrei: Forman una pila completa. Desde el punto de vista de la dirección y organización, se implican plenamente en la dirección, puesta en escena, selección de escenografía, logística y demás soporte técnico. Pero querían hacer algo especial para los Juegos Europeos. Estos efectos especiales, al igual que la realidad mixta, se han creado para televisión desde hace bastante tiempo, pero no son los más económicos en términos de implementación técnica. Por eso, los chicos buscaban opciones alternativas.
Dmitry: Analicemos el problema con más detalle. ¿En qué consistió?
Andrei: Hay un evento. Tiene una duración de hora y media. Necesitamos asegurarnos de que la audiencia que lo ve en vivo y aquellos que están sentados en el estadio puedan ver los efectos de realidad aumentada en total sincronización con el show en vivo en términos de tiempo y ubicación en el sitio.
Hubo una serie de limitaciones técnicas. Sincronizar el tiempo a través de Internet no fue posible porque se temía una carga excesiva en la red con gradas llenas y la posibilidad de que los jefes de estado asistieran al evento, lo que podría bloquear las redes móviles.
Andrey Karsakov, foto de
Teníamos dos componentes clave para este proyecto: la experiencia personal que las personas pueden obtener a través de dispositivos móviles y lo que se transmite por televisión y las pantallas de información en el estadio mismo.
Si de repente una persona está viendo episodios de realidad aumentada a través de un dispositivo móvil y al mismo tiempo aparece en la pantalla, debería ver la misma imagen.
Necesitábamos dos sistemas prácticamente diferentes para estar completamente sincronizados en el tiempo. Pero la peculiaridad de estos espectáculos es que se trata de eventos complejos en los que intervienen un gran número de servicios técnicos y todas las operaciones se realizan según códigos de tiempo. El código de tiempo es un momento específico en el que algo comienza: luz, sonido, gente saliendo, pétalos del escenario abriéndose, etc. Tuvimos que adaptarnos a este sistema para que todo empezara en el momento adecuado. Otra característica fue que las escenas y episodios con realidad aumentada estaban relacionados con el guión.
Dmitry: Pero, ¿decidiste abandonar el uso de códigos de tiempo debido al alto riesgo de fuerza mayor, o inicialmente calculaste algunas características de potencia y te diste cuenta de que la carga en todo el sistema sería bastante alta?
Andrei: Si crea un servicio de sincronización para esa audiencia, entonces no será muy difícil. En cualquier caso, las solicitudes no fracasarán de la noche a la mañana. Sí, la carga es alta, pero no es una emergencia. La pregunta es si vale la pena gastar recursos y tiempo en esto si la red se corta repentinamente. No estábamos seguros de que esto no sucedería. Al final todo funcionó, con interrupciones por la carga, pero funcionó y sincronizamos según el código de tiempo según un esquema diferente. Éste era uno de los desafíos globales.
Dificultades de implementación desde el punto de vista UX
Código de tiempo (por ) — 10:42
Andrei: También tuvimos que tener en cuenta que el estadio no es una sala de conciertos clásica y sincronizar los sistemas en todo el espacio para dispositivos móviles. Así que hace un tiempo me volví viral. En los conciertos de Eminem, luego hubo un caso con Loboda.
Galleria (Unsplash.com)
Pero lo que tienes delante siempre es una experiencia: toda la multitud se para delante del escenario, la sincronización es bastante sencilla. En el caso de un estadio, es necesario comprender en qué lado del círculo se encuentra, la posición relativa, para que el estadio encaje en el espacio que existe en el entorno virtual. Fue un desafío amargo. Intentaron solucionarlo de varias formas y el resultado fue un caso cercano al implementado por Loboda, pero no en todos los aspectos.
Dejamos que el usuario decida dónde está. Hicimos señalizaciones para el estadio, donde la gente elegía un sector, una fila, un lugar. Todo ello en cuatro “clicks”. A continuación tuvimos que determinar la dirección al escenario. Para hacer esto, mostramos una silueta de cómo debería verse la escena desde una perspectiva personalizada. Lo combinó, hizo tapping y listo: el escenario se sentó. Intentamos simplificar este proceso tanto como fuera posible. Aún así, el 90% de los espectadores que quisieron ver el programa no son personas que tengan experiencia en comunicarse con realidad aumentada.
Dmitry: ¿Hubo una solicitud separada para este proyecto?
Andrei: Sí, una aplicación para iOS y Android, que llevamos a la tienda. Hubo una campaña promocional separada para ello. Anteriormente se describió en detalle cómo descargar, etc.
Dmitry: Debe comprender que no hay lugar para que una persona pruebe físicamente y aprenda a utilizar dicha aplicación. Por tanto, la tarea de “educar” a la audiencia se volvió más complicada.
Andrei: Sí Sí. Con UX, encontramos muchos obstáculos, porque el usuario quiere obtener la experiencia en tres clics: descargar, instalar, ejecutar... funcionó. Muchas personas son demasiado vagas para seguir tutoriales complejos, leer tutoriales, etc. Y no intentamos explicarle todo al usuario lo más posible en el tutorial: aquí se abrirá una ventana, aquí accederá a la cámara, de lo contrario no funcionará, etc. No importa cuántas explicaciones escribas, no importa cuán detalladas las analices, no importa qué gifs insertes, la gente no lo lee.
En Minsk recopilamos una gran cantidad de comentarios sobre esta parte y ya hemos cambiado mucho para la aplicación en Kazán. Pusimos allí no sólo aquellos fonogramas y esos códigos de tiempo que corresponden a un episodio concreto de realidad aumentada, sino que cogimos todos los fonogramas y códigos de tiempo en su totalidad. Entonces, la aplicación escuchó lo que estaba sucediendo en el momento del lanzamiento y, si una persona inició sesión en el momento equivocado, dio la información: "Camarada, lo siento, su episodio AR será en 15 minutos".
Un poco sobre la arquitectura y el enfoque de la sincronización.
Código de tiempo (por ) — 16:37
Dmitry: ¿Decidiste sincronizar por sonido?
Andrei: Sí, sucedió por accidente. Estábamos buscando opciones y encontramos una empresa. de Izhevsk. Crean un SDK no particularmente sofisticado, pero funcional, que le permite sincronizar el sonido con la sincronización. El sistema fue preparado para funcionar con televisión, cuando se puede mostrar algo en una aplicación basándose en el sonido de un anuncio condicional o ofrecer una experiencia interactiva basada en la pista de la película.
Dmitry: Pero una cosa es estar sentado en el salón y otra, un estadio con miles de personas. ¿Cómo te fue con la calidad de la grabación de sonido y su posterior reconocimiento?
Andrei: Hubo muchos temores y dudas, pero en la mayoría de los casos todo se reconoció bien. Crean firmas en la pista de audio con sus astutos algoritmos: el resultado pesa menos que el archivo de audio original. Cuando el micrófono escucha el sonido circundante, intenta encontrar estas características y reconocer la pista basándose en ellas. En buenas condiciones, la precisión de la sincronización es de 0,1 a 0,2 segundos. Esto fue más que suficiente. En malas condiciones la discrepancia era de hasta 0,5 segundos.
Mucho depende del dispositivo. Trabajamos con una gran flota de dispositivos. Para iPhone sólo hay 10 modelos. Funcionaron bien en términos de calidad y otras características. Pero con los androides el zoológico es como mi madre. No en todas partes resultó que la sincronización de sonido funcionara. Hubo casos en los que era imposible escuchar diferentes pistas en diferentes dispositivos debido a algunas peculiaridades. En algún lugar las bajas frecuencias desaparecen, en algún lugar las altas frecuencias comienzan a silbar. Pero si el dispositivo tenía un normalizador en el micrófono, la sincronización siempre funcionaba.
Dmitry: Cuéntenos sobre la arquitectura: ¿qué se utilizó en el proyecto?
Andrei: Hicimos la aplicación en Unity, la opción más sencilla en términos de multiplataforma y trabajo con gráficos. Base AR usada. Inmediatamente dijimos que no queríamos complicar el sistema, así que nos limitamos a una flota de dispositivos compatibles con ARKit y ARCore para tener tiempo de probar todo. Creamos un complemento para DigitalSoft SDK, . Creamos un sistema de gestión de contenidos para que los guiones se ejecutaran según el cronograma.
Jugamos un poco con el sistema de partículas, porque el usuario puede ingresar en cualquier momento a un episodio en particular, y necesitamos que vea todo desde el momento en que se sincronizó. Modificamos un sistema que permite que los escenarios se reproduzcan claramente en el tiempo, de modo que la experiencia XNUMXD pueda desplazarse hacia adelante y hacia atrás, como en una película. Si bien funciona desde el primer momento con animaciones clásicas, tuvimos que experimentar con los sistemas de partículas. En algún momento, comienzan a desovar, y si te encuentras en algún lugar antes del punto de desove, aún no han nacido, aunque parece que deberían nacer. Pero este problema es bastante fácil de resolver.
Para la parte móvil, la arquitectura es bastante sencilla. Para la retransmisión televisiva todo es más complicado. Teníamos restricciones de hardware. El cliente puso una condición: "Aquí tenemos tal o cual parque de hardware, en términos generales, todo debe funcionar en él". Inmediatamente nos centramos en el hecho de que trabajaríamos con tarjetas de captura de vídeo relativamente económicas. Pero el presupuesto no significa que sean malos.
Había restricciones en cuanto al hardware, a las tarjetas de captura de vídeo y a las condiciones de trabajo: cómo debíamos recibir la imagen. Tarjetas de captura: Blackmagic Design, trabajadas según el esquema de codificación interna: aquí es cuando le llega un cuadro de video desde la cámara. La tarjeta tiene su propio chip de procesamiento, donde también se inserta un marco, que debe superponerse al entrante. La tarjeta los confunde: no tocamos nada más allí y no afectamos el cuadro de la cámara de video. Ella escupe el resultado a la sala de control a través de la salida de video. Este es un buen método para superponer títulos y otras cosas similares, pero no es muy adecuado para efectos de realidad mixta porque existen muchas restricciones en el proceso de renderizado.
Dmitry: ¿En términos de computación en tiempo real, vinculación de objetos o algo más?
Andrei: En términos de calidad y consecución de los efectos deseados. Porque no sabemos sobre qué estamos poniendo la imagen. Simplemente enviamos información de color y transparencia además de la transmisión original. Algunos efectos como refracciones, transparencia correcta y sombras adicionales no se pueden lograr con este esquema. Para hacer esto, necesitas renderizar todo junto. Por ejemplo, no hay forma de crear el efecto de distorsión del aire debido a un incendio o asfalto caliente. Lo mismo ocurre con la transferencia del efecto de transparencia teniendo en cuenta el índice de refracción. Inicialmente creamos contenido basándonos en estas restricciones e intentamos utilizar los efectos apropiados.
Dmitry: ¿Tenías ya contenido propio en el primer proyecto para los Juegos Europeos?
Andrei: No, la etapa principal del desarrollo del contenido la realizaron los chicos de Sechenov.com. Sus artistas gráficos dibujaron el contenido básico con animaciones y otras cosas. Y integramos todo en el motor, agregamos efectos adicionales, lo adaptamos para que todo funcionara correctamente.
Si hablamos del pipeline, entonces para la transmisión de televisión ensamblamos todo en Unreal Engine 4. Casualmente, justo en ese momento comenzaron a potenciar sus herramientas para la realidad mixta. Resultó que no todo es tan sencillo. Incluso ahora todas las herramientas están en bruto; tuvimos que terminar muchas cosas a mano. En Minsk trabajamos en una construcción personalizada del motor, es decir, reescribimos algunas cosas dentro del motor para que, por ejemplo, pudiéramos dibujar sombras sobre objetos reales. La versión del motor vigente en ese momento no tenía características que permitieran hacer esto usando herramientas estándar. Por este motivo, nuestros chicos realizaron su propio montaje a medida para aportar todo lo que era de vital importancia.
Otros matices y adaptación a WorldSkills en Kazán
Código de tiempo (por ) — 31:37
Dmitry: ¿Pero todo esto en un periodo de tiempo bastante corto?
Andrei: Los plazos eran ajustados , según Minsk - normal. Unos seis meses de desarrollo, pero teniendo en cuenta que participaron seis personas. Al mismo tiempo estábamos fabricando la parte móvil y desarrollando herramientas para la producción televisiva. No sólo hubo una salida de imagen. Por ejemplo, un sistema de seguimiento con óptica, para ello había que crear sus propias herramientas.
Dmitry: ¿Hubo alguna adaptación de un proyecto a otro? ¿En mes y medio era necesario aprovechar las novedades y trasladar el proyecto con nuevos contenidos a un nuevo sitio?
Andrei: Sí, fue por mes y medio. Habíamos planeado unas vacaciones de dos semanas para todo el equipo después del proyecto de Minsk. Pero inmediatamente después del cierre, los chicos de Sechenov.com se acercan y dicen: "Bueno, entonces hagamos Kazán". Aún así logramos descansar un poco, pero cambiamos a este proyecto bastante rápido. Completamos algunos trabajos técnicos. La mayor parte del tiempo se dedicó al contenido, porque para WorldSkills lo hicimos en su totalidad, simplemente lo coordinamos con el equipo de producción. Sólo había un guión de su parte. Pero fue más fácil: no hubo necesidad de iteraciones adicionales. Cuando crea contenido usted mismo, ve inmediatamente cómo funciona en el motor y puede editarlo y coordinarlo rápidamente.
En cuanto a la parte móvil, tuvimos en cuenta todas las sutilezas que tuvimos en Minsk. Hicimos un nuevo diseño de aplicación, rediseñamos un poco la arquitectura, agregamos tutoriales, pero intentamos hacerlo lo más breve y claro posible. Redujimos la cantidad de pasos del usuario desde el inicio de la aplicación hasta la visualización del contenido. Un mes y medio fue suficiente para realizar un proyecto adecuado. En una semana y media llegamos al sitio. Era más fácil trabajar allí porque todo el control del proyecto estaba en manos de los organizadores, no había necesidad de coordinarse con otros comités. En Kazán era más sencillo y fácil trabajar y era bastante normal que hubiera menos tiempo.
Dmitry: ¿Pero decidiste dejar el enfoque de la sincronización tal como estaba, basado en el sonido?
Andrei: Sí, lo dejamos por sonido. Funcionó bien. Como dicen, si funciona, no lo toques. Simplemente tomamos en cuenta los matices de la calidad de la pista de audio. Cuando hicieron la introducción, hubo un episodio de entrenamiento para que la gente lo probara antes de que comenzara el programa. Fue sorprendente que cuando en el momento de reproducir la pista en el estadio hay un aplauso tormentoso, “en vivo”, el sistema permite sincronizar bien con esta pista, pero si en ese momento los aplausos grabados se mezclan con la pista, entonces el La pista ya no se captura. Se tuvieron en cuenta estos matices y todo estuvo bastante bien sincronizado en términos de sonido.
PD: En la segunda parte del número hablamos sobre visualización de datos científicos, modelado de procesos en otros proyectos, desarrollo de juegos y el programa de maestría "" Publicaremos una continuación en el próximo artículo. Puedes escucharnos y apoyarnos aquí:
PPS Mientras tanto, en la versión inglesa de Habr: .
Fuente: habr.com