18/12/2018: Une bibliothèque de modèles 3D en code

A-Frame inspector

Le WebVR et WebXR ont été présentés sur ce blog déjà en détail, mais c'est en travaillant sur des expériences concrêtes que j'ai eu l'idée de définir deux pistes pour améliorer le "produit" de la réalité mixte sur le web, en attendant que le language et la technologie soit plus mature.

L'interface de création WebXR

- La première idée est une interface qui permette de gagner du temps dans la conception des espaces VR/XR. Un "wysiwig" basé sur l'inspecteur AFrame que l'on peut obtenir sur n'importe quelle expérience VR en appuyant sur ctr+alt+i.

Il suffirait en effet de permettre à cette interface de générer du code en direct sur la page, ce qui est bien sûr impossible en l'état, le navigeur n'ayant aucune prise sur l'hébergement de l'expérience. Une adaptation serait donc la bienvenue, avec des simplifications plus "user friendly". C'est l'idée de qwazaam.com

Note: Il est toutefois possible d'exporter le code obtenu en html ou de copier la scène au clipboard (cache). cela permet ainsi de le transvaser facilement sur la page en cours d'édition. Mais l'utilisateur lambda lui, devra avoir un outil qui fasse cette étape également.

Il y a des applications spécifiques déjà destinées à créer des espaces virtuels en "3 clics" depuis son smartphone dans l'immobilier. Leur simplicité tient dans le fait que ces applications ne gèrent que quelques aspects basiques de l'expérience: Assemblage d'une photos 3d et quelques éléments de liens (flèches) qui ne sont pas personnalisables. Mais quid d'une interface permettant de créer n'importe quelle expérience VR/XR et générer le code ou intégrer des éléments externes (photos, vidéos, modèles 3d, textes...) avec une vue en 3d ? L'idée d'une telle interface suit son cours. Un exemple récent: XR.plus par l'agence Franco-Polonaise Lune.xyz.

banque de données 3d en code

-la seconde idée est celle d'une alternative à l'importation de modèles 3D externes, venant de Unity, 3DsMax, Blender, Maya... pour ne citer que ceux-ci. Il y a souvent des problème de liaison entre les textures et modèles, voire le modèle n'apparait pas sur des expériences WebVR/XR, limité par ailleurs aux modèles compatibles .gtlf ou .obj.

Cette alternative est la création de modèles 3d en code... Chercher et tester un modèle 3d pour une expérience prends du temps. Enormément en fait. Il est parfois plus rapide de créér le modèle que l'on souhaite en 3d en combinant des formes simples et une texture avec quelques effets au besoin. Touefois il reste des écueils à cette technique:

Créér les volumes 3d puis les assembler prends du temps (et heureusement l'inspecteur est là pour donne des coordonnées fiables !) "grouper" des groupes d'objets polyformes reste relativement complexe.
Ex. une table basique en code 3d nécéssite: Un rectangle orientés à 90° vertical pour l'un (dossier) et quatre cylindres (pieds) avec une texture. En code cela donne: <a-scene> <!--Piece principale--> <!--Table--> <a-box position="-1.5 0.76 4" rotation="0 0 0" scale="1 0.02 0.8" static-body material="src: #armoire"></a-box> <!--Pieds--> <a-cylinder position="-1.92 0.33 3.68" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> <a-cylinder position="-1.92 0.33 4.3" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> <a-cylinder position="-1.1 0.33 3.68" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> <a-cylinder position="-1.1 0.33 4.3" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> On peut toutefois créér un groupe avec <a-entity> et lui affecter une échelle et une position, une rotation, ainsi que la plupart des autres paramètres accessibles aux objets. Ce qui donne en code: <a-entity position="0 0 0"> <a-box position="-1.5 0.76 4" scale="1 0.02 1" static-body material="src: #armoire"></a-box> <!--Pieds--> <a-cylinder position="-1.92 0.33 3.68" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> <a-cylinder position="-1.92 0.33 4.3" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> <a-cylinder position="-1.1 0.33 3.68" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> <a-cylinder position="-1.1 0.33 4.3" radius="0.02" height="0.8" scale="1 1 1" static-body material="src: #armoire"></a-cylinder> </a-entity>

Maintenant qu'en est-il des groupes de groupes. Ex. Je place des objets séparés sur ma table, plus une chaise, et je souhaite bouger l'ensemble à l'autre bout de la pièce... cela veut dire que je vais devoir faire fonctionner des sous-groupes ensemble et donc emboiter des "entities" sur plusieurs niveaux.

Donc l'idée reste valide. On peut imaginer intégrer un bout de code qui sera l'objet 3D avec ses variables de lumière, textures, et images dans un dossier séparé. Le principal avantage - textures à part - c'est la vitesse d’exécution, le code directement dans la page étant nettement moins lourd que le chargement d'un modèle compilé;

L'implémentation cependant est dans ce cas tout sauf "user-friendly" a moins d'avoir un Wysiwig qui puisse comprendre et redistribuer les code fournis dans le bon ordre sur la page finale. Dans tous les cas, un test de performances s'impose !

L'enjeu ? Des expériences XR plus fluides (réalité mixte et augmentée), basée par exemple sur des marqueurs pour des applications print.