Podcast « ITMO Research_ » : comment aborder la synchronisation du contenu AR avec un spectacle à l'échelle d'un stade entier

Ceci est la première partie de la transcription textuelle de la deuxième interview de notre programme (Podcasts Apple, Yandex.Music). Invité du problème - Andreï Karsakov (kapc3d), Ph.D., chercheur principal au Centre National de Recherches Cognitives, professeur agrégé à la Faculté des Transformations Numériques.

Depuis 2012, Andrey travaille dans le groupe de recherche Visualisation et Infographie. Engagé dans de grands projets appliqués au niveau national et international. Dans cette partie de la conversation, nous parlons de son expérience en matière de support AR pour les événements publics.

Podcast « ITMO Research_ » : comment aborder la synchronisation du contenu AR avec un spectacle à l'échelle d'un stade entier
photo Ceci est l'ingénierie RAEng (Unsplash.com)

Contexte et objectifs du projet

Code temporel (par version audio) — 00h41

Dmitri Kabanov: Je voudrais commencer par le projet des Jeux européens. Il est multi-composants, plusieurs équipes ont participé à la préparation, et fournir une réalité augmentée à des milliers de spectateurs directement lors d'un événement au stade est une tâche assez sérieuse. En ce qui concerne votre implication, était-ce d’abord le logiciel ?

kapc3d: Oui, nous avons fait la partie programmation et assuré le support pendant le spectacle. Il fallait tout suivre, surveiller et lancer en temps réel, et aussi travailler avec le groupe de télévision. Si l'on considère ce projet dans son ensemble, on peut alors parler des cérémonies d'ouverture et de clôture. Jeux européens à Minsk, ainsi que sur la cérémonie d'ouverture du championnat Compétences mondiales à Kazan. C'était le même plan de travail, mais des événements différents. Il y avait un intervalle de deux mois entre eux. Nous avons préparé le projet avec les gars de l'entreprise Sechenov.com.

Nous les avons rencontrés par hasard Fête des sciences, qui a eu lieu à l’automne 2018. Nos étudiants en master ont présenté leur projet de cours sur le thème de la VR. Les gars sont venus vers nous et nous ont demandé ce que nous faisions dans notre laboratoire. Cela ressemblait à ceci :

— Vous travaillez avec la VR, mais pouvez-vous travailler avec la réalité augmentée ?

- Eh bien, en quelque sorte, oui.

- Il existe une telle tâche, avec de telles notes introductives. Pouvez-vous le faire?

Ils ont un peu gratté leurs navets, cela ne semble rien d'irréaliste :

- Essayons d'abord de tout étudier, puis trouvons une solution.

Dmitry: Offrent-ils uniquement un soutien médiatique ?

Andrew: Ils forment un stack complet. Du point de vue de la gestion et de l'organisation, ils sont entièrement impliqués dans la mise en scène, la mise en scène, le choix des décors, la logistique et autres supports techniques. Mais ils voulaient faire quelque chose de spécial pour les Jeux Européens. Ces effets spéciaux, comme la réalité mixte, sont destinés à la télévision depuis assez longtemps, mais ils ne sont pas les plus économiques en termes de mise en œuvre technique. Par conséquent, les gars ont cherché des options alternatives.

Dmitry: Discutons du problème plus en détail. En quoi cela consistait-il ?

Andrew: Il y a un événement. Cela dure une heure et demie. Nous devons nous assurer que le public qui le regarde en direct et ceux assis dans le stade puissent voir les effets de réalité augmentée en parfaite synchronisation avec le spectacle en direct en termes d'heure et de lieu sur le site.

Il y avait un certain nombre de limitations techniques. Il était impossible de synchroniser l'heure via Internet, car on craignait une charge excessive du réseau avec des tribunes pleines et la perspective de voir des chefs d'État assister à l'événement, ce qui pourrait brouiller les réseaux mobiles.

Andreï Karsakov, photo de matériel de l'Université ITMO
Podcast « ITMO Research_ » : comment aborder la synchronisation du contenu AR avec un spectacle à l'échelle d'un stade entierNous avions deux éléments clés dans ce projet : l'expérience personnelle que les gens peuvent vivre grâce aux appareils mobiles, et ce qui se retrouve dans la diffusion télévisée et les écrans d'information dans le stade lui-même.

Si soudainement une personne regarde des épisodes de réalité augmentée via un appareil mobile et apparaît en même temps sur l'écran, elle devrait voir la même image.

Nous avions besoin de deux systèmes pratiquement différents pour être complètement synchronisés dans le temps. Mais la particularité de tels spectacles est qu'il s'agit d'événements complexes dans lesquels un grand nombre de services techniques sont impliqués et toutes les opérations sont effectuées selon des codes temporels. Le time code est un moment précis dans le temps où quelque chose commence : la lumière, le son, les gens qui partent, les pétales de la scène qui s'ouvrent, etc. Il a fallu s'adapter à ce système pour que tout démarre au bon moment. Une autre particularité était que les scènes et les épisodes en réalité augmentée étaient liés au scénario.

Dmitry: Mais avez-vous décidé d'abandonner l'utilisation des codes temporels en raison des risques élevés de force majeure, ou avez-vous initialement calculé certaines caractéristiques de puissance et réalisé que la charge sur l'ensemble du système serait assez élevée ?

Andrew: Si vous créez un service de synchronisation pour un tel public, ce n'est pas très difficile. Dans tous les cas, les demandes n’échoueront pas du jour au lendemain. Oui, la charge est élevée, mais ce n’est pas une urgence. La question est de savoir si cela vaut la peine d'y consacrer des ressources et du temps si le réseau s'éteint soudainement. Nous n'étions pas sûrs que cela n'arriverait pas. Au final, tout a fonctionné, avec des interruptions dues à la charge, mais ça a fonctionné, et nous avons synchronisé selon le time code selon un schéma différent. C'était l'un des défis mondiaux.

Difficultés de mise en œuvre d'un point de vue UX

Code temporel (par version audio) — 10h42

Andrew: Nous avons également dû tenir compte du fait que le stade n'est pas une salle de concert classique et synchroniser les systèmes dans tout l'espace pour les appareils mobiles. Alors, il y a quelque temps, je suis devenu viral histoire de réalité augmentée aux concerts d'Eminem, puis il y a eu un cas avec Loboda.

photo Au revoir Robert (Unsplash.com)
Podcast « ITMO Research_ » : comment aborder la synchronisation du contenu AR avec un spectacle à l'échelle d'un stade entierMais c'est toujours une expérience devant vous - toute la foule se tient devant la scène, la synchronisation est assez simple. Dans le cas d'un stade, vous devez comprendre de quel côté du cercle vous vous trouvez, la position relative, afin que le stade s'intègre dans l'espace qui existe dans l'environnement virtuel. C’était un défi aigre. Ils ont essayé de le résoudre de différentes manières, et le résultat a été un cas proche de celui mis en œuvre par Loboda, mais pas à tous égards.

Nous laissons l'utilisateur décider où il se trouve. Nous avons fait un marquage pour le stade, où les gens choisissaient un secteur, une rangée, une place. Tout cela en quatre « clics ». Ensuite, nous devions déterminer la direction vers la scène. Pour ce faire, nous avons montré une silhouette de ce à quoi devrait ressembler la scène d'un point de vue personnalisé. Il l'a combiné, a tapoté et c'est tout - la scène s'est assise. Nous avons essayé de simplifier ce processus autant que possible. Pourtant, 90 % des téléspectateurs qui ont voulu regarder l’émission ne sont pas ceux qui ont l’habitude de communiquer avec la réalité augmentée.

Dmitry: Y a-t-il eu une candidature distincte pour ce projet ?

Andrew: Oui, une application pour iOS et Android, que nous avons poussée vers le store. Il y a eu une campagne promotionnelle distincte pour cela. Il a été précédemment décrit en détail comment télécharger, etc.

Dmitry: Vous devez comprendre qu'il n'y a pas de place pour une personne pour tester physiquement et apprendre à utiliser une telle application. Par conséquent, la tâche « d’éduquer » le public est devenue plus compliquée.

Andrew: Oui oui. Avec l'UX, nous avons rencontré beaucoup de difficultés, car l'utilisateur veut vivre l'expérience en trois clics : téléchargé, installé, lancé - cela a fonctionné. Beaucoup de gens sont trop paresseux pour suivre des tutoriels complexes, lire des tutoriels, etc. Et nous n’avons pas cherché à tout expliquer au maximum à l’utilisateur dans le tutoriel : ici une fenêtre va s’ouvrir, ici l’accès à la caméra, sinon ça ne marchera pas, et ainsi de suite. Peu importe le nombre d’explications que vous écrivez, peu importe le niveau de détail que vous mâchez, peu importe les gifs que vous insérez, les gens ne les lisent pas.

À Minsk, nous avons collecté un grand nombre de retours sur cette partie et avons déjà beaucoup modifié l'application à Kazan. Nous y avons mis non seulement les phonogrammes et les codes temporels qui correspondent à un épisode spécifique de réalité augmentée, mais nous avons pris tous les phonogrammes et codes temporels dans leur intégralité. Ainsi, l'application a entendu ce qui se passait au moment du lancement et - si une personne se connectait au mauvais moment - elle a donné l'information : "Camarade, je suis désolé, votre épisode AR sera dans 15 minutes."

Un peu sur l'architecture et l'approche de la synchronisation

Code temporel (par version audio) — 16h37

Dmitry: Avez-vous décidé de synchroniser par le son ?

Andrew: Oui, c'est arrivé par accident. Nous avons examiné les options et sommes tombés sur une entreprise Cifrasoft d'Ijevsk. Ils constituent un SDK pas particulièrement sophistiqué, mais fonctionnel, qui vous permet de synchroniser le son avec le timing. Le système a été positionné pour fonctionner avec la télévision, lorsque vous pouvez afficher quelque chose dans une application basé sur le son d'une publicité conditionnelle ou offrir une expérience interactive basée sur la piste d'un film.

Dmitry: Mais c’est une chose – vous êtes assis dans votre salon, et une autre chose – un stade avec des milliers de personnes. Comment les choses se sont-elles déroulées pour vous en termes de qualité de l'enregistrement sonore et de sa reconnaissance ultérieure ?

Andrew: Il y avait beaucoup de craintes et de doutes, mais dans la plupart des cas, tout était bien reconnu. Ils construisent des signatures sur la piste audio avec leurs algorithmes astucieux – le résultat pèse moins que le fichier audio original. Lorsque le microphone écoute le son environnant, il essaie de trouver ces caractéristiques et de reconnaître la piste en fonction de celles-ci. Dans de bonnes conditions, la précision de synchronisation est de 0,1 à 0,2 seconde. C'était plus que suffisant. Dans de mauvaises conditions, l'écart pouvait atteindre 0,5 seconde.

Cela dépend beaucoup de l'appareil. Nous avons travaillé avec un large parc d'appareils. Pour les iPhones, il n’existe que 10 modèles. Ils ont bien fonctionné en termes de qualité et d’autres fonctionnalités. Mais avec les androïdes, le zoo est comme ma mère. Il s'est avéré que la synchronisation du son ne fonctionnait pas partout. Il y avait des cas où il était impossible d'entendre différentes pistes sur différents appareils en raison de certaines particularités. Quelque part les basses fréquences disparaissent, quelque part les hautes fréquences commencent à siffler. Mais si l'appareil avait un normaliseur sur le microphone, la synchronisation fonctionnait toujours.

Dmitry: Parlez-nous de l'architecture : qu'est-ce qui a été utilisé dans le projet ?

Andrew: Nous avons réalisé l'application dans Unity - l'option la plus simple en termes de multiplateforme et de travail avec des graphiques. Fondation AR utilisée. Nous avons immédiatement dit que nous ne voulions pas compliquer le système, nous nous sommes donc limités à une flotte d'appareils prenant en charge ARKit et ARCore afin d'avoir le temps de tout tester. Nous avons créé un plugin pour le SDK DigitalSoft, il est sur notre GitHub. Nous avons créé un système de gestion de contenu afin que les scripts s'exécutent selon la chronologie.

Nous avons un peu bricolé le système de particules, car l'utilisateur peut entrer à tout moment dans un épisode particulier, et nous avons besoin qu'il voie tout à partir du moment où il s'est synchronisé. Nous avons bricolé un système qui permet aux scénarios de se dérouler clairement dans le temps, afin que l'expérience XNUMXD puisse défiler d'avant en arrière, comme dans un film. Même si cela fonctionne de manière originale avec les animations classiques, nous avons dû bricoler les systèmes de particules. À un moment donné, ils commencent à frayer, et si vous vous trouvez quelque part avant le point d'apparition, ils ne sont pas encore nés, même s'il semble qu'ils devraient l'être. Mais ce problème est en réalité assez simple à résoudre.

Pour la partie mobile, l’architecture est assez simple. Pour la télédiffusion, tout est plus compliqué. Nous avions des restrictions matérielles. Le client a posé une condition : « Ici, nous avons tel ou tel parc matériel, en gros, tout doit fonctionner dessus. Nous nous sommes immédiatement concentrés sur le fait que nous travaillerions avec des cartes de capture vidéo relativement économiques. Mais le budget ne veut pas dire qu'ils sont mauvais.

Il y avait des restrictions sur le matériel, sur les cartes de capture vidéo et sur les conditions de travail – comment nous devrions recevoir l'image. Cartes de capture - Blackmagic Design, fonctionnant selon le schéma de saisie interne - c'est à ce moment-là qu'une image vidéo vous parvient de la caméra. La carte possède sa propre puce de traitement, où un cadre est également inséré, qui doit être superposé à celui entrant. La carte les mélange - nous n'y touchons rien d'autre et n'affectons pas l'image de la caméra vidéo. Elle crache le résultat à la salle de contrôle via la sortie vidéo. C'est une bonne méthode pour superposer des titres et d'autres éléments similaires, mais elle n'est pas très adaptée aux effets de réalité mixte car il existe de nombreuses restrictions sur le pipeline de rendu.

Dmitry: En termes de calcul en temps réel, de liaison d'objets ou autre chose ?

Andrew: En termes de qualité et d’obtention des effets souhaités. Parce que nous ne savons pas sur quoi nous mettons l’image par-dessus. Nous envoyons simplement des informations sur la couleur et la transparence en plus du flux d'origine. Certains effets tels que les réfractions, la transparence correcte et les ombres supplémentaires ne peuvent pas être obtenus avec ce schéma. Pour ce faire, vous devez tout restituer ensemble. Par exemple, il n'existe aucun moyen de créer l'effet de distorsion de l'air provoqué par un incendie ou de l'asphalte chaud. Il en va de même pour le transfert de l'effet de transparence tenant compte de l'indice de réfraction. Nous avons initialement créé du contenu basé sur ces restrictions et essayé d'utiliser les effets appropriés.

Voir ce post sur Instagram

Clôture des IIes Jeux Européens à Minsk.

Une publication partagée par Alena Lanskaïa (@alyonalanskaya) le 30 juin 2019 à 3h19 PDT

Dmitry: Aviez-vous déjà votre propre contenu dans le premier projet des Jeux Européens ?

Andrew: Non, la principale étape du développement du contenu a été réalisée par les gars de Sechenov.com. Leurs graphistes ont dessiné le contenu de base avec des animations et d'autres choses. Et nous avons tout intégré dans le moteur, ajouté des effets supplémentaires, l'avons adapté pour que tout fonctionne correctement.

Si nous parlons de pipeline, alors pour la diffusion télévisée, nous avons tout assemblé sur Unreal Engine 4. Par coïncidence, c'est à ce moment-là qu'ils ont commencé à renforcer leurs outils pour la réalité mixte. Il s'est avéré que tout n'est pas si simple. Même maintenant, tous les outils sont bruts ; nous avons dû finir beaucoup de choses à la main. À Minsk, nous avons travaillé sur une version personnalisée du moteur, c'est-à-dire que nous avons réécrit certaines choses à l'intérieur du moteur afin que, par exemple, nous puissions dessiner des ombres sur des objets réels. Sur la version du moteur en vigueur à l'époque, il n'existait aucune fonctionnalité permettant de le faire à l'aide d'outils standards. Pour cette raison, nos gars ont réalisé leur propre assemblage sur mesure pour fournir tout ce qui était vitalement nécessaire.

Autres nuances et adaptation à WorldSkills à Kazan

Code temporel (par version audio) — 31h37

Dmitry: Mais tout cela dans un laps de temps assez court ?

Andrew: Les délais étaient serrés Projet Kazan, selon Minsk - normal. Environ six mois pour le développement, mais en tenant compte du fait que six personnes étaient impliquées. Parallèlement, nous réalisons la partie mobile et développons des outils pour la production télévisuelle. Il n'y avait pas seulement une sortie d'image. Par exemple, un système de suivi avec optique, pour cela vous deviez créer vos propres outils.

Dmitry: Y a-t-il eu une adaptation d’un projet à l’autre ? En un mois et demi, il a fallu profiter des évolutions et transférer le projet avec du nouveau contenu sur un nouveau site ?

Andrew: Oui, c'était pendant un mois et demi. Nous avions prévu deux semaines de vacances pour toute l'équipe après le projet de Minsk. Mais immédiatement après la fermeture, les gars de Sechenov.com arrivent et disent : "Eh bien, faisons Kazan alors." Nous avons quand même réussi à nous reposer un peu, mais sommes passés assez rapidement à ce projet. Nous avons réalisé quelques travaux techniques. La plupart du temps a été consacré au contenu, car pour WorldSkills, nous l'avons entièrement réalisé, nous l'avons simplement coordonné avec l'équipe de production. Il n’y avait qu’un scénario de leur part. Mais c'était plus simple : aucune itération supplémentaire n'était nécessaire. Lorsque vous créez vous-même du contenu, vous voyez immédiatement comment il fonctionne dans le moteur et vous pouvez rapidement le modifier et le coordonner.


Concernant la partie mobile, nous avons pris en compte toutes les subtilités que nous avions à Minsk. Nous avons créé une nouvelle conception d'application, repensé un peu l'architecture, ajouté des didacticiels, mais avons essayé de la rendre aussi courte et claire que possible. Nous avons réduit le nombre d'étapes de l'utilisateur depuis le lancement de l'application jusqu'à l'affichage du contenu. Un mois et demi a suffi pour réaliser un projet adéquat. En une semaine et demie nous sommes arrivés sur le site. Il était plus facile de travailler là-bas car tout le contrôle du projet était entre les mains des organisateurs ; il n'était pas nécessaire de se coordonner avec d'autres comités. Il était plus simple et plus facile de travailler à Kazan et il était tout à fait normal qu'il y ait moins de temps.

Dmitry: Mais avez-vous décidé de laisser l’approche de synchronisation telle qu’elle était, basée sur le son ?

Andrew: Oui, nous l'avons laissé par le son. Cela a bien fonctionné. Comme on dit, si ça marche, n'y touchez pas. Nous avons simplement pris en compte les nuances de la qualité de la piste audio. Lorsqu'ils ont fait l'intro, il y avait un épisode de formation que les gens pouvaient essayer avant le début de la série. Il était surprenant que lorsqu'au moment de jouer la piste dans le stade il y ait des applaudissements nourris, "en direct", le système permette de bien se synchroniser avec cette piste, mais si à ce moment les applaudissements enregistrés se mélangent à la piste, alors le la trace n'est plus captée. De telles nuances ont été prises en compte et tout a été plutôt bien synchronisé en termes de son.

PS Dans la deuxième partie du numéro, nous parlons de visualisation de données scientifiques, de modélisation de processus dans d'autres projets, de développement de jeux et du programme de master "Technologie de développement de jeux informatiques" Nous publierons une suite dans le prochain article. Vous pouvez nous écouter et nous soutenir ici :

PPS Pendant ce temps, sur la version anglaise de Habr : un regard plus attentif sur l'Université ITMO.

Source: habr.com

Ajouter un commentaire