Un inspecteur d'actifs + un commutateur sans blocage + un support Windows

Après la sortie, passage au polissage

L'open source a rendu le projet public, et le véritable test commence au moment où il est remis : plus de personnes, des ordinateurs plus variés, des yeux plus critiques exposeront chaque point qui n'est pas assez fluide ou stable. Ce jour était le tournant après la sortie : ne pas rechercher de nouvelles fonctionnalités éblouissantes, mais s'installer pour peaufiner l'expérience existante de manière plus fluide et renforcer les fondations plus stables. L'inspecteur d'actifs permet aux créateurs de voir clairement chaque matériel en main ; la commutation sans décrochage supprime les problèmes les plus fréquents lors d'une utilisation quotidienne ; La compatibilité Windows permet à plus de personnes d'entrer ; l'auto-guérison du moteur empêche les accidents d'interrompre facilement les personnes ; et les vérifications du contrat au moment du chargement empêchent les modifications du code de l'IA de s'échapper avec des erreurs. Individuellement petits, tous ces objectifs visent à « est-il réellement fluide et stable à utiliser » – exactement ce qu'un projet qui vient d'être présenté au public devrait renforcer immédiatement. Une première impression ne se produit qu’une seule fois, et chaque morceau de vernis après la libération la protège.

Un inspecteur d'actifs : voyez clairement chaque actif

L'éditeur a obtenu aujourd'hui un panneau d'inspecteur d'actifs, couvrant tous les types d'actifs d'un projet. Il répond à un besoin fondamental mais manquant depuis longtemps : lorsque votre projet accumule de nombreux matériaux (maillages, matériaux, textures, animations, scènes), comment voir rapidement ce qu'est réellement l'un d'entre eux ? Auparavant, vous ne voyiez souvent qu'un nom, et pour connaître son apparence et ses propriétés, vous deviez le placer dans une scène. Sélectionnez maintenant n'importe quel élément et l'inspecteur de droite donne un aperçu et des détails appropriés : choisissez un maillage et voyez sa forme, un matériau et voyez la qualité de sa texture, une texture et voyez l'image, une animation et voyez ses informations. Un « navigateur de contenu » était également lié au panneau matériel, formant un flux cohérent depuis la navigation jusqu'à la visualisation et l'édition. L'importance pour les créateurs est de « savoir ce que vous avez » : un projet un peu plus vaste contient facilement des dizaines ou des centaines d'actifs, et le fait de pouvoir ouvrir et voir clairement chacun d'entre eux vous évite de tâtonner parmi un tas de noms vagues, augmentant ainsi l'efficacité de la gestion et de la réutilisation des matériaux.

Changer sans caler : garder le contexte de rendu actif

Cette journée a résolu un vieux problème très pénible et, dans l'utilisation quotidienne, extrêmement fréquent : le décrochage à la commutation. Auparavant, qu'il s'agisse de basculer entre différentes scènes ou de basculer entre les modes « édition » et « lecture », le système démontait et reconstruisait l'ensemble du rendu graphique sous-jacent : un flash noir, une réinitialisation et, au plus lent, un gel pur et simple. La cause première : chaque commutateur reconstruit le contexte de rendu, et la reconstruction d'un contexte graphique est une opération assez coûteuse et sujette à des erreurs dans certains environnements de navigateur : plus vous changez souvent, plus il risque de se briser. La solution d'aujourd'hui est "keep-alive" : la commutation ne détruit et ne reconstruit plus mais maintient le contexte de rendu vivant en arrière-plan (déplacé hors écran plutôt que détruit) et le réutilise directement en cas de besoin. En mode sur place, le basculement entre les scènes et entre le montage et la lecture devient fluide et instantané, sans écrans noirs ni blocages. Pour un outil de création qui vous encourage à « modifier, jeter un coup d'œil, modifier à nouveau », la commutation est l'une des actions les plus fréquemment déclenchées ; passer de « reconstruire à chaque fois » à « changer instantanément à tout moment » supprime directement l'obstacle le plus gênant dans le flux créatif.

Multiplateforme : un lot de correctifs Windows

Maintenant qu'il est open source et souhaite que le plus grand nombre de personnes possible l'utilise, il fallait s'attaquer à Windows. Cette journée a balayé un lot de problèmes de compatibilité Windows, tous les pièges typiques du type "bien sur un autre système, inexplicablement cassé sous Windows": la façon de savoir si un processus est toujours en vie nécessite une approche différente pour être correcte dans le terminal Windows; les liens symboliques créés lors de la création d'un nouveau projet atteignent les limites d'autorisation sous Windows, contournés par un équivalent Windows natif ; et le décodage de la carte d'environnement (format HDR) a également été corrigé sous Windows. Les scripts de démarrage ont été renforcés pour une utilisation multiplateforme. Chaque problème est discret, mais un seul problème non résolu pourrait bloquer un utilisateur Windows lors de l'installation, de la création du projet ou de la première exécution, le faisant carrément rebondir. Parcourir tout ce chemin, de l'installation à l'exécution, en travaillant sur Windows ouvre la porte aux utilisateurs Windows qui détiennent la majeure partie du marché des ordinateurs de bureau - et pour un projet simplement open source désireux d'être essayé par davantage de personnes, l'importance pratique de cette étape est particulièrement grande.

Auto-réparation du moteur : récupération après une perte de périphérique, dégradation gracieuse dans les limites

Le moteur a fait un grand pas en avant dans la « résistance aux accidents » ce jour-là. La première est l’auto-réparation du périphérique/surface : un périphérique graphique peut soudainement tomber en cours de fonctionnement pour diverses raisons (pression des ressources du système, réinitialisation du pilote), ce qui signifiait auparavant souvent que l’écran devenait noir sans récupération ; maintenant, le moteur détecte une telle baisse et tente de rétablir automatiquement le rendu afin que l'image revienne, plutôt que de mourir. Deuxièmement, il y a une dégradation gracieuse sous certaines limites : dans certains environnements de navigateur plus faibles, la sonde du moteur sur la capacité de la mémoire vidéo peut ne pas obtenir une valeur précise, et aujourd'hui, elle retombe à un plafond par défaut sûr alors qu'elle ne le peut pas ; et lorsque le contenu à restituer dépasse la capacité, il « restitue désormais un sous-ensemble tronqué » plutôt que de sauter l'image entière, préférant dessiner un peu moins plutôt que de détruire l'image entière ; les crashs de bas niveau ont également été isolés en erreurs récupérables. Le thème commun est la « résilience » : un moteur destiné à faire face à toutes sortes d’appareils réels et à être utilisé pendant de longues périodes par des gens ordinaires ne peut pas supposer que tout est parfait ; la marque de la vraie maturité est que, lorsque l'imperfection survient, elle résiste, se rétablit et continue de travailler à un niveau réduit, plutôt que de se mettre en grève au premier accident.

Vérifications du contrat de temps de chargement + réécriture de scène

Cette journée a ajouté une autre protection à la ligne « L'IA écrit du code » : les vérifications des contrats au moment du chargement. Lors du chargement d'un jeu, le système vérifie automatiquement que le code du jeu correspond aux interfaces du moteur — un « contrat » étant les conventions d'appel prescrites par le moteur ; Si, après que l'IA a modifié le code, certains endroits utilisent mal une interface ou si les interfaces entre fichiers ne correspondent pas, le système signale cette "dérive" directement et de manière visible dans une superposition d'erreurs à l'écran, plutôt que de planter inexplicablement à mi-chemin. Cela définit effectivement un autre point de contrôle automatique entre « écriture terminée » et « en cours d'exécution », détectant sur place les erreurs au niveau de l'interface. Pendant ce temps, le moteur a terminé la « réécriture » de la scène : il peut sérialiser le contenu de la scène actuelle dans un pack d'actifs structuré et rechercher l'identifiant à l'envers à partir du contenu. Cela pose les bases sous-jacentes à la boucle « modifier dans l'éditeur et enregistrer immédiatement » : l'édition ne consiste pas seulement à visualiser et à régler ; les changements doivent également persister de manière fiable. Ces deux éléments, l'un après l'autre, fiabilisent « les produits de la création » : en garantissant l'alignement du code et la sauvegarde des résultats d'édition.

Rembobinage du point de contrôle du terminal + touches de collaboration multi-agents

Aujourd'hui, la version ligne de commande/terminal a gagné des fonctionnalités correspondant à l'interface graphique : points de contrôle et rembobinage. Vous pouvez ramener une conversation à un point de contrôle antérieur et réessayer, en revenant si vous n'êtes pas satisfait ; la récupération de session a été ajoutée : après une interruption, une commande reprend là où vous l'avez laissée, sans recommencer ; plus une superposition pour vous poser des questions. L'interface de chat a continué à peaufiner les détails en direct de la collaboration multi-agents : lorsqu'un sous-agent confie une tâche à un autre, un en-tête de relais clair indique la relation de transfert ; les agents liés sont regroupés par « familles de producteurs », chacun dans sa propre catégorie ; les opérations sensibles nécessitant votre appel reçoivent une carte de confirmation d'autorisation dédiée ; et les avatars des agents ont été légèrement surélevés et agrandis pour rendre plus clair d'un seul coup d'œil « qui est actif, qui vous attend ». Ensemble, ils servent une chose : lorsque vous demandez à une équipe d'IA chargées de tâches différentes de collaborer, l'ensemble du processus doit être clair, contrôlable et toujours susceptible d'être annulé : vous comprenez ce qu'ils font tout en gardant l'initiative de s'arrêter et de revenir en arrière.

Ce que signifie cette journée

Si la version open source de la veille consistait à « ouvrir la porte et inviter les gens à entrer », cette journée consistait à « ranger la maison pour que les gens y vivent à l'aise ». Il n'avait aucune nouvelle fonctionnalité révolutionnaire, tout était peaufiné et renforcé : vous permettant de voir clairement chaque actif, de continuer à passer des accrocs, de laisser les utilisateurs de Windows entrer, d'aider le moteur à résister aux accidents, d'empêcher le code de l'IA de s'échapper avec des erreurs, de rendre la collaboration multi-agents claire et contrôlable. Ce que tout cela souligne, c'est la « convivialité » et la « fiabilité » – exactement les deux choses qu'un projet qui vient d'accueillir un flot de nouveaux utilisateurs doit le plus renforcer en même temps. Les nouveaux utilisateurs ne resteront pas pour une fonctionnalité éblouissante, mais pourraient bien se détourner à cause d'un seul blocage, d'un seul crash, d'un seul échec d'exécution sous Windows. Résoudre ces problèmes banals d'expérience et de stabilité un par un semble évident, mais cela renforce réellement les bases de l'utilisation réelle qui suit l'open source. La libération est un point de départ et non une fin ; cette journée a marqué le début de la prise au sérieux du fait d'être réellement utilisé par les gens.