Meta Quest est maintenant une cible

Les lunettes AR que vous pouvez acheter n'existent pas encore - mais des millions de gens possèdent déjà un casque. RakuAI rencontre maintenant vos utilisateurs là où ils sont, avec une définition d'expérience qui se porte directement vers les lunettes quand elles sortiront.

Une réunion avec un partenaire vers la fin de la semaine dernière a rendu le prochain mouvement évident. La cible produit finale pour Raku, ce sont des lunettes AR. La cible produit aujourd’hui, ce sont aussi des lunettes AR, mais les lunettes AR sur lesquelles nous voulons nous déployer n’existent pas encore sous une forme que quiconque peut acheter. Cet écart est réel. Il est aussi frustrant, parce que les expériences que nous voulons que les gens vivent sur ce moteur ne devraient pas avoir à attendre le matériel.

Ce week-end nous avons comblé l’écart d’une autre façon. Le runtime tourne maintenant sur les casques Meta Quest avec Horizon OS, en mode AR passthrough, à travers la couche OpenXR que Meta expose. Le Quest n’est pas le facteur de forme que nous optimisons ultimement. C’est le facteur de forme que les gens possèdent déjà.

Ce qui a atterri

Trois PR de runtime et les pièces SDK correspondantes :

• Intégration OpenXR/Quest VR avec rendu stéréo et suivi 6DoF
• Mode AR passthrough pour Meta Quest avec couches de composition et fondu alpha
• Documentation des permissions Horizon OS pour l’AR passthrough Quest

Le SDK a eu le travail correspondant : exemples C étendus pour Quest VR avec sélection de runtime adaptative à la plateforme, documentation complète Meta Quest (Horizon OS) pour l’intégration OpenXR, support d’exemple Quest VR et validation CI, et un passage de documentation AR passthrough Meta Quest avec comparaison de plateformes.

Le côté gouvernance a eu l’Epic #190 : Support OpenXR Horizon OS (Meta Quest), plus une documentation de référence pour l’intégration. La PR de documents stratégiques (#193 dans le dépôt de gouvernance) a intégré le contexte d’une réunion avec un partenaire plus tôt dans la semaine.

Pourquoi Quest, pourquoi maintenant

Deux raisons.

Le Quest est la plus grande base installée de l’informatique spatiale en ce moment. Si vous voulez qu’une expérience AR sérieuse atteigne un public significatif en 2026, le Quest est l’appareil que ce public possède déjà. Construire pour l’appareil qu’ils ont permet au moteur de faire ses preuves avec de vrais utilisateurs avant que le matériel de classe lunettes ne se déploie à l’échelle grand public. La bonne chose à faire est de rencontrer les utilisateurs là où ils sont.

Le runtime OpenXR du Quest est une implémentation réelle, pas une demi-spec. Ceci compte plus que les gens ne lui en accordent le crédit. Meta a beaucoup investi dans la conformité OpenXR, dans l’AR passthrough à travers XR_FB_passthrough, dans le rendu fovéal à travers XR_FB_foveation, et dans le suivi des mains à travers XR_EXT_hand_tracking. Les extensions que le Quest expose sont les mêmes extensions que notre runtime a commencé à consommer sérieusement il y a deux semaines. L’intégration n’a pas été gratuite, mais elle a été beaucoup moins coûteuse qu’elle ne l’aurait été contre une cible OpenXR moins conforme.

Ce que fait réellement le mode AR passthrough

Le Quest est un appareil d’abord VR avec un mode AR passthrough boulonné par-dessus. Ça sonne comme un compromis, et en un sens ça l’est. En un autre sens, c’est une fonction de contrainte qui rend l’AR sur le Quest plus disciplinée qu’elle ne le serait autrement.

Le gestionnaire de couches de composition que nous avons fait atterrir il y a deux semaines pour OpenXR en général est ce qui fait fonctionner le passthrough proprement. Le passthrough caméra arrive comme une couche de composition. Le contenu virtuel de notre runtime arrive comme une autre, avec un fondu alpha pour que le contenu virtuel se compose correctement contre le monde réel que l’utilisateur peut voir à travers les caméras. Les superpositions système (l’interface propre de Meta quand elle est invoquée) arrivent comme une troisième couche au bon ordre de z.

Le fondu alpha est la partie subtile. L’alpha prémultiplié compte. L’estimation d’éclairage compte. Le contenu virtuel doit être corrigé en couleur par rapport à l’éclairage ambiant que montrent les caméras, sinon il flotte de façon peu convaincante. Le travail d’estimation d’éclairage qui a atterri il y a trois semaines dans le runtime est ce qui fait que le mode AR ressemble à de l’AR plutôt qu’à un autocollant plat sur un flux vidéo.

La question des permissions Horizon OS

Le modèle de permissions de Meta pour l’AR passthrough est plus élaboré que ce à quoi la plupart des développeurs s’attendent en venant de la VR desktop. Le runtime doit déclarer les bonnes entrées de manifeste, demander les bonnes permissions runtime, et dégrader avec grâce quand un utilisateur en refuse une. La PR de documentation qui a atterri en milieu de semaine (#149 dans le runtime, plus la documentation SDK correspondante) est destinée à empêcher les développeurs qui construisent sur Raku de tomber dans la falaise de permissions que Meta a construite autour du flux caméra pour des raisons de confidentialité.

L’histoire de confidentialité compte. Les caméras d’un Quest voient le domicile de l’utilisateur. Tout ce que le moteur fait avec ce flux caméra doit être opt-in, transparent, et auditable. C’est vrai sur Quest. Ce sera encore plus vrai sur des lunettes AR que les gens portent en public. Le travail que nous faisons ce week-end pour gérer correctement le modèle de permissions du Quest se portera vers chaque déploiement plus sensible plus tard.

Le contexte de la réunion avec le partenaire

Une note sur la PR de documents de gouvernance. L’équipe de relations développeurs de Meta et moi avons parlé. Je ne vais pas résumer le contenu de ces conversations sur le blog public, parce que les conversations sont encore en cours. Ce que je dirai, c’est que l’ingénierie de ce week-end a été informée par ce à quoi ils tiennent, et l’approche OpenXR-d’abord que nous avons adoptée s’aligne avec la direction que prend leur plateforme.

L’intégration de documents stratégiques dans le dépôt de gouvernance ce week-end capture les notes de réunion et là où l’ingénierie y répond. Le dépôt est privé ; la réponse d’ingénierie est publique. Les PR qui ont atterri ce week-end sont l’artefact public.

Ce que cela signifie et ne signifie pas

Ce que cela signifie : un développeur qui veut construire une expérience AR sur Raku peut cibler le Quest aujourd’hui et atteindre des utilisateurs aujourd’hui. L’expérience ne sera pas optimale pour les facteurs de forme de lunettes AR, parce que le Quest n’est pas des lunettes AR. L’expérience sera un aperçu viable de ce à quoi ressemblera l’AR, et l’utilisateur peut réellement porter le matériel.

Ce que cela ne signifie pas : Raku est « un moteur Quest » maintenant. Raku est un runtime AR multiplateforme qui se trouve aussi tourner sur le Quest. Le même moteur tournera sur des lunettes AR quand des lunettes AR sortiront dans le facteur de forme que nous optimisons. Le Quest est l’une de plusieurs cibles, pas la cible.

Ce que cela ne signifie pas : nous forkons le moteur pour le Quest. Chaque pièce spécifique au Quest se trouve derrière la couche OpenXR ou le drapeau de fonctionnalité Horizon OS. Si un développeur construit une expérience qui tourne sur le Quest aujourd’hui, la même définition d’expérience .raku se chargera sur des lunettes AR demain sans aucun changement de code au-dessus de la frontière du SDK.

Ce que je veux que les partenaires et bâtisseurs retiennent de ceci

Si vous êtes chez Meta et que vous lisez ceci : l’ingénierie de ce week-end répond à la conversation. Nous voulons être un développeur sérieux d’expériences AR ciblant Quest en 2026. Le travail OpenXR est la fondation. Les prochaines étapes sont pour nous.

Si vous êtes un développeur Quest expérimenté qui réfléchit à ce que Raku ajoute par-dessus le développement Horizon OS natif : la réponse est la couche de runtime IA et la portabilité multiplateforme. Le système nerveux IA qui vit à l’intérieur du moteur sur l’étape de simulation est le même que vous vous déployiez sur Quest ou sur du matériel de classe lunettes. Construire sur Raku maintenant vous amène aux lunettes AR gratuitement quand les lunettes AR arriveront.

Si vous êtes un développeur AR indépendant qui réfléchit à quel moteur construire : le Quest est l’appareil que vos utilisateurs possèdent aujourd’hui. Le support Quest de Raku est réel depuis ce samedi. La liaison Unity et la liaison Unreal fonctionnent toutes deux contre lui. Le démarrage rapide du SDK inclut la configuration Quest.

Cent dix-huit commits sur le week-end. Samedi soir, le moteur a une nouvelle plateforme cible. Retour à la construction demain matin.