Série: Aprendendo a Programar com IA

Meta Quest Agora É um Alvo

O que o suporte ao Quest exigiu: OpenXR no Horizon OS, passthrough, estéreo, 6DoF.

Meta Quest Agora É um Alvo RA por passthrough através de camadas de composição OpenXR Camada 0 — passthrough de câmera Camada 1 — conteúdo virtual (alfa) Camada 2 — overlays do sistema Quest · Horizon OS · 6DoF XR_FB_passthrough · XR_FB_foveation · XR_EXT_hand_tracking
O dispositivo que as pessoas possuem hoje, sobre o padrão que leva aos óculos de amanhã.

Óculos de RA que você pode comprar ainda não existem — mas milhões de pessoas já possuem um headset. A RakuAI agora encontra seus usuários onde eles estão, com uma definição de experiência que leva direto aos óculos quando eles forem lançados.

Uma reunião com parceiro no fim da semana passada tornou o próximo movimento óbvio. O alvo eventual de produto para a Raku são óculos de RA. O alvo de produto hoje também são óculos de RA, mas os óculos de RA nos quais queremos lançar ainda não existem em uma forma que alguém possa comprar. Essa lacuna é real. Também é frustrante, porque as experiências que queremos que as pessoas tenham neste motor não deveriam ter que esperar pelo hardware.

Neste fim de semana fechamos a lacuna de outro jeito. O runtime agora roda em headsets Meta Quest com Horizon OS, em modo de RA por passthrough, através da camada OpenXR que a Meta expõe. O Quest não é o formato para o qual estamos finalmente otimizando. É o formato que as pessoas já possuem.

O que entrou

Três PRs de runtime e as peças correspondentes de SDK:

  • Integração OpenXR/Quest VR com renderização estéreo e rastreamento 6DoF
  • Modo de RA por passthrough para Meta Quest com camadas de composição e alpha blending
  • Documentação de permissões do Horizon OS para RA por passthrough no Quest

O SDK ganhou o trabalho correspondente: exemplos em C estendidos para Quest VR com seleção de runtime adaptativa por plataforma, documentação abrangente do Meta Quest (Horizon OS) para integração OpenXR, suporte a exemplos Quest VR e validação em CI, e uma passada de documentação de RA por passthrough do Meta Quest com comparação de plataforma.

O lado da governança ganhou o Epic #190: Suporte OpenXR ao Horizon OS (Meta Quest), além de documentação de referência para a integração. O PR de documentos estratégicos (#193 no repositório de governança) integrou contexto de uma reunião com parceiro no início da semana.

Por que Quest, por que agora

Duas razões.

O Quest é a maior base instalada em computação espacial agora mesmo. Se você quer que uma experiência séria de RA alcance uma audiência significativa em 2026, o Quest é o dispositivo que essa audiência já possui. Construir para o dispositivo que eles têm permite que o motor prove seu valor com usuários reais antes de hardware da classe óculos ser lançado em escala de consumidor. A coisa certa a fazer é encontrar os usuários onde eles estão.

O runtime OpenXR do Quest é uma implementação real, não uma meia-especificação. Isso importa mais do que as pessoas dão crédito. A Meta investiu pesado em conformidade OpenXR, em RA por passthrough através do XR_FB_passthrough, em renderização foveada através do XR_FB_foveation, e em rastreamento de mãos através do XR_EXT_hand_tracking. As extensões que o Quest expõe são as mesmas extensões que nosso runtime começou a consumir a sério há duas semanas. A integração não foi de graça, mas foi bem menos custosa do que teria sido contra um alvo OpenXR menos conformante.

O que o modo de RA por passthrough de fato faz

O Quest é um dispositivo primariamente de VR com um modo de RA por passthrough pendurado em cima. Isso soa como um meio-termo, e em alguns aspectos é. Em outros aspectos é uma função forçadora que torna a RA no Quest mais disciplinada do que seria de outra forma.

O gerenciador de camadas de composição que entregamos há duas semanas para OpenXR geral é o que faz o passthrough funcionar de forma limpa. O passthrough de câmera vem como uma camada de composição. O conteúdo virtual do nosso runtime vem como outra, com alpha blending para que o conteúdo virtual componha corretamente contra o mundo real que o usuário consegue ver através das câmeras. Overlays do sistema (a própria UI da Meta quando invocada) vêm como uma terceira camada na ordem-z correta.

O alpha blending é a parte sutil. Alfa pré-multiplicado importa. Estimativa de iluminação importa. O conteúdo virtual tem que ser corrigido em cor contra a iluminação ambiente que as câmeras estão mostrando, ou ele flutua de forma pouco convincente. O trabalho de estimativa de iluminação que entrou três semanas atrás no runtime é o que faz o modo de RA parecer RA em vez de um adesivo plano em cima de um feed de vídeo.

A questão de permissões do Horizon OS

O modelo de permissões da Meta para RA por passthrough é mais envolvido do que a maioria dos desenvolvedores espera vindo do VR de desktop. O runtime tem que declarar as entradas corretas de manifesto, solicitar as permissões corretas de runtime, e degradar graciosamente quando um usuário nega uma delas. O PR de documentação que entrou no meio da semana (#149 no runtime, mais a documentação correspondente do SDK) tem a intenção de manter os desenvolvedores construindo na Raku longe do precipício de permissões que a Meta construiu ao redor do feed de câmera por razões de privacidade.

A questão de privacidade importa. As câmeras de um Quest estão vendo a casa do usuário. Qualquer coisa que o motor faça com esse feed de câmera tem que ser opt-in, transparente, e auditável. Isso é verdade no Quest. Vai ser ainda mais verdade em óculos de RA que as pessoas usam em público. O trabalho que estamos fazendo neste fim de semana para lidar corretamente com o modelo de permissões do Quest vai carregar para frente em todo deployment mais sensível depois.

O contexto da reunião com o parceiro

Uma nota sobre o PR de documentos de governança. O time de relações com desenvolvedores da Meta e eu estamos conversando. Não vou resumir o conteúdo dessas conversas no blog público, porque as conversas ainda estão em andamento. O que vou dizer é que a engenharia deste fim de semana foi informada pelo que eles se importam, e a abordagem OpenXR-primeiro que temos adotado se alinha com para onde a plataforma deles está indo.

A integração de documento estratégico no repositório de governança neste fim de semana captura as notas da reunião e onde a engenharia está respondendo a elas. O repositório é privado; a resposta de engenharia é pública. Os PRs que entraram neste fim de semana são o artefato público.

O que isso significa e o que não significa

O que significa: um desenvolvedor que quer construir uma experiência de RA na Raku pode ter o Quest como alvo hoje e alcançar usuários hoje. A experiência não vai ser ótima para formatos de óculos de RA, porque o Quest não são óculos de RA. A experiência vai ser um preview viável de como a RA vai parecer, e o usuário pode de fato usar o hardware.

O que não significa: a Raku não é “um motor de Quest” agora. A Raku é um runtime de RA multiplataforma que por acaso também roda no Quest. O mesmo motor vai rodar em óculos de RA quando óculos de RA forem lançados no formato para o qual estamos otimizando. O Quest é um de vários alvos, não o alvo.

O que não significa: não estamos bifurcando o motor para o Quest. Toda peça específica do Quest fica atrás da camada OpenXR ou da feature flag do Horizon OS. Se um desenvolvedor constrói uma experiência que roda no Quest hoje, a mesma definição de experiência .raku vai carregar em óculos de RA amanhã sem nenhuma mudança de código acima da fronteira do SDK.

O que eu quero que parceiros e construtores tirem disso

Se você está na Meta e está lendo isso: a engenharia deste fim de semana é responsiva à conversa. Queremos ser um desenvolvedor sério de experiências de RA voltadas ao Quest em 2026. O trabalho de OpenXR é a fundação. Os próximos passos são nossos.

Se você é um desenvolvedor experiente de Quest pensando no que a Raku adiciona em cima do desenvolvimento nativo do Horizon OS: a resposta é a camada de runtime de IA e a portabilidade multiplataforma. O sistema nervoso de IA que vive dentro do motor na etapa de simulação é o mesmo, quer você lance para o Quest quer para hardware da classe óculos. Construir na Raku agora te leva a óculos de RA de graça quando os óculos de RA chegarem.

Se você é um desenvolvedor independente de RA pensando em qual motor construir: o Quest é o dispositivo que seus usuários possuem hoje. O suporte da Raku ao Quest é real a partir deste sábado. O binding de Unity e o binding de Unreal funcionam ambos contra ele. O guia rápido do SDK inclui configuração para Quest.

Cento e dezoito commits ao longo do fim de semana. Sábado à noite, o motor tem uma nova plataforma-alvo. De volta a construir amanhã de manhã.

Lance no headset que eles já têm. Alcance os óculos que eles vão usar.

O suporte da Raku ao Quest é real hoje — bindings de Unity e Unreal, fundação OpenXR, camada de runtime de IA. Uma definição de experiência, todo alvo. Comece a construir para o futuro espacial agora.

← Todos os posts