Interview de David Rousset sur babylon.js

Aujourd’hui nous allons parler babylon.js !

Pour ceux qui ne connaîtraient pas, c’est un moteur 3D écrit en JavaScript et basé sur WebGl.

Qui de mieux pour en parler que David Rousset, développeur et co-fondateur du framework.

(NB : Je me suis permis de mettre en gras certaines parties)

Bonjour David, peux-tu te présenter, nous décrire ton parcours ?

Bonjour ! Je travaille pour Microsoft depuis 15 ans où je suis actuellement ce que nous appelons un évangéliste technique. Je suis un fan du web, je passe donc le plus clair de mon temps en conférence (Paris Web, Kiwi Party, Paris JS & co), à écrire des articles sur le sujet et à prêcher la bonne parole des standards (et oui je travaille bien chez Microsoft ! ;)). Je m’occupe également de l’activité jeux vidéo dans la division DX de Microsoft France où j’accompagne les studios à venir sur nos plateformes Windows & Windows Phone. Du coup, babylon.js est la parfaite synthèse de 2 de mes passions principales : écrire un framework de jeux pour le Web !

D’où t’es venu l’idée de construire ton propre moteur et avec qui travailles-tu ?

L’idée est venu avec mon super pote David Catuhe. Il écrit des moteurs 3D depuis tout petit (Amiga, PC DirectX). Il pense 3D depuis qu’il est bébé. On avait envie de se faire plaisir en écrivant tous les 2 un moteur de jeux 3D open source basé sur WebGL tournant partout : IE11, Chrome, Firefox, Opera et toutes les plateformes mobiles : Windows Phone, Android, iOS & Firefox OS. On a donc commencé exclusivement sur notre temps libre, par passion. Pour ma part, je suis super chiant et exigeant sur 1 point principal : le moteur doit être simple à utiliser et pas uniquement réservé à une élite guru de la 3D. C’est vraiment notre philosophie. Nous sommes donc 2 développeurs principaux aujourd’hui dessus. Mais nous sommes aidés aussi par Michel Rousseau qui est notre artiste 3D et qui a réalisé la plupart de nos démos, Pierre Lagarde qui nous donne un coup de main de temps en temps sur certaines tâches serveurs. Pour finir, Etienne Margraff vient de rejoindre récemment l’équipe pour bosser sur le packaging dans Cordova et est en train d’écrire le support de textures procédurales. Sébastien Pertus bosse de son côté sur une solution de Leader Board basée sur node.js et hébergeable dans Azure.

Depuis quand le projet existe et avez-vous défini une roadmap pour la suite ?

Le projet existe depuis que nous savons que WebGL allait arriver dans IE11, donc depuis mai 2013 environ. Nous savions que c’était un tournant important pour le web et nous espérions qu’Apple suive le mouvement, ce qu’ils ont fait récemment. Notre roadmap est décrite ici : https://github.com/BabylonJS/Babylon.js/wiki/Roadmap. Notre priorité principale est le support de Web Audio, d’un Scene Optimizer (essayer d’optimiser les performances du moteur automatiquement en fonction du device) et un exportateur depuis Unity 3D. On s’intéresse aussi à des technologies très cool comme asm.js pour notre librairie mathématique.

babylon.js partage le même objectif que ThreeJS, à savoir abstraire la complexité de Webgl pour faciliter la vie des développeurs. En quoi ces frameworks sont-ils différents ?

Souvent les gens nous disent que babylon.js est plus simple à utiliser, ce qui était l’un de nos buts principaux. Par ailleurs, nous avons fait des choix d’architecture différents. Nous sommes très orientés « scène » dans un esprit jeux vidéo. Nous avons énormément travaillé sur les performances aux niveaux de nos shaders (ces petits bouts de code exécutés par le GPU) et d’un cache avancé des appels vers WebGL, ce que n’a pas aujourd’hui Three.js. Pour finir, nous offrons beaucoup de services « dans la boîte » comme un support offline via un provider IndexedDB, un support varié de caméras (gamepad, virtual joysticks, device orientation) et un moteur de collisions intégré. On permet également de viser tous les périphériques tactiles à travers une abstraction des 2 modèles d’évènements tactiles (touch & pointers events). Pour finir, nous avons 2 exportateurs 3DS Max et Blender très complets et avancés. On est particulièrement fiers de la version 3DS Max qui est peut-être l’un des plus avancée du marché. En conclusion, je dirais que Three.js est plus bas niveau et est plus un moteur 3D pur là où nous essayons de couvrir un maximum de besoins pour le développeur de jeux. Par contre, il jouit d’une énorme communauté et de nombreux plug-ins pour l’enrichir. Le privilège de l’âge ! 😉

Comparer à d’autres moteurs, babylon.js intègre un moteur physique, qu’elle fût la charge de travail dédiée à cette “feature” ?

L’intégration d’un moteur physique fut relativement rapide et simple. Nous avons décidé d’ouvrir cette partie via un système de plug-in dans babylon.js. Nous avons écrit le 1er plug-in pour intégrer le moteur open source cannon.js. La communauté a ensuite pris le relais pour écrire le plug-in d’intégration de oimo.js que nous nous trouvons d’ailleurs plus au point. Nous avons donc décidé de supporter par défaut oimo.js du coup. On est vraiment contents de l’implication de notre communauté et du résultat ! J’ai écrit un article récemment sur la partie physique : Understanding collisions & physics by building a cool WebGL Babylon.js demo with Oimo.js

La 3D sur le Web est surtout associée aux jeux vidéos, connais-tu d’autres usages ?

Oh oui ! Il y a beaucoup d’autres usages ! Visualisation de grosses volumétries de données, charting, cartographie 3D, catalogue en ligne 3D pour l’e-commerce, création de sa cuisine en ligne, modélisation avancée dans l’industrie aéronautique, etc. J’ai fait beaucoup de rendez-vous client grâce à babylon.js où tous ces domaines ont été abordés. Pour la cartographie 3D par exemple, ma démo préférée est celle réalisée par Dot Vision au-dessus de notre moteur : Démo Dot Vision Bing Maps 3D . Ils ont pris les données d’élévation de la planète via de l’open data de la Nasa, pris le système de tuiles de Bing Maps et construit un super algo au-dessus de notre moteur. L’idée est de suivre en temps réel des courses via des bracelets « IoT » ou de rejouer une course après coup. Allez voir leur démo, c’est bluffant.

Le développement de jeux vidéo et le développement Web sont très différents, penses-tu que ces deux univers puissent fusionner un jour ?

Ils doivent fusionner en fait si l’on veut que cela marche bien. J’en parle en partie dans cet article : The web: the next game frontier? Les développeurs de jeux vidéo ont une culture historique irremplaçable techniquement (s’adapter aux différents GPU et CPU, optimisations variées du moteur 3D) et sur le gameplay. Mais ils connaissent souvent très mal la culture web et en ont assez peur j’ai l’impression. De l’autre côté, nous avons une population web habituée depuis des années au responsive, à la délicate gestion du support multi-navigateurs, à l’accessibilité. Les 2 doivent absolument échanger pour construire une nouvelle expérience basée sur le meilleur des 2 mondes.

Avec l’activation de WebGl sur IOS et l’accès à de meilleures cartes graphiques pour le grand public, penses-tu que les moteurs et applications 3D vont gagner en popularité ?

J’en suis définitivement convaincu. J’en parle toujours dans le même article !  Le jour où Apple a annoncé le support de WebGL de manière propre dans iOS, j’ai sauté de joie ! C’était le dernier virage à entamer pour que WebGL devienne définitivement « mainstream » et envisageable en production. Je pense que 2015 sera une année importante pour l’arrivée de nombreux projets utilisant WebGL. Nous devrions par exemple voir les 1ers projets exportés depuis Unity 5. De notre côté, nos démos babylon.js, même importantes comme Hill Valley/Retour vers le futur, tournent entre 25 et 30 images/seconde (fps) sur mon Nokia 1520 et jusqu’à 2 fois plus vite sur le dernier iPhone 6 ! Nos smartphones sont désormais capables d’afficher des scènes complexes en 3D directement dans le navigateur. Cela ouvre des perspectives incroyables.

Selon moi, la pièce manquante à la 3D sur le Web aujourd’hui est un éditeur dédié aux contraintes Web ; ceci permettant de faciliter l’échange entre graphiste 3D et développeur. Quelques solutions émergent comme Blender4Web. Quelle est la position de babylon.js à ce sujet ?

Nous n’avons pas de velléités de nous lancer dans notre propre éditeur, c’est un travail bien trop gros et compliqué. Nous préférons rester concentrés sur notre moteur. Mais certaines personnes sont en train de se pencher dessus dans la communauté. Par ailleurs, notre stratégie est de plutôt se brancher sur des éditeurs déjà bien faits comme Blender, 3DS Max ou Unity. Pour finir, il existe des solutions très avancées comme celle de http://clara.io avec qui nous sommes actuellement en relation.

De nouveaux usages émergent en 3D avec la Kinect V2 ou l’OcculusRift DK2. Existe-t-il des outils au sein de babylon.js pour faciliter leur intégration ?

Nous avions intégré le support du DK1 via un driver Windows qui faisait passer le casque pour un accéléromètre. Cela permettait de toucher le navigateur via les Device Orientation API et évitait d’écrire un plug-in. Il faudra que nous passions un peu de temps à mettre à jour le driver en DK2. Mais entre-temps, des initiatives intéressantes comme WebVR sont arrivées et la communauté nous a proposé une extension babylon.js pour WebVR dans notre 1.14 : what’s new.md. Pour la Kinect, nous n’avons pas travaillé sur ce sujet. Certains se sont amusés à créer des modèles via Kinect Fusion (qui numérise en 3D un objet réel) pour l’injecter dans babylon.js : Sharing 3D Scans in WebGL using BabylonJS. Le Kinect SDK propose également une forme d’export JavaScript, on pourrait se brancher dessus. Mais jusqu’à aujourd’hui, personne ne nous a manifesté le besoin.

Merci David pour ces réponses, ceci nous permet d’en savoir plus sur les coulisses de babylon.js.

Pour ceux qui voudraient découvrir le framework, je vous conseille la lecture de cet article pour débuter.