Meta Quest ahora es un objetivo

Las gafas de RA que puedas comprar todavía no existen, pero millones de personas ya tienen un visor. RakuAI ahora encuentra a tus usuarios donde están, con una única definición de experiencia que se traslada directamente a las gafas cuando lleguen.

Una reunión con un socio a finales de la semana pasada hizo obvio el siguiente movimiento. El objetivo de producto final para Raku son las gafas de RA. El objetivo de producto de hoy también son las gafas de RA, pero las gafas de RA sobre las que queremos lanzar todavía no existen en una forma que nadie pueda comprar. Esa brecha es real. También es frustrante, porque las experiencias que queremos que la gente tenga en este motor no deberían tener que esperar al hardware.

Este fin de semana cerramos la brecha de otra manera. El runtime ahora corre en visores Meta Quest con Horizon OS, en modo RA con passthrough, a través de la capa OpenXR que expone Meta. El Quest no es el factor de forma para el que en última instancia estamos optimizando. Es el factor de forma que la gente ya tiene.

Qué se completó

Tres PRs del runtime y las piezas correspondientes del SDK:

• Integración de OpenXR/Quest VR con renderizado estéreo y seguimiento 6DoF
• Modo RA con passthrough para Meta Quest con capas de composición y mezcla alfa
• Documentación de permisos de Horizon OS para RA con passthrough en Quest

El SDK recibió el trabajo correspondiente: ejemplos en C extendidos para Quest VR con selección de runtime adaptable a la plataforma, documentación exhaustiva de Meta Quest (Horizon OS) para la integración de OpenXR, soporte de ejemplos de Quest VR y validación de CI, y un repaso de documentación de RA con passthrough en Meta Quest con comparación de plataformas.

El lado de gobernanza recibió el Epic #190: Soporte OpenXR de Horizon OS (Meta Quest), más documentación de referencia para la integración. El PR de documentos estratégicos (#193 en el repositorio de gobernanza) integró contexto de una reunión con un socio a principios de semana.

Por qué Quest, por qué ahora

Dos razones.

El Quest es la base instalada más grande en computación espacial en este momento. Si quieres que una experiencia de RA seria llegue a una audiencia significativa en 2026, el Quest es el dispositivo que esa audiencia ya tiene. Construir para el dispositivo que tienen le permite al motor probarse a sí mismo con usuarios reales antes de que el hardware de clase gafas se lance a escala de consumo. Lo correcto es encontrar a los usuarios donde están.

El runtime OpenXR de Quest es una implementación real, no una especificación a medias. Esto importa más de lo que la gente le reconoce. Meta ha invertido mucho en la conformidad con OpenXR, en RA con passthrough a través de XR_FB_passthrough, en renderizado foveado a través de XR_FB_foveation, y en seguimiento de manos a través de XR_EXT_hand_tracking. Las extensiones que expone el Quest son las mismas extensiones que nuestro runtime empezó a consumir en serio hace dos semanas. La integración no fue gratis, pero fue mucho menos costosa de lo que habría sido contra un objetivo OpenXR menos conforme.

Lo que realmente hace el modo RA con passthrough

El Quest es un dispositivo VR-primero con un modo RA con passthrough atornillado encima. Eso suena a una concesión, y en algunos aspectos lo es. En otros aspectos es un elemento forzador que hace que la RA en el Quest sea más disciplinada de lo que sería de otro modo.

El gestor de capas de composición que completamos hace dos semanas para OpenXR en general es lo que hace que el passthrough funcione limpiamente. El passthrough de la cámara llega como una capa de composición. El contenido virtual de nuestro runtime llega como otra, con mezcla alfa para que el contenido virtual componga correctamente contra el mundo real que el usuario puede ver a través de las cámaras. Las superposiciones del sistema (la propia interfaz de Meta cuando se invoca) llegan como una tercera capa en el orden z correcto.

La mezcla alfa es la parte sutil. El alfa premultiplicado importa. La estimación de iluminación importa. El contenido virtual tiene que corregirse en color contra la iluminación ambiental que muestran las cámaras, o flota de forma poco convincente. El trabajo de estimación de iluminación que se completó hace tres semanas en el runtime es lo que hace que el modo RA se vea como RA en lugar de como una pegatina plana encima de una transmisión de video.

La cuestión de los permisos de Horizon OS

El modelo de permisos de Meta para la RA con passthrough es más elaborado de lo que la mayoría de los desarrolladores esperan viniendo de VR de escritorio. El runtime tiene que declarar las entradas de manifiesto correctas, solicitar los permisos de runtime correctos y degradarse con elegancia cuando un usuario deniega alguno de ellos. El PR de documentación que se completó a mitad de semana (#149 en el runtime, más la documentación correspondiente del SDK) tiene la intención de evitar que los desarrolladores que construyen sobre Raku se topen con el precipicio de permisos que Meta ha construido alrededor de la transmisión de la cámara por motivos de privacidad.

La historia de privacidad importa. Las cámaras de un Quest están viendo la casa del usuario. Cualquier cosa que el motor haga con esa transmisión de la cámara tiene que ser opt-in, transparente y auditable. Eso es cierto en Quest. Será más cierto todavía en las gafas de RA que la gente lleve en público. El trabajo que estamos haciendo este fin de semana para gestionar correctamente el modelo de permisos del Quest se trasladará a cada despliegue más sensible más adelante.

El contexto de la reunión con el socio

Una nota sobre el PR de documentos de gobernanza. El equipo de relaciones con desarrolladores de Meta y yo hemos estado hablando. No voy a resumir el contenido de esas conversaciones en el blog público, porque las conversaciones todavía están en curso. Lo que sí diré es que la ingeniería de este fin de semana estuvo informada por lo que a ellos les importa, y el enfoque de OpenXR primero que hemos estado tomando se alinea con hacia dónde va su plataforma.

La integración de documentos estratégicos en el repositorio de gobernanza este fin de semana recoge las notas de la reunión y dónde está respondiendo la ingeniería a ellas. El repositorio es privado; la respuesta de ingeniería es pública. Los PRs que se completaron este fin de semana son el artefacto público.

Lo que esto significa y lo que no significa

Lo que significa: un desarrollador que quiera construir una experiencia de RA sobre Raku puede apuntar al Quest hoy y llegar a usuarios hoy. La experiencia no será óptima para factores de forma de gafas de RA, porque el Quest no son gafas de RA. La experiencia será una vista previa viable de cómo se sentirá la RA, y el usuario puede realmente ponerse el hardware.

Lo que no significa: Raku es “un motor de Quest” ahora. Raku es un runtime de RA multiplataforma que además resulta que corre en el Quest. El mismo motor correrá en gafas de RA cuando las gafas de RA se lancen en el factor de forma para el que estamos optimizando. El Quest es uno de varios objetivos, no el objetivo.

Lo que no significa: estamos bifurcando el motor para el Quest. Cada pieza específica de Quest se sitúa detrás de la capa OpenXR o del flag de función de Horizon OS. Si un desarrollador construye una experiencia que corre en el Quest hoy, la misma definición de experiencia .raku se cargará en gafas de RA mañana sin ningún cambio de código por encima del límite del SDK.

Lo que quiero que los socios y constructores se lleven de esto

Si estás en Meta y estás leyendo esto: la ingeniería de este fin de semana responde a la conversación. Queremos ser un desarrollador serio de experiencias de RA orientadas a Quest en 2026. El trabajo de OpenXR es la base. Los siguientes pasos dependen de nosotros.

Si eres un desarrollador experimentado de Quest pensando en qué añade Raku sobre el desarrollo nativo de Horizon OS: la respuesta es la capa de runtime de IA y la portabilidad multiplataforma. El sistema nervioso de IA que vive dentro del motor en el paso de simulación es el mismo tanto si lanzas al Quest como al hardware de clase gafas. Construir sobre Raku ahora te lleva a las gafas de RA de forma gratuita cuando las gafas de RA lleguen.

Si eres un desarrollador de RA independiente pensando en con qué motor construir: el Quest es el dispositivo que tus usuarios ya tienen. El soporte de Quest de Raku es real a partir de este sábado. Tanto el binding de Unity como el de Unreal funcionan contra él. La guía de inicio rápido del SDK incluye la configuración de Quest.

Ciento dieciocho commits a lo largo del fin de semana. Sábado por la noche, el motor tiene una nueva plataforma objetivo. De vuelta a construir mañana por la mañana.