Unity 6.6 sort WebGPU du stade expérimental, mais le laisse désactivé
Unity a publié Unity 6.6 le 1er septembre. Il s’agit d’une version « Supported », ce qui signifie qu’elle bénéficie du même engagement de stabilité qu’une LTS jusqu’à l’arrivée de la 6.7, et qu’elle constitue la dernière étape de la gamme Unity 6 avant cette LTS. Pour tous ceux qui publient dans un navigateur, l’annonce principale tient en une phrase tirée de l’article de l’équipe Web Graphics paru une semaine plus tôt : « à compter d’Unity 6000.6, l’API graphique WebGPU n’est plus expérimentale ; elle est désormais entièrement prise en charge ».
Unity propose WebGPU comme backend expérimental depuis la version 6.1, début 2025. Nous en avions parlé à l’époque et suivons depuis l’évolution côté navigateurs, de l’intégration de WebGPU dans Safari à son arrivée dans tous les principaux navigateurs. Le moteur a désormais rattrapé son retard.
La présentation par Unity des nouveautés de la version 6.6
Ce que WebGPU rend possible
Dans Unity, WebGPU est particulièrement important en raison des compute shaders. WebGL 2 ne les a jamais pris en charge : toutes les fonctionnalités d’Unity reposant sur le calcul GPU étaient donc tout simplement absentes des builds web. Lorsque WebGPU est sélectionné, les builds web bénéficient du GPU Resident Drawer et de l’occlusion culling par GPU, de la mise à l’échelle Spatial-Temporal Post-Processing, de VFX Graph avec des particules simulées par le GPU, des Adaptive Probe Volumes et du compute skinning. Pour illustrer son article, Unity a utilisé les scènes de démonstration Fantasy Kingdom, une ville stylisée très dense, et l’intérieur d’un vaisseau spatial rempli de particules VFX Graph, toutes deux exécutées dans un navigateur.
Les particules VFX Graph sont simulées par le GPU, raison pour laquelle elles n’ont jamais été disponibles avec WebGL 2. Image : Unity.
Il existe également un mode de compatibilité allégé pour le matériel qui annonce WebGPU, mais ne peut pas gérer l’ensemble complet des fonctionnalités. Le même build peut ainsi atteindre davantage d’appareils sans aucune intervention du développeur.
Ce qu’Unity a délibérément choisi de ne pas faire
WebGPU n’est pas activé par défaut. WebGL 2 reste l’API graphique par défaut pour les builds web. Pour utiliser WebGPU, il faut ouvrir les paramètres du lecteur Web, décocher la sélection automatique de l’API graphique et ajouter WebGPU à la liste. À l’exécution, Unity essaie les API par ordre de priorité et passe à la suivante lorsque la première n’est pas disponible.
WebGPU doit être ajouté manuellement à la liste des API graphiques. Image : Unity.
L’article mentionne deux réserves qui peuvent faire perdre une journée entière à ceux qui passent à côté. Premièrement, les navigateurs n’exposent WebGPU que dans un contexte sécurisé. Un build servi depuis un fichier local ou un hôte HTTP non sécurisé repasse donc silencieusement à WebGL 2, vous laissant vous demander pourquoi vos fonctionnalités de calcul ont disparu. Deuxièmement, selon les propres termes d’Unity : « tous les appareils annonçant la prise en charge de WebGPU n’offrent pas une expérience uniforme ». C’est pourquoi la version 6.6 ajoute Graphics Device Filtering, un ensemble de règles permettant de forcer le recours à l’API de repli pour certains navigateurs, GPU ou pilotes identifiés comme problématiques.
Le reste des nouveautés web de la version 6.6 concerne la taille et la mémoire. WebAssembly64 permet à un build pour navigateur d’adresser jusqu’à 16 Go de mémoire, au lieu de l’ancienne limite de 4 Go, dans Chrome et Edge 128 ou versions ultérieures ainsi que Firefox 129 ou versions ultérieures. Progressive Asset Loading fournit les ressources scène par scène plutôt que sous forme d’un téléchargement initial unique. Le joueur peut ainsi commencer dans la première scène pendant que le reste est chargé progressivement. Ces deux fonctions répondent aux deux raisons pour lesquelles les jeux web Unity ont toujours été difficiles à promouvoir : ils étaient volumineux et finissaient à court de mémoire.
Le reste de la version
En dehors du navigateur, Fast Enter Play Mode est désormais activé par défaut pour les nouveaux projets et recharge la scène sans rechargement du domaine. Unity présente ce changement comme une préparation à la transition d’Unity 7 vers CoreCLR. Les dictionnaires sont enfin sérialisés nativement dans l’Inspector. Une nouvelle fenêtre Build Analysis suit l’historique et les métriques des builds, tandis que Content Directories organise le contenu local avec une intégration d’Addressables et la prise en charge de DirectStorage sous Windows et Xbox. Pour illustrer les améliorations apportées aux shaders, Unity cite un build dont la durée est passée de 1 heure 46 minutes à 32 minutes après la conversion des variantes de mots-clés en branches dynamiques.
Ce que cela implique pour les jeux web
Nous travaillons directement avec three.js et WebGPU. Le passage du backend d’Unity au statut de technologie prise en charge constitue donc moins une menace concurrentielle qu’une confirmation. Le calcul GPU dans le navigateur est désormais une voie officiellement prise en charge dans le moteur disposant du plus grand parc installé. Davantage de jeux seront donc publiés en comptant dessus, davantage de joueurs rencontreront les cas limites de compatibilité, et les éditeurs de navigateurs subiront une pression accrue pour les résoudre. Nous avons présenté la situation comparative de WebGPU et WebGL pour les jeux ainsi que les différents choix de moteurs pour le web, et les conseils des deux articles restent valables : publiez avec WebGPU activé et WebGL 2 comme solution de repli, testez sur du matériel d’entrée de gamme réel et considérez que « le navigateur annonce sa prise en charge » ne constitue que le début de la question.
Laisser WebGPU désactivé par défaut est le bon choix pour une version prise en charge, mais c’est aussi révélateur. L’API est prête. Le parc d’appareils n’est pas encore uniforme, et le moteur qui doit fonctionner sur chacun d’eux le sait mieux que quiconque.