Le Text-to-3D débarque dans votre jeu + les agents vérifient avant de continuer

Deux axes convergents : livraison et fiabilité autonome

Les deux choses les plus remarquables de cette journée correspondent exactement aux deux questions clés sur la route « L'IA crée des jeux » : comment ce qui est créé est-il réellement utilisé et comment l'IA cause-t-elle moins de problèmes aux gens. L'atelier « texte en modèle 3D » de la veille était encore au stade du « banc d'essai » : il pouvait générer, mais le résultat ne s'intégrait pas nécessairement de manière fluide dans un jeu ; ce jour-là, il a parcouru le dernier kilomètre, avec des modèles générés stockés par jeu et atterrissant directement dans votre niveau. D'un autre côté, le "build-gate" installé sur l'IA les jours précédents nécessitait encore que la plateforme surveille de derrière ; cette journée est allée plus loin, en demandant à l'agent de fermer lui-même la boucle "écrire le code → vérifier → continuer", sans s'arrêter pour demander à l'utilisateur à chaque tour. Avec l'accélération du moteur pour les grandes scènes, les progrès de l'animation squelettique et un nouvel exemple de jeu, le thème de la journée est : rendre les capacités véritablement utilisables et l'automatisation véritablement sans souci.

La conversion texte/image en 3D fonctionne réellement : les résultats arrivent dans votre jeu

L'établi de génération 3D est officiellement passé du "banc d'essai" à "réellement utilisable" ce jour. Il pourrait déjà générer des modèles 3D à partir de texte ou d'images, mais la génération n'est que la première étape : un modèle qui ne peut pas être enregistré et intégré en douceur dans le jeu que vous créez n'est qu'une pièce maîtresse isolée. Ce que cette journée a complété est exactement la seconde moitié de la « livraison » : chaque jeu possède son propre stockage d'actifs 3D, et les modèles générés sont archivés par jeu ; la génération s'effectue via un chemin de téléchargement accessible au public et, après connexion à un service externe d'image en 3D, la génération de modèles à partir de texte ou d'images fonctionne désormais de bout en bout dans un environnement réel ; le backend a également ouvert un canal dédié pour servir les ressources 3D par jeu, fournissant la sortie générée par chaque jeu séparément. L'interface utilisateur de l'éditeur d'outils qui l'accompagne a également été reconstruite, alignée sur un style visuel unifié et organisant la barre latérale par étape de génération. Enchaînées ensemble, la distance entre "Je veux un modèle de roche / caisse / petit monstre" et "ce modèle est déjà à mon niveau" s'est soudainement raccourcie - la génération n'est plus une étape distincte où vous transportez manuellement les résultats, mais une étape fluide dans le flux créatif. Pour les créateurs sans compétences artistiques, cela a véritablement aplati une partie de la barre la plus élevée : l’acquisition d’actifs.

Les agents vérifient leur propre travail, au lieu de tarder à vous demander

Poursuivant l'idée du "build-gate" des jours précédents, cette journée a véritablement resserré un peu plus la boucle "écrire → vérifier → continuer" de l'agent. La difficulté précédente était subtile et courante : un agent terminait un morceau de code, sans exécuter de tests de manière proactive ni vérifier si la construction comportait une erreur, mais s'arrêtait pour demander à l'utilisateur "est-ce vrai ?" - pourtant, l'utilisateur ne peut souvent pas juger du tout et ne peut que répondre vaguement "ça devrait aller", laissant passer l'erreur. Cela a effectivement transféré aux gens la responsabilité de vérification qui devrait incomber à la machine. Le changement d'aujourd'hui permet à l'agent d'exécuter automatiquement une vérification après l'écriture du code : il ne se déroule qu'en cas de réussite, et en cas d'échec, il continue de corriger les erreurs spécifiques en main jusqu'à ce qu'il soit vraiment correct – ne plus passer inutilement une de vos conversations sur une question qu'il pourrait se confirmer. Cela prolonge la même logique que les jours précédents "pas de "fait" jusqu'à ce que la construction soit terminée : cette dernière garantit que la livraison finale est correcte, celle-ci fait en sorte que chaque étape intermédiaire se ferme automatiquement autant que possible et dérange moins les gens. Avec un nouveau marqueur « passer au dernier » dans le chat et plus de défilement automatique vous tirant vers le bas tout en examinant d'anciens enregistrements, les longues conversations sont beaucoup plus confortables à revoir. Un véritable bon collaborateur en IA ne devrait « pas se demander ce qu’il peut gérer lui-même », et cette journée s’est déroulée exactement dans ce sens.

La charge à froid d'une grande scène passe d'environ 2 Go à environ 45 Mo.

Le moteur a donné ce jour-là aux grandes scènes complexes un démarrage à froid étonnamment agressif. La difficulté précédente : une scène d'intérieur riche en détails devait lire environ 2 Go de géométrie de maillage lors du premier chargement - non seulement un démarrage insupportablement lent, mais une agonie lors de redémarrages répétés pendant le développement. L'approche actuelle pré-binarise les données du maillage et les regroupe dans un artefact de cache compact : pour la même scène, les données lues lors du premier chargement sont passées d'environ 2 Go à environ 45 Mo, soit un ordre de grandeur plus rapide à démarrer. L'importance est qu'il décide directement "si ce moteur peut exécuter des scènes à grande échelle" - une charge qui prend des dizaines de secondes ou se fige rend les grandes scènes pratiquement inutilisables ; le compresser en quelques secondes est la première fois que des scènes véritablement volumineuses et détaillées deviennent « indolores à développer ». Le moteur peut également allumer des centaines de lumières à la fois dans une scène tout en restant efficace, et intégrer un texte net et net dans l'image ; Ensemble, ces capacités signifient que la gamme de démonstration du moteur peut enfin proposer des scènes sérieuses approchant l'échelle du jeu réel.

Travaux préparatoires sur l'animation squelettique : ouvrir la voie à des "personnages qui bougent vraiment"

Le moteur a également franchi une étape importante dans la ligne d'animation des personnages ce jour-là : le câblage via la chaîne de données de sommets nécessaire à l'animation du skinning du squelette. Cela semble bas, mais cela correspond à l'un des types d'expression les plus importants dans les jeux : un personnage court, saute et ondule naturellement parce que les « os » conduisent la « peau » : à l'intérieur du modèle se trouve un squelette invisible, et à mesure que chaque os oscille, la surface maillée (« peau ») qui y est attachée se déforme, donc le personnage bouge. Pour que ce mécanisme fonctionne correctement, le moteur doit transmettre et calculer correctement la chaîne de données indiquant « quels os affectent chaque sommet, et dans quelle mesure » ​​tout au long du processus. Ce qui est arrivé aujourd'hui est exactement le maillon clé de cette chaîne, associé à une démo montrant plusieurs instances du même personnage skinné à la fois, plus un importateur de modèles reconnaissant plusieurs formats et un résolveur gérant la hiérarchie des os. Il ne s'agit pas encore de "le personnage bouge déjà", mais de l'ingénierie préalable qui rend cette étape possible - avec cette chaîne pavée, l'animation réelle du personnage peut plus tard s'y connecter de manière stable. Pour un moteur visant à créer des jeux, l’animation des personnages est un problème incontournable, et cette journée en a résolu un élément clé.

Un nouvel échantillon de survie par balle rejoint la bibliothèque de jeux

Un exemple de jeu 3D de style « survie par balle » a été ajouté à la bibliothèque ce jour : des essaims de petits monstres se précipitent de tous côtés tandis que le personnage tire automatiquement, les éliminant continuellement et essayant de survivre un peu plus longtemps au milieu d'un encerclement toujours plus dense. Ce genre a été populaire ces dernières années : règles simples, rythme satisfaisant, facile à maîtriser mais rejouable. En faire un échantillon prêt à l'emploi présente deux niveaux de valeur : premièrement, il s'agit d'un produit fini jouable que tout le monde peut ouvrir et jouer, ou modifier dans sa propre version ; deuxièmement, en tant que jeu réel avec une boucle de jeu complète, il teste à son tour si les capacités de la plate-forme et du moteur résistent vraiment - de nombreux ennemis à l'écran mettent l'accent sur la capacité de rendu, le combat automatique met l'accent sur la logique, le rythme de survie met l'accent sur la sensation générale. Les tests de résistance de la plateforme avec un jeu réel exposent les problèmes mieux que n'importe quel test abstrait. Chaque échantillon supplémentaire dans un style différent donne aux créateurs ultérieurs un point de départ supplémentaire sur lequel ils peuvent s'appuyer directement.

Ce que signifie cette journée

Cette journée a fait avancer à la fois la « capacité » et la « fiabilité » – et ce sont précisément les deux piliers d’une plate-forme de création d’IA, dont aucun ne peut manquer pour une démarche régulière. Sur le volet "capacité", la conversion texte-3D a véritablement atterri, de grandes scènes sont devenues exécutables, l'animation squelettique a été pavée et un nouvel échantillon a rejoint la bibliothèque - la plate-forme peut faire des choses plus grandes, plus réelles. Sur le volet « fiabilité », l'agent a appris à vérifier avant de continuer : la plate-forme fait les choses avec plus de sérénité, est moins sujette aux accidents et nécessite une surveillance moins constante. Un outil digne de confiance à long terme ne sollicite jamais une seule jambe, mais avance les deux en alternance coordonnée : plus la capacité est forte, plus il a besoin de fiabilité pour la soutenir, de peur que la puissance n'entraîne au contraire un plus grand risque de crash ; et plus la fiabilité est solide, plus les capacités peuvent être poussées avec audace vers des objectifs plus ambitieux et plus ambitieux. Cette journée a été une étape franchie les deux jambes jointes.