Gemini 4 Carbon a écrit seul un path tracer en CUDA et rendu une minute d'animation

Habituellement, une démo du type « l'IA a écrit du code » ressemble à ceci : le modèle a produit une landing page, un jeu du serpent ou un parseur. Ici, l'histoire est différente. D'après la description de l'auteur de la démo (compte fofrAI sur X, repris dans le canal Telegram « Metaversichche i IIsche »), le modèle Gemini 4 Carbon a parcouru seul tout le chemin, du dossier vide à la vidéo finale : géométrie, lumière, physique, caméra et musique.

Ce que le modèle a concrètement construit

Voici la liste telle qu'elle apparaît dans le post.

Premièrement : un moteur de rendu 3D maison en C++ et CUDA. Il repose sur le path tracing, c'est-à-dire un calcul rigoureux de la lumière, des réflexions et des ombres par lancer de rayons sur une carte graphique NVIDIA. Il ne s'agit pas d'appeler le bouton « Render » de Blender, mais d'un code qui calcule lui-même comment la lumière rebondit sur les surfaces.

Deuxièmement : la physique via MuJoCo. C'est un moteur courant en robotique. Il calcule la gravité, les collisions, le frottement et l'interaction entre solides.

Troisièmement : la scène. Le modèle a conçu une machine de Rube Goldberg, où billes et leviers se déclenchent en chaîne. Il a ensuite créé un studio 3D et un travelling continu de la caméra.

Quatrièmement : le rythme. Le mouvement de la caméra a été synchronisé avec un morceau de Lyria 3.5, le modèle musical de Google.

Pourquoi ce n'est pas qu'une belle image

Le chiffre clé est ici : 60 secondes de simulation pour 120 000 pas, soit 2 000 pas par seconde. Il n'y a aucune image clé. Les objets bougent parce que des forces simulées les poussent, et non parce que quelqu'un a dessiné une trajectoire. Pour une machine de Rube Goldberg, c'est essentiel : si un seul maillon de la chaîne est mal calculé, la bille n'arrive pas au bout et toute la réaction s'effondre. On ne peut pas simuler une telle vidéo « à l'œil » : la physique fonctionne ou non.

Deuxième point : l'ampleur de la tâche. Elle réunit programmation graphique, code GPU, modélisation physique, composition de scène, travail de caméra et calage sur le son. Ce type de tâche se prête mal aux benchmarks standards : chaque élément est familier au modèle pris isolément, la difficulté est de les faire s'emboîter sans que tout casse au centième de seconde.

Une ironie à part : la blague sur NVIDIA Omniverse dans le titre du post d'origine. Omniverse était vendu comme une plateforme de simulation et de pipelines 3D. Ici, le modèle a assemblé un pipeline comparable à partir de composants ouverts et prêts à l'emploi. Et il tourne malgré tout sur CUDA, de sorte qu'un tel scénario profite plutôt au matériel NVIDIA.

Ce que nous ignorons

La prudence s'impose. La source est un post Telegram qui reprend des tweets, et il s'agit d'une seule vidéo de démonstration, non d'une expérience reproductible. On ne voit pas dans le matériel à quoi ressemblait le prompt, combien d'itérations ont été nécessaires, si un humain est intervenu, a corrigé des erreurs, ni combien a coûté l'exécution. La qualité d'image reste également floue : un path tracer écrit « from scratch » peut produire du bruit et des artefacts qu'un moteur mature n'aurait pas. Enfin, « l'a écrit seul » ne veut pas dire « l'a imaginé seul » : MuJoCo et CUDA sont des outils existants, et le modèle les a assemblés.

L'affirmation du post selon laquelle « on n'a plus besoin de graphistes 3D » est donc une blague, pas une conclusion. C'est toujours l'artiste qui décide ce qui mérite d'être montré, et un pipeline de studio comporte des éléments invisibles dans la démo : assets, retouches d'animation, validation par le client.

Que faire concrètement

Pour un développeur ou un product manager, la conclusion est plus modeste mais plus utile. Premièrement, il faut cesser de mesurer un modèle sur de petites tâches. S'il assemble d'un seul coup la combinaison « code GPU + physique + visuel + son », les prototypes de simulateurs, de visualisations et d'environnements d'apprentissage peuvent être réalisés bien plus vite. Deuxièmement, les moteurs physiques comme MuJoCo sont des vérificateurs pratiques : le résultat est plausible ou non, ce qui aide à repérer les erreurs du modèle. Troisièmement, si vous développez des outils pour la 3D, les jeux ou la robotique, lancez un scénario aussi long sur votre propre stack pour voir où exactement il casse.

Une démo n'est pas une preuve, mais c'est une bonne occasion de mettre à jour votre jeu de tests. Si Gemini 4 Carbon est réellement capable de cela sur commande, et non par un heureux hasard, c'est le seuil d'entrée des prototypes graphiques complexes qui changera le plus.