Meta Quest ist jetzt ein Zielgerät

Käufliche AR-Brillen gibt es noch nicht — aber Millionen Menschen besitzen bereits ein Headset. RakuAI erreicht Ihre Nutzer jetzt dort, wo sie sind, mit einer Erlebnisdefinition, die direkt zu Brillen weiterträgt, sobald diese verfügbar sind.

Ein Partnertreffen Ende letzter Woche machte den nächsten Schritt offensichtlich. Das eventuelle Produktziel für Raku sind AR-Brillen. Das Produktziel heute sind ebenfalls AR-Brillen, aber die AR-Brillen, auf denen wir ausliefern wollen, existieren noch nicht in einer Form, die irgendjemand kaufen kann. Diese Lücke ist real. Sie ist auch frustrierend, denn die Erlebnisse, die wir Menschen auf dieser Engine ermöglichen wollen, sollten nicht auf Hardware warten müssen.

Dieses Wochenende haben wir die Lücke auf andere Weise geschlossen. Die Runtime läuft jetzt auf Meta-Quest-Headsets mit Horizon OS, im Passthrough-AR-Modus, über die OpenXR-Schicht, die Meta freigibt. Die Quest ist nicht der Formfaktor, für den wir letztlich optimieren. Es ist der Formfaktor, den die Leute schon besitzen.

Was gelandet ist

Drei Runtime-PRs und dazu passende SDK-Teile:

• OpenXR/Quest-VR-Integration mit Stereo-Rendering und 6DoF-Tracking
• Passthrough-AR-Modus für Meta Quest mit Composition Layers und Alpha-Blending
• Horizon-OS-Berechtigungsdokumentation für Quest-Passthrough-AR

Das SDK bekam die entsprechende Arbeit: C-Samples für Quest VR erweitert mit plattformadaptiver Runtime-Auswahl, umfassende Meta-Quest-(Horizon-OS-)Dokumentation für die OpenXR-Integration, Quest-VR-Sample-Unterstützung und CI-Validierung sowie ein Meta-Quest-Passthrough-AR-Dokumentationsdurchgang mit Plattformvergleich.

Auf der Governance-Seite kam Epic #190: Horizon OS (Meta Quest) OpenXR Support, plus Referenzdokumentation für die Integration. Der Strategiedokumente-PR (#193 im Governance-Repo) integrierte Kontext aus einem Partnertreffen früher in der Woche.

Warum Quest, warum jetzt

Zwei Gründe.

Die Quest ist gerade die größte installierte Basis im Spatial Computing. Wenn Sie wollen, dass eine ernsthafte AR-Erfahrung 2026 ein bedeutsames Publikum erreicht, ist die Quest das Gerät, das dieses Publikum bereits besitzt. Für das Gerät zu bauen, das sie haben, lässt die Engine sich mit echten Nutzern beweisen, bevor Hardware der Brillenklasse in Konsumentenmaßstab ausliefert. Das Richtige ist, die Nutzer dort zu treffen, wo sie sind.

Die OpenXR-Runtime von Quest ist eine echte Implementierung, keine halbe Spezifikation. Das zählt mehr, als man ihm oft zugesteht. Meta hat stark in OpenXR-Konformität investiert, in Passthrough-AR über XR_FB_passthrough, in foveiertes Rendering über XR_FB_foveation und in Hand-Tracking über XR_EXT_hand_tracking. Die Erweiterungen, die die Quest freigibt, sind dieselben Erweiterungen, die unsere Runtime seit zwei Wochen ernsthaft konsumiert. Die Integration war nicht kostenlos, aber deutlich günstiger, als sie es gegen ein weniger konformes OpenXR-Ziel gewesen wäre.

Was der Passthrough-AR-Modus tatsächlich tut

Die Quest ist ein VR-first-Gerät mit einem aufgesetzten Passthrough-AR-Modus. Das klingt nach einem Kompromiss, und in mancher Hinsicht ist es das auch. In anderer Hinsicht ist es ein erzwungener Rahmen, der AR auf der Quest disziplinierter macht, als es sonst wäre.

Der Composition-Layer-Manager, den wir vor zwei Wochen für allgemeines OpenXR eingebaut haben, ist das, was Passthrough sauber funktionieren lässt. Der Kamera-Passthrough kommt als eine Composition-Layer herein. Der virtuelle Inhalt unserer Runtime kommt als eine weitere herein, mit Alpha-Blending, sodass sich der virtuelle Inhalt korrekt gegen die reale Welt zusammensetzt, die der Nutzer durch die Kameras sieht. System-Overlays (Metas eigene UI bei Bedarf) kommen als dritte Layer in der richtigen Z-Reihenfolge herein.

Das Alpha-Blending ist der subtile Teil. Prämultiplizierte Alpha-Werte sind wichtig. Beleuchtungsschätzung ist wichtig. Der virtuelle Inhalt muss farblich gegen die Umgebungsbeleuchtung korrigiert werden, die die Kameras zeigen, sonst schwebt er unglaubwürdig. Die Beleuchtungsschätzungsarbeit, die vor drei Wochen in der Runtime landete, ist das, was den AR-Modus wie AR aussehen lässt statt wie einen flachen Aufkleber auf einem Videostream.

Die Frage der Horizon-OS-Berechtigungen

Metas Berechtigungsmodell für Passthrough-AR ist involvierter, als die meisten Entwickler es von Desktop-VR gewohnt sind. Die Runtime muss die richtigen Manifest-Einträge deklarieren, die richtigen Laufzeitberechtigungen anfragen und elegant degradieren, wenn ein Nutzer eine davon verweigert. Der Dokumentations-PR, der Mitte der Woche landete (#149 in der Runtime, plus entsprechende SDK-Docs), soll verhindern, dass Entwickler, die auf Raku bauen, in die Berechtigungsklippe laufen, die Meta aus Datenschutzgründen um den Kamerastream herum gebaut hat.

Die Datenschutzgeschichte ist wichtig. Die Kameras einer Quest sehen das Zuhause des Nutzers. Alles, was die Engine mit diesem Kamerastream macht, muss Opt-in, transparent und auditierbar sein. Das gilt für Quest. Es wird noch mehr gelten für AR-Brillen, die Menschen in der Öffentlichkeit tragen. Die Arbeit, die wir dieses Wochenende leisten, um Quests Berechtigungsmodell korrekt zu behandeln, trägt zu jedem noch sensibleren Einsatz später weiter.

Der Kontext des Partnertreffens

Eine Anmerkung zum Governance-Docs-PR. Metas Developer-Relations-Team und ich sprechen miteinander. Ich werde den Inhalt dieser Gespräche nicht im öffentlichen Blog zusammenfassen, weil die Gespräche noch laufen. Was ich sagen kann: Das Engineering dieses Wochenendes wurde von dem informiert, was ihnen wichtig ist, und der OpenXR-first-Ansatz, den wir verfolgen, passt zu der Richtung, in die ihre Plattform geht.

Die Integration der Strategiedokumente im Governance-Repo dieses Wochenende erfasst die Meeting-Notizen und wo das Engineering darauf reagiert. Das Repo ist privat; die Engineering-Antwort ist öffentlich. Die PRs, die dieses Wochenende landeten, sind das öffentliche Artefakt.

Was das bedeutet und was nicht

Was es bedeutet: Ein Entwickler, der eine AR-Erfahrung auf Raku bauen will, kann die Quest heute anvisieren und heute Nutzer erreichen. Die Erfahrung wird für Formfaktoren von AR-Brillen nicht optimal sein, weil die Quest keine AR-Brille ist. Die Erfahrung wird eine tragfähige Vorschau darauf sein, wie sich AR anfühlen wird, und der Nutzer kann die Hardware tatsächlich tragen.

Was es nicht bedeutet: Raku ist jetzt „eine Quest-Engine”. Raku ist eine plattformübergreifende AR-Runtime, die zufällig auch auf der Quest läuft. Dieselbe Engine wird auf AR-Brillen laufen, wenn AR-Brillen in dem Formfaktor ausliefern, für den wir optimieren. Die Quest ist eines von mehreren Zielen, nicht das Ziel.

Was es nicht bedeutet: Wir forken die Engine für die Quest. Jeder Quest-spezifische Teil sitzt hinter der OpenXR-Schicht oder dem Horizon-OS-Feature-Flag. Wenn ein Entwickler eine Erfahrung baut, die heute auf der Quest läuft, wird dieselbe .raku-Erlebnisdefinition morgen auf AR-Brillen laden, ohne jede Codeänderung oberhalb der SDK-Grenze.

Was ich Partnern und Buildern mitgeben möchte

Wenn Sie bei Meta sind und das hier lesen: Das Engineering dieses Wochenendes reagiert auf das Gespräch. Wir wollen ein ernsthafter Entwickler quest-gerichteter AR-Erfahrungen 2026 sein. Die OpenXR-Arbeit ist das Fundament. Die nächsten Schritte liegen bei uns.

Wenn Sie ein erfahrener Quest-Entwickler sind, der überlegt, was Raku über native Horizon-OS-Entwicklung hinaus hinzufügt: Die Antwort ist die KI-Runtime-Schicht und die plattformübergreifende Portabilität. Das KI-Nervensystem, das im Simulationsschritt in der Engine lebt, ist dasselbe, egal ob Sie zur Quest oder zu Hardware der Brillenklasse ausliefern. Auf Raku zu bauen bringt Sie jetzt kostenlos zu AR-Brillen, sobald AR-Brillen ankommen.

Wenn Sie ein Indie-AR-Entwickler sind und überlegen, mit welcher Engine Sie bauen sollen: Die Quest ist das Gerät, das Ihre Nutzer heute besitzen. Rakus Quest-Unterstützung ist real, Stand diesem Samstag. Sowohl das Unity-Binding als auch das Unreal-Binding funktionieren dagegen. Der SDK-Schnellstart enthält das Quest-Setup.

Hundertachtzehn Commits über das Wochenende. Samstagabend hat die Engine eine neue Zielplattform. Zurück ans Bauen morgen früh.