Jumeaux numériques

Un jumeau numérique ne rentre pas dans un casque

Une maquette industrielle complète pèse des millions de polygones et s'appuie sur une machine de calcul sérieuse. Un casque autonome, lui, est un téléphone posé sur la tête. Entre les deux, on choisit d'habitude entre deux renoncements : alléger le modèle jusqu'à ce qu'il passe et perdre en route le détail qui justifiait le jumeau, ou streamer l'image du casque depuis la machine, et découvrir que le moindre retard du réseau se paie en inconfort.

Ce second point mérite qu'on s'y arrête, parce qu'il n'est pas une question de puissance. Quand le flux vidéo est la vue du casque, chaque rotation de tête doit faire l'aller-retour jusqu'au serveur avant que l'image ne suive. Le monde traîne derrière le regard, et l'oreille interne n'aime pas ça du tout.

Le parti pris de L3DS : streamer un écran, pas un point de vue

L3DS ne diffuse pas ce que voit l'utilisateur. Il diffuse un grand écran stéréoscopique posé dans l'espace, qui pivote pour rester face à lui. L'utilisateur ne regarde pas à travers le flux : il regarde un objet, dans une scène que son casque continue d'afficher tout seul.

Le déplacement de ce choix est simple et il change tout. La rotation de tête reste traitée localement, par le compositeur du casque, à sa cadence le flux n'en porte plus la responsabilité. Un retard sur le réseau se voit alors sur le contenu de l'écran, là où l'œil le tolère, et non sur la stabilité du monde, là où il ne la tolère pas. On accepte une latence qui rendrait une vue directe inutilisable.

Ce qu'il y a dessous

• Un protocole binaire, court et versionné, décrit dans un seul fichier de référence dont sont générés les deux côtés, C# pour Unity, Python pour Blender. Une évolution du format ne peut pas désynchroniser les implémentations.
• WebRTC pour le transport. La pose de la caméra part à ~60 Hz sur un canal non fiable : une position perdue vaut mieux qu'une position en retard.
• Une seule image pour les deux yeux, l'œil gauche dans la moitié gauche, redécoupée à l'affichage par le shader, un flux plutôt que deux à synchroniser.
• Une qualité qui suit le mouvement. Le client mesure ses vitesses linéaire et angulaire et les joint à chaque envoi de pose ; le serveur décide seul d'envoyer une image haute qualité quand le regard se pose. On dépense les bits quand ils se voient.
• Deux modes. VR pour l'immersion, et Portal en passthrough, l'écran devient une fenêtre ouverte dans la pièce réelle, avec fond transparent, à hauteur réglable par rapport au sol.

Entre quels outils

Le serveur, celui qui détient la scène lourde et la rend, est une application Unity ou un add-on Blender. Le client est une application Unity sur casque autonome, ou un navigateur compatible WebXR. Autrement dit : la scène reste là où elle a été conçue, dans l'outil où elle vit, et c'est la vue qui voyage.

Un protocole n'a de valeur que s'il est ouvert

Nous voulons publier L3DS en open source. Ce n'est pas un geste de communication : c'est la seule issue cohérente avec ce qu'est cette brique. Un protocole d'échange qui reste fermé n'est pas un protocole, c'est un format privé, il ne vaut que ce que vaut le nombre de logiciels qui le parlent, et personne n'écrit un connecteur pour une spécification qu'il ne peut pas lire.

Le travail a d'ailleurs été mené dans ce sens depuis le début. Le format binaire tient dans un fichier de référence unique, lisible, dont les implémentations Unity et Blender sont générées : c'est exactement la forme qu'on donne à une spécification destinée à être reprise par d'autres, pas à un code interne. Un troisième moteur, un quatrième outil de création se branchent en écrivant leur propre lecture de ce fichier.

C'est la même conviction qui nous fait travailler sur OpenUSD : les formats ouverts sont ce qui empêche une maquette 3D de devenir prisonnière de l'outil qui l'a produite.