Un backend récupérable en cas de crash + le premier véritable éclairage du moteur

Trois lignes, une résolution : creuser jusqu'au substrat rocheux et re-couler

Les trois grands efforts de la journée partagent un trait commun : aucun n'est de petites réparations sur le sol existant - tous "creusent jusqu'au substrat rocheux et re-versent". Le backend a détruit tout son environnement d'exécution et l'a réécrit selon des couches claires ; le moteur a poussé le rendu du simple nettoyage de l'écran à un véritable éclairage physique ; et même le processus de développement de l’IA qui construit tout cela a été considérablement rationalisé. Oser refaire les fondations alors que le produit peut déjà faire une démonstration reflète un jugement : certaines dettes structurelles contractées tôt pour accélérer deviennent plus coûteuses à mesure qu'elles sont différées, il est donc préférable de les rembourser d'un coup pendant qu'il est encore temps. Cette journée incarne la maturité technique consistant à « faire la bonne réécriture au bon moment ».

Un backend reconstruit : une fondation multi-agents récupérable en cas de crash

Le runtime backend a été réintégré ce jour dans une architecture multi-agents plus robuste et plus claire. Le changement clé est la « récupération après incident » : chaque agent écrit son propre journal d'événements (grand livre) enregistrant tout ce qu'il vit ; Si le processus tombe en panne, ou même si la machine perd de l'alimentation, la réouverture permet au système de rejouer les événements de ce grand livre et de restaurer l'agent dans son état exact d'avant le crash. Cette bouée de sauvetage a été vérifiée à plusieurs reprises par un test de fumée de bout en bout : produire un événement, l'écrire dans le grand livre, le rouvrir et le rejouer dans son intégralité, tout le chemin prouvé. Pour une plate-forme qui souhaite que les agents travaillent longtemps en arrière-plan, il s'agit d'une mise à niveau fondamentale de "un accident efface tout progrès" à "un accident le laisse toujours revivre sur place".

Une architecture en couches : pourquoi diviser le backend en couches claires

Cette réécriture n'était pas seulement un nouveau style de codage, mais divisait le backend en plusieurs couches ascendantes à responsabilité unique : à la base, un squelette de types et de valeurs par défaut ; au-dessus, un bus d'événements et une file d'attente, un tableau noir partagé (état transitoire), un registre d'événements récupérables, une liste d'agents surveillés sur le disque, une fenêtre contextuelle, l'agent lui-même et la boucle qui pilote un tour de sa réflexion, un planificateur par session et, au sommet, les sessions et la gestion des sessions. Chaque couche dépend uniquement de celle située en dessous et n'expose que des interfaces claires, de sorte que chaque couche peut être comprise, testée et remplacée seule. Parallèlement, la liste des agents a été modifiée pour détecter les ajouts et les suppressions en surveillant directement les modifications de fichiers sur le disque, sans maintenir un index susceptible de dériver. La véritable valeur de la superposition est de garder un système de plus en plus complexe toujours « décomposable, compréhensible, modifiable » – c'est exactement pourquoi cela vaut la peine de le recréer.

Le premier véritable éclairage du moteur : une lumière basée sur la physique

Le rendu du moteur a franchi un seuil symbolique ce jour-là : il a allumé pour la première fois une lumière physique. « Basé sur le physique » signifie que la réponse d'un matériau à la lumière suit les règles énergétiques du monde réel, plutôt que de simplement multiplier une couleur par une luminosité. Allumer cette première lumière directionnelle ressemble à de la lumière et de l'ombre ajoutées à l'écran, mais c'est en réalité le moteur qui passe de "peut colorer des formes" au monde de "peut simuler l'interaction réelle entre la lumière et les objets". C'est le point de départ de toute imagerie réaliste : ce n'est qu'avec un modèle d'éclairage correct que les reflets du métal, la douceur du tissu et les bosses d'une surface deviennent ensuite crédibles. Réussir cette première étape la plus fondamentale et la plus cruciale donne le ton correct pour tous les gains ultérieurs de qualité d’image.

Roulettes de lumière, atténuation et cartographie des tons

Après avoir allumé la première lumière directionnelle, le moteur a rapidement ajouté des types de lumière plus riches : des lumières ponctuelles (émettant dans toutes les directions à partir d'un point, comme une ampoule) et des projecteurs (projetant un cône, comme une lampe de poche), tous deux avec une "atténuation de distance" physiquement correcte - plus loin de la lumière est plus sombre, comme l'intuition l'attend. Avec plus de lumières, un nouveau problème est que les hautes lumières « explosent » en blanc mort, donc le mappage de tons est venu ensuite : compresser gracieusement la lumière au-delà de la plage d'affichage de l'écran dans la bande visible, de sorte que les transitions clair-obscur soient naturelles et que les zones lumineuses conservent les détails au lieu de les maculer. Ensemble, cela signifie que vous pouvez désormais utiliser différents types de lumière pour définir l'ambiance d'une scène (une lumière ponctuelle chaude, un projecteur sur un personnage) sans que l'image perde le contrôle de la luminosité.

Un cube texturé, rendu bout à bout

Cette journée a également rendu correctement "un cube texturé" du début à la fin - ce qui semble simple mais nécessite d'aligner plusieurs détails de bas niveau à la fois : l'espace colorimétrique doit passer par la chaîne de traitement correcte (sinon la texture est inclinée en couleur), les faces arrière doivent être éliminées correctement (ou vous voyez des parois intérieures qui doivent être cachées) et la direction d'enroulement du triangle doit être correcte (ou certaines faces se retournent vers l'intérieur et l'objet entier semble plein de trous). Il s'agit du classique "diable dans les détails" du rendu 3D : tout élément est mal aligné et l'image se brise d'une manière étrange. Obtenir un cube texturé dessiné complètement et correctement valide le pipeline complet depuis les données du modèle jusqu'aux pixels de l'écran, éliminant ainsi un lot des pièges les plus courants avant de restituer ultérieurement des modèles véritablement complexes.

Moins de détours dans le processus de développement de l'IA

Cette journée a également considérablement rationalisé le processus de développement derrière « la manière dont l'IA construit tout cela ». Auparavant, le processus interne de modification était lourd : deux étapes de révision distinctes, avec de petites modifications réparties entre différents modèles. Ce jour-là, les révisions dupliquées ont été fusionnées en une seule, produisant un seul artefact unifié, les petites modifications ont été regroupées sur un chemin plus rapide et plus léger et les transferts redondants ont été supprimés. Résultat : le même changement nécessite beaucoup moins de détours tout au long du processus, de petites choses qui devraient être rapides et véritablement accélérées, sans pour autant perdre un contrôle rigoureux. Invisible pour les utilisateurs, cette ligne décide directement de la rapidité avec laquelle l'équipe (et le développement de plus en plus axé sur l'IA) peut produire de manière constante – lisser la « chaîne de montage qui fabrique les choses » compte autant que peaufiner le produit.

Ce que signifie cette journée

Ce jour-là, rien n'était une fonctionnalité superficielle « ajouter un bouton » ; les trois lignes ont fait le travail le moins flatteur mais le plus essentiel : réécrire le backend pour résister aux accidents, pousser le rendu pour simuler la lumière réelle et remodeler le processus de développement lui-même pour qu'il soit plus précis. Ensemble, ils répondent à une question : cette chose peut-elle réellement résister à une utilisation sérieuse et à long terme ? Avec la reprise après incident, confier le travail au backend n’est plus angoissant ; avec l'éclairage physique allumé, le moteur s'engage véritablement sur la voie de « peut créer de beaux jeux » ; avec un processus plus simple, cette évolution rapide peut se poursuivre. Re-couler les fondations tôt vous permet de construire plus haut et avec plus de confiance plus tard - et c'est la ligne que cette journée laisse pour le développement futur.