La 3D, là où le pipeline casse encore : TRELLIS.2 et le pari O-Voxel

L'asset dont personne ne parle

La génération d'images prend la lumière, la génération de vidéos fournit les bandes de démo, et la 3D reste dans son coin, responsable du fait qu'il y a encore un humain dans le pipeline. Si vous avez déjà essayé de mettre un objet généré dans un moteur de jeu, un configurateur produit ou un plan VFX, vous connaissez le mode de défaillance : l'image est propre, le fichier est inutilisable.

TRELLIS.2, le modèle image-vers-3D de 4B paramètres de Microsoft Research, attaque le problème au niveau de la représentation, pas du rendu. Il traîne sur la page trending de GitHub ce mois-ci, autour de 11,000 étoiles, et s'il revient sans cesse, c'est parce qu'il fait partie des rares générateurs 3D dont la sortie est réellement acceptée par un outil en aval.

Ce que change O-Voxel

La plupart des systèmes image-vers-3D prédisent un champ implicite, une fonction de distance signée ou une grille d'occupation, puis en extraient une surface avec marching cubes. L'approche est élégante et a une faiblesse précise : elle suppose un objet fermé, étanche. Un vêtement dont on voit l'intérieur, des feuilles, des coques fines, une géométrie qui se touche elle-même, tout ce qui contient une cavité fermée se retrouve moyenné ou perdu à l'extraction.

TRELLIS.2 remplace le champ par une structure de voxels creux appelée O-Voxel, décrite comme field-free. Au lieu de demander à quelle distance se trouve la surface, il représente la structure directement, ce qui permet de conserver les surfaces ouvertes, la géométrie non-manifold et les volumes internes fermés sans étape de conversion destructive.

Ça ressemble à un détail de recherche. C'est la différence entre une veste qui s'affiche correctement et une veste qui ressemble à un pavé plein avec une texture imprimée dessus.

Le reste de la pile est classique, comme si la praticité avait été un objectif. Un VAE 3D creux avec un sous-échantillonnage spatial de 16× compresse les assets dans un espace latent compact, et la génération passe par des diffusion transformers ordinaires plutôt que par une architecture maison. Résolution et temps sur une H100 : 512³ en trois secondes environ, 1024³ en dix-sept, 1536³ en une minute environ.

Les matériaux, la partie qui sauve la mise

La fonctionnalité qui compte le plus, c'est le PBR. TRELLIS.2 ne prédit pas seulement une texture de couleur. Il modélise la couleur de base, la rugosité, le métallique et l'opacité en canaux séparés, donc le résultat s'affiche correctement sous un nouvel éclairage au lieu de n'être juste que sous l'angle de génération.

C'est là que la plupart des générateurs 3D s'effondrent en production. Un mesh avec une texture de couleur bakée impressionne dans une visionneuse et part en morceaux dès qu'on change la lumière ou qu'on bouge la caméra. Un mesh avec des maps de rugosité et de métallicité se comporte comme un objet. Le support de la transparence est un gain plus discret mais tout aussi concret : le verre, les feuilles et les tissus troués cessent d'être des cas particuliers.

Le pipeline de traitement est lui aussi étonnamment léger. Convertir un mesh texturé en O-Voxel prend moins de dix secondes sur un seul CPU ; le retour prend moins de cent millisecondes sur CUDA. Pas de boucle d'optimisation, pas de nettoyage par asset. Pour quiconque a attendu un bake de textures, ce passage ressemble à une promesse.

Où ça s'insère dans un vrai pipeline

L'usage le plus réaliste aujourd'hui, ce n'est pas de générer l'asset héros. C'est de remplir l'espace autour. Un packshot a besoin d'une étagère, d'une table, d'un câble, d'une caisse au sol. Ces props sont ennuyeux individuellement et coûteux collectivement, parce que chacun est un boulot de modélisation qui prend un après-midi à un artiste.

L'image-vers-3D à ce niveau de qualité transforme un après-midi en quelques minutes plus une passe de nettoyage. Il faut encore quelqu'un pour vérifier l'échelle, corriger l'origine et reprendre la topologie là où la surface s'est amincie, mais le point de départ est un mesh avec des matériaux au lieu d'un viewport vide. C'est un vrai déplacement des heures, et c'est le genre de gain qui ne finit jamais dans une bande de démo parce qu'il n'a rien de spectaculaire en soi.

L'installation est le vrai portillon

Maintenant la partie honnête. TRELLIS.2 est un dépôt de recherche, et il se comporte comme tel.

Il n'est testé que sous Linux. Il veut un GPU NVIDIA avec au moins 24GB de mémoire, le code étant validé sur A100 et H100. Il lui faut le CUDA Toolkit, recommandé en 12.4, et il compile plusieurs paquets pendant l'installation. Le backend d'attention par défaut est flash-attn ; sur des cartes plus anciennes comme une V100, on installe xformers et on définit une variable d'environnement.

La communauté a comblé le trou avec des nœuds ComfyUI, et au moins trois packs de nœuds circulent, ce qui est à la fois un signe de demande et un avertissement : ils ne sont pas interchangeables, et la première vraie décision de tout projet TRELLIS.2 est d'en choisir un. Les utilisateurs Windows sur cartes RTX 50 ont une douleur bien à eux : ces GPU veulent le pilote 570 ou plus récent et CUDA 12.8 ou 13, ce qui casse plusieurs dépendances compilées pour CUDA 12.6 et antérieur.

Sous 24GB, vous n'êtes pas bloqué, mais vous êtes dans le compromis. Les builds quantifiés tournent en 512 sur des cartes 8GB, à peu près trois à six minutes par mesh sur une RTX 3060. C'est une vitesse de prototypage utilisable et une vitesse de production douloureuse. L'écart entre je peux essayer et je peux livrer se mesure en VRAM.

Il y a aussi un petit piège d'export à connaître avant d'ouvrir un ticket : les fichiers GLB sont exportés avec le mode alpha réglé sur OPAQUE, donc les visionneuses ignorent la transparence que vous avez générée. Le correctif tient en une ligne dans la config de post-traitement, ou en rebranchant le canal alpha dans Blender. Les données sont là. L'exportateur ne s'en sert simplement pas par défaut.

Pourquoi la 3D est le vrai goulot

Regardez où l'IA a mesurablement changé les workflows de production, et où elle ne l'a pas fait. Concept art : changé. Storyboards : changés. Photo produit : changée. Assets 3D : globalement inchangés, parce que le livrable n'est pas une image. C'est un fichier avec de la topologie, des UVs, des matériaux, une échelle et une origine sur lesquels un autre programme doit s'accorder.

C'est un contrat bien plus strict que ça rend bien. Une texture juste à 95% est une texture utilisable. Un mesh juste à 95% est un mesh qui ne ferme pas, qui ne passe pas en booléen et qu'on ne peut pas rigger.

Le pari de TRELLIS.2, c'est qu'on satisfait ce contrat en modélisant la structure nativement plutôt qu'en l'approximant depuis un champ. Qu'O-Voxel devienne un standard ou reste un artefact de recherche dépendra de choses sans rapport avec l'article : l'outillage d'export, les plugins moteur, et la convergence ou non de l'écosystème sur un jeu de nœuds ComfyUI.

La direction, elle, est déjà claire. Le travail 3D utile cette année ne porte pas sur de plus jolies prévisualisations. Il porte sur des sorties qui survivent au contact du programme suivant dans la chaîne. C'est un objectif moins photogénique, et c'est lui qui décide si l'humain reste dans la boucle.