Construit pour recevoir des directives de ChatGPT, Claude et Gemini

L'ère du « ce produit tourne sur le modèle de tel fournisseur » est courte. RakuAI est construit pour que n'importe quel modèle - ChatGPT, Claude, Gemini, ou le vôtre - puisse piloter une expérience AR en temps réel. Apportez le meilleur modèle. Le runtime est prêt.

La plupart des moteurs de jeu qui s’intègrent avec un LLM cloud aujourd’hui le font de la façon à laquelle on s’attendrait. Un modèle est boulonné dans l’éditeur comme un panneau de chat. Vous tapez dans le panneau de chat. Le panneau écrit du contenu ou du code. Le runtime, qui n’a aucune idée que tout cela s’est produit, exécute l’artefact résultant plus tard.

Ce n’est pas ce que fait Raku. Raku est construit pour recevoir des directives d’un LLM cloud comme une préoccupation de runtime, pas une commodité de création. Le travail de ce week-end l’a rendu explicite.

Ce qui a atterri

Cent dix-huit commits à travers le runtime ce week-end. Les pièces marquantes :

• Un XRAssistantService qui câble les réponses du LLM cloud dans le pipeline vocal comme une fonctionnalité de runtime de premier ordre
• Un rendu fovéal par suivi oculaire avec optimisation de performance multi-profils
• Un fournisseur OpenXR XR_EXT_eye_gaze_interaction
• Suivi des mains et reconnaissance gestuelle pour le runtime XR
• Suivi du corps entier avec un squelette à 71 articulations
• Détection de fixation et minuteurs de maintien dans l’infrastructure de suivi oculaire
• Passthrough haute résolution, détection de profondeur, et estimation d’éclairage
• Un pipeline de rendu déporté Wi-Fi 7 avec un serveur hôte et surveillance de latence
• Un canal delta à faible latence pour la synchro de pose et d’état AR multijoueur en temps réel
• Service d’ancrage sous-millimétrique pour Android XR
• Pont de capteurs ARCore pour les appareils Android sans la pile Android XR
• Un compositeur HUD multi-couches et une API de superposition
• Exemples AR Surface Demo et Room Visualizer pour la compréhension de scène

Quelques-unes de ces choses sont des points marquants qui valent la peine d’être discutés. Le pipeline de rendu déporté Wi-Fi 7 en est une. Le XRAssistantService en est une autre. Toutes deux sont façonnées pour le partenariat.

Le XRAssistantService et à quoi il sert réellement

Le XRAssistantService est la pièce d’ingénierie appâtant les partenariats la plus propre que nous ayons livrée à ce jour. Sa forme :

Le runtime a un pipeline vocal. L’utilisateur parle. La reconnaissance vocale tourne localement sur l’appareil avec une faible latence. Le texte est diffusé dans le service assistant. Le service assistant remet le texte à un LLM cloud. Le LLM cloud renvoie un flux de tokens qui représentent l’intention : ce que l’expérience AR devrait faire ensuite étant donné ce que l’utilisateur a dit. Le runtime analyse ce flux et le transforme en actions runtime en vol. La synthèse vocale pour la réponse est aussi diffusée en flux.

La pièce que je veux que les bâtisseurs et les laboratoires remarquent est que le LLM n’est pas invoqué une fois par tour de l’utilisateur. Le pipeline vocal peut continuer à diffuser des tokens vers le modèle pendant un tour (avec le bon support de backend), et le modèle peut continuer à produire de l’intention sur laquelle le runtime agit en continu. C’est ce que signifie réellement « recevoir des directives d’un LLM cloud comme une préoccupation de runtime ». Ce n’est pas un chatbot collé dans une expérience AR. C’est le runtime traitant le flux d’intention du modèle comme une entrée de contrôle de la même priorité que le regard de l’utilisateur.

L’interface est agnostique au modèle par conception. ChatGPT peut piloter cela. Claude peut piloter cela. Gemini peut piloter cela. Un petit modèle sur l’appareil peut piloter cela. Tout ce qui produit un flux de tokens d’intention conforme au protocole du service assistant peut piloter cela. La pièce que nous avons construite ce week-end est la couche d’intégration entre un tel modèle et le reste du runtime.

Si vous êtes dans l’un de ces laboratoires et que vous lisez ceci : c’est l’intégration dont nous voulons vous parler. Nous ne voulons pas un partenariat spécial où votre modèle est le seul modèle auquel le moteur peut parler. Nous voulons que votre modèle soit le meilleur modèle auquel le moteur peut parler, parce que l’intégration est ouverte et l’expérience que produit votre modèle sera meilleure que l’expérience que produit le modèle de quiconque d’autre.

Le pipeline de rendu déporté Wi-Fi 7

C’est l’autre pièce façonnée pour le partenariat. Les lunettes AR ont une enveloppe thermique. L’enveloppe thermique est petite. L’enveloppe de calcul à l’intérieur de cette enveloppe thermique est plus petite que ce que certaines expériences veulent rendre. La réponse traditionnelle est de faire des compromis sur l’expérience. La réponse Wi-Fi 7 est de rendre une partie de la frame sur une boîte de calcul en tethering (un téléphone, un beltpack, un ordinateur de bureau dans la même pièce) et de diffuser le résultat.

Ce week-end, le pipeline de rendu déporté a atterri de bout en bout. Le serveur hôte tourne n’importe où. Le runtime sur les lunettes parle à l’hôte via Wi-Fi 7. La latence de frame est surveillée et le runtime peut dégrader avec grâce vers le rendu local quand la liaison a un raté, ce qui arrivera.

Pourquoi cela compte pour les partenaires : cela signifie qu’un partenaire matériel n’a pas à mettre un GPU de classe bureau dans les lunettes pour livrer une expérience de classe bureau. Le calcul peut être là où le calcul est le moins cher. La liaison est ce qui compte. Nous construisons le runtime autour de la liaison.

L’échafaudage OpenXR

Un bon nombre des commits de ce week-end étaient au service de la conformité OpenXR. XR_EXT_eye_gaze_interaction. Suivi des mains. Schémas de fournisseur pour ARKit et ARCore. La raison pour laquelle OpenXR compte dans cette base de code est que c’est la couche à laquelle nous voulons que ce moteur soit portable à travers les partenaires matériels. Si un partenaire matériel livre un runtime conforme OpenXR, ce moteur peut se déployer dessus. Les interfaces que nous construisons ce mois-ci sont délibérément du côté des standards plutôt que du côté spécifique au fournisseur, parce que c’est ainsi que le moteur reste neutre.

Honnête sur ce qui n’est pas terminé

Quelques choses ont atterri ce week-end en tant que WIP (travail en cours). La PR de suivi des mains spécifiquement est encore câblée de façon incomplète. Il y a une erreur de liaison PoseStabilizer que nous corrigeons dans un suivi. Le suivi oculaire a la détection de fixation mais l’intégration du minuteur de maintien avec la couche application n’est pas terminée. Le suivi du corps entier est en place mais les pièces de reconnaissance gestuelle ont encore besoin de plus d’exemples.

Je veux être clair là-dessus parce que le schéma du travail de développement piloté par agents est qu’une grande quantité de WIP atterrit la même semaine, et le WIP est explicitement nommé dans les titres de PR. Si vous lisez le journal de commits de ce week-end et voyez « [WIP] » à quelques endroits, c’est voulu. Les livrables complets se rassemblent au cours des deux prochaines semaines.

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

Si vous êtes un laboratoire IA construisant le prochain grand modèle et que vous vous souciez d’un runtime AR qui traite la sortie de votre modèle comme une entrée de contrôle sur l’étape de simulation, parlez-moi. La couche d’intégration XRAssistantService se déploie dans ce moteur en novembre 2025 et sera une interface stable sur laquelle se brancher d’ici la fin de l’année.

Si vous êtes un partenaire matériel construisant des lunettes AR avec du Wi-Fi 7 embarqué et une histoire de calcul externe, le pipeline de rendu déporté est exactement la charge de travail pour laquelle votre matériel a été construit. Le runtime est prêt pour cela.

Si vous êtes un développeur qui réfléchit aux types d’expériences que ce moteur vous permettra de construire, la réponse commence à être visible dans le journal de commits. Des expériences AR pilotées par la voix qui répondent à l’utilisateur en milieu de phrase sont réalisables. L’AR multijoueur en temps réel avec ancrage sous-millimétrique est réalisable. Le calcul dont vous avez besoin pour l’un ou l’autre vit sur les lunettes ou sur le tether, selon ce dont votre expérience a besoin.

Cent dix-huit commits, gros week-end. Le moteur a l’air différent dimanche soir de ce qu’il était quand l’ordinateur portable s’est ouvert samedi.