3 min de lecture

Three.js ou Rust/WGPU pour des démos IA rapides

Three.jsRustWGPU

Three.js est généralement le choix le plus rapide pour une démo IA dans le navigateur, grâce aux scènes, matériaux et shaders déjà disponibles. Rust/WGPU offre davantage de contrôle sur le GPU, mais exige une infrastructure dédiée. Une estimation de 8 à 10 heures pour un prototype illustre bien ce compromis.

Three.js transforme plus vite une idée en scène fonctionnelle

Je ne compliquerais pas le départ : pour un prototype dans le navigateur, Three.js offre le chemin le plus court entre une idée et une scène fonctionnelle. Dans la discussion d'origine, un participant a clairement indiqué que Three.js avait suffi pour la démo, même si la bibliothèque d'assets était limitée. Un autre a estimé qu'une version plus aboutie dans un moteur de jeu demanderait 8 à 10 heures et plusieurs itérations, avec accès à une bibliothèque de shaders.

Sur le plan technique, c'est cohérent. La documentation de Three.js consacrée à ShaderMaterial décrit comment intégrer des shaders de sommets et de fragments personnalisés sans devoir construire un moteur de rendu complet autour d'eux. La scène, la caméra, les matériaux et l'infrastructure standard existent déjà ; l'essentiel du temps peut donc être consacré à l'éclairage, à la composition, aux effets procéduraux et au comportement de la caméra.

Rust/WGPU propose le compromis inverse : davantage de contrôle, mais davantage de travail. La documentation de wgpu et sa collection d'exemples montrent une gestion explicite des ressources GPU, des pipelines, de la synchronisation, des tâches de calcul et des surfaces HDR. C'est une base solide pour des mélanges inhabituels, de la géométrie générée par calcul ou une architecture de rendu sur mesure, mais les assets, les abstractions et les conventions du moteur doivent être conçus séparément.

Unity et Unreal se situent entre les deux : ils offrent des éditeurs matures et une chaîne de production prête à l'emploi sans imposer l'écriture d'un moteur, mais restent plus lourds pour une démo légère dans le navigateur. La date de la discussion n'est pas indiquée ; il faut donc la lire comme une analyse d'ingénierie au 27 septembre 2026, et non comme l'annonce d'une nouvelle technologie.

Un rendu original ne commence pas par le choix de l'API

La conclusion est simple : Three.js fait gagner du temps, tandis que Rust/WGPU achète du contrôle au prix du développement d'infrastructure. Pour un prototype web ponctuel, la seconde voie peut facilement devenir un travail sur le moteur plutôt qu'une exploration de l'idée visuelle.

Pour autant, WGPU ne suffit pas à éviter une image générique. Le caractère vient de la structure des shaders, de l'éclairage, de la variation des textures, de la caméra, de la postproduction et de la qualité des assets. Dans la démo WebGL présentée, la limite apparaissait déjà au niveau des assets, et non dans la capacité de Three.js à afficher la scène.

Aucun benchmark comparatif direct n'est disponible dans les sources, il serait donc excessif d'affirmer qu'une pile est systématiquement plus rapide qu'une autre. La vraie question est de savoir à quel moment les abstractions prêtes à l'emploi empêchent l'effet recherché. C'est ce seuil, bien plus que le nom d'une API, qui détermine si le résultat devient une image distinctive ou une nouvelle maquette soignée.

Nous avons déjà présenté Rust LocalGPT, un assistant local distribué dans un unique binaire et construit autour de Rust et d'une API HTTP. Son approche d'implémentation apporte un contexte utile pour comparer Rust/WGPU et Three.js dans le rendu de jeux basés sur l'IA.