Le moteur est entièrement autonome + des matériaux plus riches

Le tournant décisif de l'autonomie : de la "coquille empruntée" à "l'autonomie"

C'est un jour décisif dans l'histoire du moteur. Depuis le début, le moteur a conservé une dépendance de faible niveau à l'égard d'une bibliothèque de rendu externe mature à usage général – en l'utilisant comme « réponse de référence » pour vérifier si son propre rendu était correct. Aujourd'hui, cette dernière dépendance a été entièrement supprimée et le moteur fonctionne désormais uniquement sur son propre pipeline de rendu. Il ne s’agit pas d’une suppression de dépendance ordinaire mais d’un changement de posture : de « se tenir sur les épaules des autres, en faisant toujours référence à quelqu’un d’autre » à « être la norme elle-même ». Les éléments ci-dessous – une référence d'auto-vérification, des matériaux plus riches, une compatibilité des appareils, un aperçu natif – sont tous l'accompagnement autour de ce « autonome », déclarant ensemble que ce moteur est devenu un moteur de rendu mature et autonome.

Un benchmark de parité de pixels intégré : se vérifier

Après la suppression de la bibliothèque externe, un problème pratique s'est posé : auparavant, cette bibliothèque était la référence pour confirmer « le rendu est-il correct », et sans elle, qu'est-ce qui garantit la qualité ? La réponse : le moteur possède son propre benchmark de "parité de pixels" : il génère sa propre réponse de référence et vérifie chaque image rendue pixel par pixel, alarmant en cas de déviation. Cela transforme le « juge de qualité » emprunté à l'extérieur en un élément intégré au moteur lui-même. Son importance est considérable : à partir de maintenant, la qualité d'image, les performances et l'évolution des fonctionnalités du moteur sont entièrement entre ses mains, et ne sont plus régies par les limites et les compromis de capacités d'une bibliothèque externe – quoi que vous souhaitiez ajouter ou optimiser, sans contourner les limites de quelqu'un d'autre. Un moteur capable de se vérifier est véritablement qualifié pour évoluer de manière autonome sur le long terme.

Matériaux PBR de niveau 1 : émissifs + occlusion ambiante + looks de mappage de tons

Le système matériel a été unifié et a atteint un niveau supérieur ce jour-là. Le niveau bas fusionnait ce qui était auparavant plusieurs variantes de matériaux en un modèle de matériau unifié basé sur le « passage de rendu », simplifiant les concepts et laissant la place à l'ajout de nouvelles fonctionnalités. Sur ce modèle unifié, plusieurs capacités améliorant le réalisme ont été ajoutées : émissive, permettant aux objets de briller d'eux-mêmes pour les enseignes au néon, les runes lumineuses et les noyaux d'énergie ; occlusion ambiante, crevasses, coins et points de contact naturellement assombris pour renforcer considérablement la profondeur ; et plusieurs looks de mappage de tons pour choisir l'ambiance générale de l'image (cool, chaleureux, cinématique, etc.). Pour éviter que "plus de variété de matériaux" ne "coûte la fréquence d'images", ces matériaux complexes sont transmis via un cache de pipeline de rendu, les réutilisant et gardant les différents séparés. Tout compte fait, les éléments d'une scène semblent plus « corrects » et plus tactiles – la mise à niveau clé de « peut rendre » à « rend magnifiquement ».

Prise en charge plus large des appareils : la couche appareil terminée + repli sans fonctionnalités avancées

Cette journée a également fait progresser le « laisser tourner le moteur sur plus de machines ». La « couche de périphérique de rendu » de bas niveau complète un ensemble complet de fonctionnalités clés, de sorte que le moteur peut pleinement demander et utiliser les ressources du périphérique dont le rendu a besoin dans le navigateur, sans plus manquer d'éléments ; sur le chemin de secours sans les dernières fonctionnalités du GPU, les lacunes restantes pour un « rendu correct » ont été comblées une par une. De manière encore plus réfléchie, pour les appareils dépourvus de certaines fonctionnalités GPU modernes, un itinéraire de compatibilité matérielle a été construit afin qu'ils puissent dessiner correctement des objets même sur un chemin simplifié. Résultat net : la gamme de machines capables d’exécuter correctement la 3D s’est encore élargie d’un cran. Pour une plate-forme grand public, « fonctionne sur des machines plus faibles » compte autant que « a meilleure apparence » : le premier décide combien de personnes peuvent entrer, le second s'ils restent.

Un lecteur natif en avant-première : un jeu en cinquante lignes

Les jeux en avant-première de ce jour ont été déplacés vers l'hôte d'exécution natif de la plate-forme : une entrée de jeu propre et un chargeur chargé de charger et d'exécuter correctement un jeu, sans passer par un hôte externe. Le modèle de jeu a été compressé à une cinquantaine de lignes, ce qui signifie que l'écriture d'un jeu exécutable commence à partir de cinquante lignes. La valeur ici est "un point de départ assez léger" : un débutant ou une IA n'est pas confronté à un gros morceau de code-cadre à comprendre en premier, mais à un squelette minimal et clair prêt à s'appuyer immédiatement. Plus le démarrage est léger et standard, plus la voie à suivre pour « donner naissance à un jeu » est fluide : l'IA générant du code à partir de ce démarrage propre fait moins d'erreurs, et un humain prenant le relais trouve plus facile à lire et à modifier. Un hôte natif et un modèle minimal constituent une étape vers la réduction de la barre d'entrée pour "créer un jeu" au plus bas.

Stabilité : HTTPS partout + aperçu de la récupération automatique

Cette journée a également ajouté deux touches de stabilité. L'un d'entre eux est la prise en charge d'un mode de développement « HTTPS partout » : certaines fonctionnalités des navigateurs modernes (y compris certaines fonctionnalités graphiques et de l'appareil) ne sont accordées que sous une origine sécurisée, et HTTPS les rend correctement disponibles tout en correspondant mieux à un environnement de déploiement réel. L'autre est la récupération automatique de l'aperçu : lorsque l'aperçu échoue en raison d'un problème transitoire du backend, il essaie de se reconnecter et de s'auto-réparer tout seul, plutôt que de rester sur une page d'erreur en attendant une actualisation manuelle. Les deux visent à "ne pas vous interrompre" - ce qui interrompt le plus le flux pendant le développement n'est souvent pas un gros bug mais ces petits problèmes récurrents nécessitant un sauvetage manuel de temps en temps. Les automatiser est ce qui permet de s'asseoir pour rendre un jeu pendant des heures vraiment fluide.

Ce que signifie cette journée

Le cœur de cette journée est le moteur qui termine son « indépendance ». La suppression de la dernière dépendance de rendu externe et l'utilisation de son propre benchmark de parité de pixels signifient qu'il est passé de "fonctionnant sur un shell emprunté, référençant d'autres" à un moteur de rendu mature qui se suffit à lui-même et se vérifie. Sur cette base, les matériaux ont atteint une véritable qualité tactile, la compatibilité des appareils a atteint des machines plus faibles, l'aperçu a obtenu un point de départ natif minimal et la stabilité est devenue plus résiliente – chacune étant une extension qui signifie plus après cette indépendance. Une plate-forme qui ose réaliser sa base de rendu la plus fondamentale entièrement en interne, ne dépendant d'aucune bibliothèque externe, est après avoir tenu son propre destin : à partir de maintenant, jusqu'où peut aller la qualité de l'image, jusqu'où les performances peuvent être optimisées et quelles nouvelles fonctionnalités prendre en charge ne sont plus à la merci des autres. C’est le poids pour lequel cette journée mérite le plus d’être rappelée.