4DCodeBench : évaluer les agents sur l'infographie inverse de scènes dynamiques

4DCodeBench est un nouveau benchmark d'infographie inverse 4D par génération de code. Le 4D désigne ici les trois dimensions spatiales plus le temps. La tâche est simple à énoncer. Un agent reçoit une vidéo et doit écrire un programme graphique exécutable. Une fois lancé, ce programme doit reproduire la structure de la scène et les mouvements observés. Cela diffère de la plupart des benchmarks de compréhension vidéo. La réponse n'est ni une légende ni une étiquette, mais du code. On peut exécuter le code, l'inspecter et le comparer à la vidéo image par image. L'évaluation est donc plus difficile à contourner. Un peu de contexte aide. L'infographie directe transforme une description de scène en image : à partir de la géométrie, des matériaux, de l'éclairage et des lois physiques, un moteur de rendu produit des pixels. L'infographie inverse fait le chemin contraire : à partir des pixels, retrouver la description de la scène. Les travaux antérieurs s'appuyaient sur le rendu différentiable, les champs de radiance neuronaux ou le Gaussian splatting. Ces méthodes produisent de grands ensembles de paramètres, difficiles à lire et à modifier. 4DCodeBench choisit une autre voie : il exige une représentation compacte et programmatique. L'agent doit convertir ses observations visuelles en abstractions de la structure et de la dynamique de la scène. Si nécessaire, il implémente des abstractions comme la simulation physique pour reproduire des comportements complexes. Le test ne porte donc pas sur ce que l'agent voit, mais sur sa compréhension de la raison pour laquelle la scène bouge ainsi.

Côté données, le résumé de l'article indique que les auteurs ont réuni des vidéos du monde réel et construit des scènes synthétiques couvrant divers phénomènes physiques : déformation, écoulement de fluides et rupture. Les deux sources ont des rôles distincts. Les vidéos réelles testent la généralisation face au bruit, aux occlusions et aux arrière-plans encombrés. Les scènes synthétiques offrent une vérité terrain contrôlée. Les concepteurs connaissent les paramètres physiques et le programme générateur, et peuvent donc localiser précisément l'erreur d'un modèle. Le choix des trois phénomènes est aussi délibéré. La déformation renvoie à l'élasticité, l'écoulement à la mécanique des milieux continus, la rupture à une défaillance discontinue. Les méthodes numériques, le sens des paramètres et les signatures visuelles diffèrent beaucoup. Une seule recette couvrira difficilement les trois.

Le résumé ne décrit pas le protocole d'évaluation. Ce paragraphe est donc une inférence générale sur ce type de tâche. Consultez l'article complet pour les détails exacts. Une boucle typique ressemble à ceci : percevoir la vidéo, proposer une scène et une hypothèse physique, écrire le code graphique, l'exécuter, comparer le rendu à la cible, puis corriger le code d'après les écarts. La comparaison peut porter sur l'apparence image par image et sur la cohérence temporelle. L'apparence reflète surtout la reconstruction statique. La cohérence temporelle révèle la dynamique. Chaque étape peut échouer : mauvais modèle physique, paramètres à la mauvaise échelle, pas de temps qui fait diverger la simulation, ou code qui ne s'exécute pas. Le résultat central figure dans le résumé. Les auteurs ont évalué largement des modèles de pointe et constatent que de fortes capacités de reconstruction statique ne se traduisent pas encore par une reconstruction fiable des dynamiques complexes. C'est instructif. Un modèle peut placer correctement objets, matériaux et caméras, et pourtant échouer à choisir le bon mécanisme physique, à estimer ses paramètres et à l'intégrer correctement dans le temps. Une scène statique ressemble à un décor bien dessiné. Une scène dynamique exige de saisir la causalité. Le résumé ne donne aucun score, et cet article n'en invente pas. Pour les classements et les écarts par phénomène, lisez l'article et la page publique du benchmark. Le coût et la latence sont eux aussi absents du résumé ; ce qui suit relève de la conjecture raisonnée. La génération de code, l'exécution des simulations et plusieurs tours de correction s'additionnent, et le total croît avec le nombre d'itérations. Les simulations de fluides et de rupture ont un coût de calcul réel, et chaque essai de l'agent exécute un programme. Pour comparer des systèmes, il faudrait publier le nombre d'itérations, la consommation de jetons et le temps de simulation à côté du score final. Sinon, un meilleur résultat peut simplement refléter un budget plus grand. Pour les développeurs et les entreprises, trois points ressortent. D'abord, une représentation programmatique est modifiable, réutilisable et peut se brancher sur un moteur physique. Cela intéresse les jumeaux numériques, la simulation robotique, les effets de jeu et de cinéma, et la visualisation scientifique. Une vidéo convertie en script de simulation que l'on peut ajuster et relancer est bien plus utile qu'un bloc de poids opaques. Ensuite, le benchmark offre une autre façon de tester les modèles du monde : savoir si un modèle comprend la physique peut se vérifier en lui demandant d'écrire une simulation qui tourne et qui correspond. Enfin, le benchmark est public. La communauté suit les progrès avec une seule règle, et les équipes peuvent identifier si le goulot d'étranglement est la perception, la planification, le codage ou la connaissance physique.

Les limites sont réelles. Le résumé contient peu de détails ; les règles de notation, la liste des modèles et le nombre de tâches se vérifient dans le texte complet. La ressemblance visuelle n'est pas la justesse physique : des programmes différents peuvent donner des vidéos semblables, et une métrique doit distinguer un hasard heureux d'une vraie compréhension. Les scènes synthétiques diffèrent des images réelles, donc un gain sur l'une ne se transfère pas forcément à l'autre. Les résultats dépendent aussi des bibliothèques graphiques et des simulateurs employés, et la familiarité avec une bibliothèque peut se glisser dans le score. Pour la suite, plusieurs pistes méritent l'attention : des agents qui exploitent le retour du simulateur pour se corriger, un entraînement sur des données conçues pour la synthèse de programmes physiques, l'association de la physique différentiable et de la génération de code, et des métriques plus strictes pour l'estimation des paramètres. La valeur de 4DCodeBench est de transformer la compréhension d'un monde dynamique en un problème d'ingénierie que l'on peut exécuter et noter. Les modèles de pointe actuels ont encore une distance nette à parcourir sur cette route.