3dverse

Avant même de commencer, laissez-moi me présenter rapidement. Je m’appelle Matéo, j’ai 19 ans, et je ne suis pas développeur. Pour être plus précis, j’ai déjà trifouillé le front-end de quelques sites web, mais seulement de manière occasionnelle, et n’ai absolument jamais fait de back-end. Autant dire que développer une application 3D ne me semblait clairement pas à ma portée il y a encore peu de temps. Pourtant, malgré mon flagrant manque de qualification, j’ai développé un configurateur de voiture 3D complet qui fonctionne entièrement sur un navigateur internet, et donc sur n’importe quel appareil, en moins d’une semaine.

Mais alors comment j’ai fait pour développer cette application web assez avancée ? Avant d’aborder comment j’ai fait, parlons d’abord du pourquoi je me suis lancé dans ce projet.

Pourquoi faire ça ?

Il y a un élément que je ne vous ai pas dit sur moi : je suis stagiaire chez 3dverse. Et chez 3dverse, vous le sentez venir, on fait de la 3D. Pour être plus précis, on ne fait pas n’importe quelle 3D, on fait de la 3D dans le cloud. Bon, au lieu de vous endormir avec de longues explications sur la technologie que développe 3dverse (d’autant que le sujet mérite un article à lui tout seul, ou même un livre ou deux tant c’est passionnant), je vais vous faire un rapide résumé. Si vous souhaitez en savoir plus, je vous invite fortement à lire l’article suivant : ARTICLE C’EST QUOI 3DVERSE. 3dverse développe un moteur 3D dans le cloud afin de pouvoir facilement créer des applications 3D dont tous les calculs sont déportés sur des serveurs distants. Vous le savez sans doute, les calculs 3D sont très lourds et donc en déportant cette charge de travail sur les GPU des serveurs de 3dverse on peut accéder à de la 3D d’excellente qualité sur n’importe quel appareil, peu importe sa puissance. Ca, déjà, c’est très très cool. Ca permet d’enfin pouvoir visualiser de gros modèles sur des smartphones, tablettes ou mêmes casques de réalité augmentée, et autant dire que ça a changé ma vie car quand je travaillais sur des projets ThreeJS je passais plus de temps sur Blender à décimer mes modèles 3D et à supprimer les faces qu’on ne voyait pas pour améliorer les performances du site qu’à avancer sur le code.

Mais les avantages du moteur de 3dverse ne s’arrêtent pas là : le vrai point fort est la facilité de développement. En effet, gérer une infrastructure cloud peut sembler être pour le moins… complexe (et pour avoir pas mal discuté avec les développeurs back-end de 3dverse, c’est même un véritable enfer) mais en passant par 3dverse on n’a pas à se soucier de tout ça. Toute l’infrastructure (serveurs, synchronisation, sécurité…) est gérée par la plateforme et la seule chose qu’on a à faire est d’appeler quelques fonctions via une API et un SDK pour créer et interagir avec un viewport 3D. C’est ainsi que, quand le projet de réaliser un configurateur de voiture en utilisant le moteur de 3dverse a été présenté en interne, j’ai fébrilement levé la main pour proposer d’essayer de développer une démo. Une poignée de main et deux cafés plus tard, je me retrouvais devant Visual Studio.

Lancement du projet

Cela faisait déjà 20 minutes que je fixais ma page HTML vide, mais rien ne venait. Par où commencer ? La réponse me vint d’un développeur de 3dverse, Houssem, qui m’envoya la documentation du SDK de 3dverse et se proposa même de m’aider. J’ai ainsi pu constater avec plaisir qu’il existait déjà plusieurs templates de code pour se connecter à l’API de 3dverse, ouvrir une session et afficher le rendu sur sa page web. Il ne m’a donc pas fallu beaucoup plus qu’un simple copier-coller pour voir un viewport 3D dans lequel je pouvais me déplacer apparaitre sur ma page. Et c’est à partir de là que j’ai compris toute la puissance du moteur de 3dverse, car ce viewport n’affichait pas qu’un simple espace 3D vide, comme ça pourrait être le cas en ThreeJS, il était directement relié à une scène 3D que n’importe qui pouvait rejoindre et modifier. Ainsi, pendant que je commençais à travailler l’interface de l’application (je rappelle que c’est la seule chose que je sais faire), Houssem ajoutait un modèle de voiture dans la scène, que je pouvais voir en temps réel sur mon application, sans même avoir besoin de recharger la page. Ce fut ainsi avec une grande satisfaction que je vis la scène prendre forme sous mes yeux tout en continuant d’ajouter des éléments d’interface. Lumières, environnement, effets de caméra, tout prenait vie devant moi. Houssem pouvait voir ma caméra se balader dans l’espace tandis que je voyais chaque modification qu’il faisait.

Je pense que je n’ai même pas besoin de préciser qu’aucun workflow classique de développement d’application 3D ne permet de reproduire ce qu’on était en train de faire. En travaillant à deux sans se marcher sur les pieds, le configurateur de voiture avançait à une vitesse folle ! C’est ainsi qu’en à peine une après-midi, la première partie de l’application et toute la mise en forme des modèles étaient terminées.

Suite du développement

Par la suite, Houssem ajouta quelques fonctions Javascript permettant de changer de modèle de voiture, modifier certaines parties, changer les couleurs, animer la voiture… Le code était vraiment simple, même pour moi, et utilisait simplement certaines fonctions du SDK de 3dverse. Je n’avais plus qu’à appeler les bonnes fonctions au bon moment pour que l’interface soit fonctionnelle. Houssem me laissa ensuite poursuivre le projet seul. A ce moment, je savais déjà exactement à quoi ressemblait l’application finale. Je m’étais pris au jeu et avais densifié le cahier des charges en voyant la vitesse à laquelle on avait avancés. Je souhaitais donc que la configuration de la voiture se fasse en trois temps : le choix du modèle, la personnalisation et la revue, où on pourrait modifier l’environnement de la scène pour voir la voiture sous un nouvel oeil. Le problème était qu’Houssem ne m’avait pas envoyé de fonction permettant de changer l’environnement. J’allais donc devoir m’attaquer au Javascript et écrire cette fonction moi-même.

Quelques centaines de lignes de codes sans accroc plus tard, si ce n’est que que j’ai développé une forte animosité envers la personne qui a décrété qu’une application devait fonctionner sur tous les formats d’écran, il ne me manquait plus que la possibilité de modifier l’environnement dans la dernière partie de l’application pour finir. Je pris donc une grande inspiration, relança ma playlist pour la troisième fois et cliqua sur ce tant redouté “App.js”. Je me suis rapidement rendu compte que je me prenais la tête pour rien. Je ne veux pas dire par là que je savais instantanément quoi écrire, possédé par le développeur originel, mais dès que j’ai compris la logique derrière chaque objet composant une scène, c’est allé très vite. En fait, chaque élément d’une scène est ce qu’on appelle une entité. Cela peut être un modèle, une lumière ou même un environnement ou une caméra. Chaque entité a plusieurs components, qui viennent lui affecter certaines propriétés. On retrouve ainsi sur chaque entité un component “Transform” qui indique sa position, son orientation et sa taille, mais on peut aussi avoir des components plus spécifiques comme un “Environment”, qui permet de sélectionner des images HDR pour ajouter un environnement à la scène. Je précise que toutes ces informations sur les components que possèdent une entité précise sont facilement obtenable via un éditeur de scène et qu’Houssem utilisait au début du projet. Une fois que j’ai compris ça, tout était clair : pour modifier la cubemap, il me suffisait de changer les propriétés du component “Environment” de l’entité “Env” de ma scène, qui représente la skybox.

Chaque entité dans 3dverse a un identifiant unique appelé UUID, il fallait donc que je change l’UUID de la cubemap actuelle par l’UUID de la cubemap que je souhaitais et le tour était joué. Je mets rapidement tout ça sous forme de code en utilisant les fonctions du SDK indiquées dans la documentation, et ça marche du premier coup (j’avoue que j’étais assez fier). C’était même tellement simple que j’ai décidé d’ajouter quelques fonctions supplémentaires, comme la possibilité de modifier l’éclairage ou d’afficher certains éléments de la scène.

Un petit coup de polish pour finir, je push tout sur Github, et c’était fini. Moins de 7 jours s’étaient écoulés et le configurateur de voiture était entièrement fonctionnel, sur n’importe quel appareil.

A votre tour

Vous avez sans doute compris le message peu subtil que je m’efforce de vous faire passer : développer des applications 3D avec 3dverse n’est pas très dur. Le mot le plus approprié pour désigner ce moteur serait de dire qu’il est accessible. Il est accessible pour les utilisateurs des applications développées avec, qui n’ont plus de problèmes de performance, et accessible pour les développeurs qui économisent un temps de production considérable grâce à une interface de développement adaptée et la collaboration en temps réel. En bref, c’est positif pour tout le monde.

3dverse développe d’ailleurs ses propres outils basés sur le moteur, dont le plus notable est 3dverse Collaborate, une plateforme permettant de partager et réviser des modèles 3D en équipe en tirant parti des bénéfices du cloud. Je pense que c’est une excellente entrée en matière si vous souhaitez avoir un avant-goût de l’expérience que propose le moteur de 3dverse, et il a été conçu pour être particulièrement simple d’utilisation.

Pour conclure, développer une web app 3D me semblait inaccessible il y a encore peu de temps, et si moi j’ai réussi c’est la preuve que le développement 3D n’est plus réservé à une élite de développeurs surdoués mais est désormais à la portée de tous. Donc si un projet d’application 3D complètement fou trotte dans votre tête depuis des mois, sachez que vous n’êtes qu’à un clic de le concrétiser : Lancez-vous!