Les conteneurs spatiaux OpenXR apportent des règles de multitâche 3D

Les conteneurs spatiaux OpenXR définissent un espace géré par le système où plusieurs applications 3D peuvent s'exécuter côte à côte. Le Khronos Group a ratifié deux extensions le 19 octobre et les a publiées pour le multitâche XR multiplateforme. Google affirme qu'Android XR les supportera.

Comment fonctionnent les conteneurs spatiaux OpenXR

Khronos décrit un conteneur spatial comme un espace géré par le système pour le contenu XR, similaire à la façon dont une fenêtre de bureau contient une application 2D. Le modèle permet à une application d'ouvrir un ou plusieurs conteneurs tout en laissant le placement et les contrôles système connexes au runtime.

Les deux extensions sont XR_EXT_spatial_container et XR_EXT_spatial_container_self_rendering. La première permet aux applications de créer et de gérer des conteneurs. La seconde permet aux applications de dessiner dedans par le biais des couches de composition OpenXR.

• Le système contrôle où se trouve chaque conteneur.
• Les utilisateurs peuvent placer du contenu autour d'eux ou le faire les suivre en se déplaçant.
• Les conteneurs peuvent être affichés ou masqués.
• Un conteneur peut être sélectionné pour l'entrée.
• Chaque conteneur peut basculer entre le mode limité pour le multitâche et le mode immersif qui remplit la vue.

Khronos affirme que les fournisseurs de runtime et de moteurs ont travaillé sur la fonctionnalité pendant 18 mois. Le groupe de travail développe également des extensions qui permettraient aux applications d'utiliser un moteur de rendu fourni par le système et ajusté à chaque appareil. Khronos s'attend à ce que les implémentations se déploient au cours de 2026.

Mise à jour (2026-11-01) : VR.org News rapporte que les deux extensions ont rejoint le registre OpenXR avec la version 1.1.63 de la spécification le 1er septembre 2026. VR.org News rapporte également que OpenXR SDK 1.1.65, publié le 16 octobre, a ajouté un exemple de code de conteneur spatial, des entrées de manifeste Android et un commutateur de ligne de commande à hello_xr. L'exemple crée jusqu'à trois conteneurs et peut basculer son troisième conteneur entre les modes limité et immersif. Un runtime peut ne supporter qu'un seul des modes limité ou immersif, et les changements de mode sont des demandes asynchrones qui peuvent être rejetées. L'intégration du conteneur spatial de Godot a fusionné sous la jalon 4.8 et a été incluse dans la bêta 1 de Godot 4.8. Monado n'avait pas de support de conteneur spatial sur sa branche principale au moment de la publication.

Entreprises et plateformes impliquées

L'annonce de Khronos comprend des déclarations de Google, Meta, PICO, Unity, Varjo, Collabora et l'équipe Godot XR. Jared Finder de Google a déclaré que Google était « enthousiaste à l'idée d'apporter le support des conteneurs spatiaux à Android XR. » L'équipe Godot a déclaré que sa prochaine version supportera la fonctionnalité.

La déclaration de Meta soutient l'idée plus large mais ne s'engage pas explicitement à supporter les conteneurs spatiaux sur Quest. Le support d'Android XR est prévu, tandis que le support sur d'autres plateformes dépend de la mise en œuvre de chaque runtime. L'exemple du SDK OpenXR et la bêta 4.8 de Godot montrent la progression du développement, mais n'établissent pas le support sur tous les runtimes.

Ce que le multitâche OpenXR pourrait changer

Road to VR compare cette approche avec Shared Space sur Apple Vision Pro, où plusieurs applications 3D peuvent se situer l'une à côté de l'autre. Quest exécute actuellement une seule application immersive à la fois aux côtés de fenêtres 2D et de menus système.

Une norme commune pourrait permettre aux développeurs de créer des applications 3D de multitâche une seule fois pour Quest, Android XR, PICO et PC VR au lieu d'écrire une version différente pour chaque plateforme. Le modèle commun couvre la création de conteneurs, le placement, la visibilité, la sélection d'entrée et les transitions entre la présentation limitée et immersive.

visionOS d'Apple et PS VR2 ne supportent pas OpenXR, ils sont donc en dehors de cet effort. Pour les runtimes supportés, la disponibilité réelle dépend toujours de la mise en œuvre, y compris des modes de conteneur qu'un runtime accepte et de la réussite des demandes de changement de mode asynchrones.