1.1 O continuum

• VR (realidade virtual): o mundo real é substituído; você está "dentro" de um ambiente sintético.
• AR (realidade aumentada): conteúdo virtual sobreposto ao mundo real (do celular ao headset).
• MR (realidade mista): o virtual interage com o real — objetos virtuais são tapados por móveis reais, pousam na sua mesa, respondem à geometria da sala.
• XR / spatial computing: guarda-chuva para tudo isso. "Spatial computing" é o termo que a Apple popularizou; na prática, sinônimo de XR com foco em passthrough e UI espacial.
• Milgram & Kishino descreveram isso como um continuum realidade↔virtualidade — não caixas separadas.

Esta apostila complementa a apostila Realidade Aumentada (que foca em AR mobile e conceitos) com UI espacial, WebXR e o estado de 2026 (headsets de MR, óculos, o ecossistema de dev).

1.2 3DoF × 6DoF

• 3DoF (3 graus de liberdade): rastreia só a rotação da cabeça (olhar em volta). Cardboard, headsets antigos, alguns óculos. Você não pode se mover no mundo virtual.
• 6DoF: rotação e translação (andar, agachar, inclinar). O padrão dos headsets atuais (Quest, Vision Pro). Habilita presença e interação real.
• Controllers e mãos também são 3DoF ou 6DoF.

1.3 Os dispositivos (panorama 2026)

1.4 Onde vale — e onde é hype

• Vale hoje: treinamento e simulação (soldagem, procedimentos, segurança), revisão de design 3D (arquitetura, produto, cenografia), telepresença/colaboração 3D, manutenção e campo com AR (instruções sobrepostas), saúde (reabilitação, exposição terapêutica), varejo "veja na sua sala" (AR de móvel/produto), educação imersiva.
• Ainda hype / não vale: substituir o monitor para trabalho de escritório o dia todo (conforto, resolução, fadiga), "metaverso social" de massa, reuniões genéricas que uma chamada de vídeo resolve melhor, qualquer coisa que force o headset onde uma tela 2D é superior.
• A pergunta: este problema se beneficia de escala real, profundidade, presença no espaço ou sobreposição ao mundo? Se não, é uma tela.

2.1 Cybersickness (enjoo)

• Causa principal: conflito sensorial — seus olhos veem movimento que o seu ouvido interno (sistema vestibular) não sente. É o oposto do enjoo de carro (onde você sente movimento e não vê).
• Vection: a sensação ilusória de auto-movimento induzida pela visão. Locomoção virtual, câmeras que se movem sozinhas, aceleração e rotação são os grandes vilões.
• Latência motion-to-photon alta (você move a cabeça e a imagem demora a acompanhar) causa enjoo direto — por isso o headset tem que manter o frame rate.

2.2 Frame rate é um requisito de saúde

• Alvos: 72–90 Hz mínimo, 90–120 Hz ideal. Abaixo disso, judder e desconforto.
• Não pode "cair" — uma queda momentânea já basta para enjoar. Melhor reduzir qualidade visual do que perder frames.
• Técnicas do sistema: reprojection / timewarp / spacewarp (o headset reprojeta o último frame para a nova pose da cabeça enquanto o app renderiza) — ajuda, mas não substitui um app que roda no ritmo.

2.3 Locomoção confortável

Ofereça opções e deixe o usuário escolher; assuma o preset mais confortável por padrão.

2.4 Fadiga física

• "Gorilla arm": manter os braços erguidos para interagir cansa rápido. Coloque alvos na zona ergonômica (abaixo da linha dos olhos, perto do corpo), permita interação sentado, use ray + pinch (mão baixa) em vez de direct touch para conteúdo distante.
• Peso do headset e pontos de pressão → sessões curtas; não projete tarefas de 2 horas.
• Vergência–acomodação: os olhos convergem para a distância virtual mas focam na tela do headset — desconforto em uso prolongado, sobretudo com conteúdo muito perto. Mantenha a UI a ~1–2 m.

2.5 Segurança

• Guardian / boundary: o limite do espaço físico; nunca force o usuário a andar até a borda; alerte ao se aproximar.
• Consciência do entorno: em VR total, avise sobre obstáculos; em MR/passthrough, o usuário vê a sala.
• Epilepsia fotossensível: nada de flashes > 3×/s (WCAG 2.3.1 vale aqui também), cuidado com estroboscópio e alto contraste piscante.
• Avisos de conteúdo (altura, movimento intenso), pausas sugeridas, "reset da vista".

3.1 Os modelos de input

3.2 Regras de alvo e alcance

• Alvos grandes — o tamanho angular é o que importa (um alvo pequeno mas perto pode ser fácil; grande mas longe, difícil). Mínimos generosos (equivalente a 60+ px numa tela, mais em XR).
• Espaçamento entre alvos maior que em 2D — a mira treme.
• Zona ergonômica: conteúdo interativo entre a cintura e a linha dos olhos, a ~0.5–2 m; nada que exija olhar muito para cima ou esticar.
• Não coloque UI presa perto demais dos olhos nem exija movimentos amplos e repetidos.

3.3 Feedback

• Sem o toque físico de um botão, o feedback tem que vir por outros canais: destaque visual no hover/olhar, som curto no "clique", haptics no controller, animação de "pressionado".
• Estados claros: focado (olhar/hover), pressionado, desabilitado — como em 2D (ver Motion de Interface), mas mais fortes.
• Confirme ações à distância — o usuário precisa saber que "pegou".

3.4 Gestos do sistema vs do app

• Cada plataforma reserva gestos (abrir o menu do sistema, recentralizar, home) — não os sobrescreva.
• Prefira os padrões da plataforma (pinça no visionOS, o botão do menu no Quest) a inventar gestos próprios que o usuário terá que aprender e que colidem com o sistema.

4.1 Janelas, volumes, espaços

O modelo do visionOS é um bom vocabulário geral:

• Window — um painel 2D flutuante (basicamente uma tela de app no espaço). A maior parte da produtividade vive aqui; nem tudo precisa ser 3D.
• Volume — uma caixa 3D delimitada com conteúdo tridimensional (um modelo, um jogo de tabuleiro), que convive com outros apps.
• Immersive space — o app assume o ambiente todo (parcial "mixed" ou total "full"); use com moderação, para experiências que merecem tomar o espaço.
• Regra: comece com uma Window; suba para Volume/Immersive só quando a profundidade e o espaço são o valor.

4.2 Âncoras: onde o conteúdo "mora"

Head-locked é a armadilha nº 1 de quem vem do 2D: "vou colar o dashboard na frente do usuário". Não — deixe o mundo segurar a UI.

4.3 Profundidade, escala e legibilidade

• Distância: UI de leitura a ~1–2 m; conteúdo manipulável ao alcance do braço.
• Tamanho angular é o que decide legibilidade — texto e alvos devem manter o mesmo tamanho aparente a qualquer distância (escalar com a distância).
• Profundidade com moderação: um pouco de separação em Z ajuda a hierarquia (o modal à frente do conteúdo); camadas demais confundem e forçam refoco constante.
• Paralaxe sutil dá "solidez"; exagerada, enjoa.

4.4 Tipografia, cor e material em XR

• Passthrough muda tudo: o fundo é a sala real do usuário — imprevisível, com qualquer cor e luz atrás. Não dá para garantir contraste com um fundo. Solução: painéis com material próprio (o "glass" do visionOS: translúcido, com blur e realce), sombra/vinheta atrás do texto, e testar em ambientes claros e escuros.
• Texto: maior e mais pesado que em tela; evitar fontes finas; alto contraste dentro do painel; ver Tipografia e Cor.
• Material translúcido ("glassmorphism" de verdade aqui): deixa a sala "vazar" e integra a UI ao ambiente — mas cuide da legibilidade (o mesmo problema de contraste da apostila Cor).
• Não use branco puro em VR total (ofusca) nem preto puro em passthrough (some).

4.5 Ergonomia de layout

• Layouts levemente curvos (côncavos para o usuário) mantêm tudo à mesma distância e ângulo de leitura.
• Largura limitada — não faça o usuário girar a cabeça 120° para ler; o "campo de conforto" é ~±30–40° horizontais.
• Coloque o essencial na altura dos olhos; o secundário abaixo; quase nada acima.

5.1 A WebXR Device API

• Sessão: navigator.xr.requestSession('immersive-vr' | 'immersive-ar'), precedida de isSessionSupported e disparada por um gesto do usuário (um botão "Entrar em VR/AR").
• Reference spaces: o sistema de coordenadas — local, local-floor (origem no chão), bounded-floor (com o boundary), unbounded, viewer (head-locked).
• Loop de render: session.requestAnimationFrame (não o do window) → frame.getViewerPose → renderizar uma vez por view (um olho cada), no XRWebGLLayer.
• Input: session.inputSources (controllers/mãos), eventos select/squeeze, frame.getPose para posição.
• Módulos AR: hit test (raycast contra o mundo real — pousar objetos), anchors (fixar no mundo), depth sensing (occlusion), light estimation, DOM overlay (HTML 2D sobre a cena AR no mobile), hand input (25 juntas por mão).
• Suporte: Quest (browser), Android Chrome (AR); no visionOS o Safari suporta WebXR (com particularidades). Sempre feature-detect.

5.2 Os frameworks

5.3 Progressive enhancement

• O site deve funcionar sem XR — a versão 2D/3D na tela é o baseline; "Entrar em AR/VR" é um aprimoramento para quem tem o dispositivo.
• Feature-detect navigator.xr e o modo de sessão; esconder o botão se não suportado.
• Para "ver em AR" de um produto, <model-viewer> já entrega isso em iOS e Android sem sessão WebXR.

// esqueleto WebXR com three.js
renderer.xr.enabled = true;
document.body.appendChild(ARButton.createButton(renderer, {
  requiredFeatures: ['hit-test'], optionalFeatures: ['dom-overlay', 'anchors']
}));
renderer.setAnimationLoop((t, frame) => {
  if (frame) {
    // obter hit test, atualizar retículo, etc.
  }
  renderer.render(scene, camera);
});

6.1 Formatos

• glTF / GLB — o "JPEG do 3D" para a web e para a maioria das engines: malha, PBR, animação, num arquivo. GLB é a versão binária (tudo empacotado).
• USDZ — o formato do Quick Look da Apple (iOS/visionOS); gere-o a partir do glTF no pipeline (Reality Converter, ferramentas de linha de comando).
• USD (não zipado) e Reality Composer Pro — a base de cenas no visionOS/RealityKit.
• Autoria: Blender → exportar glTF (ver Blender 3D); ou DCCs profissionais.

6.2 Pipeline de otimização

• Geometria: reduzir polígonos (decimate/retopo), Draco ou Meshopt para comprimir malhas, LODs (versões mais leves ao longe).
• Texturas: KTX2 / Basis Universal (compressão GPU, transcodifica no device) em vez de PNG/JPEG gigantes; resolução adequada (2K é muito para um objeto pequeno); atlas para reduzir binds.
• Materiais: menos materiais únicos = menos draw calls; instancing para objetos repetidos.
• Iluminação: baked (assada em lightmaps) sempre que possível — luz dinâmica é cara; poucos lights em tempo real.
• Ferramentas: gltf-transform, gltfpack, o gltf-report; no R3F, gltfjsx.

6.3 Os orçamentos

• Foveated rendering: renderiza em alta resolução só onde o olho olha (fixed ou eye-tracked) — ganho grande de fill rate; o sistema oferece, você habilita.
• Occlusion culling, frustum culling, static batching — o básico de tempo real, aqui obrigatório (ver Unity, Computação Gráfica & Three.js).
• Teste no dispositivo-alvo, com o profiler dele (OVR Metrics / RenderDoc / Instruments). O desktop mente.

7.1 visionOS (Apple)

• SwiftUI para as janelas/volumes 2D-3D + RealityKit (o motor 3D/física/áudio) + ARKit (rastreamento de mãos, planos, world) + Reality Composer Pro (autoria de cenas, materiais Shader Graph, USD).
• Modelo de espaço: Shared Space (seu app convive com outros — janelas e volumes) vs Full Space (seu app sozinho, acesso a mais recursos como ARKit completo).
• Interação: olhar + pinça pelo sistema (o app recebe eventos de "tap" já resolvidos); privacidade forte (o app não vê a câmera crua nem para onde você olha, exceto o alvo já resolvido).
• Apps de iPad/iPhone rodam "de graça" como janelas; a experiência espacial exige código visionOS.

7.2 Meta / Quest

• Unity ou Unreal + o Meta XR SDK (Interaction SDK, Passthrough, Scene, Movement/body tracking) — o caminho da maioria dos apps/jogos.
• Meta Spatial SDK — para apps 2D/panel-first em Kotlin/Android, sem Unity.
• WebXR pelo browser do Quest (bom alcance, sem loja).
• Recursos: passthrough colorido, Scene understanding (a malha e os planos da sua sala), Shared Spatial Anchors, colocalização.

7.3 Android XR

• Plataforma XR baseada em Android (Google + Samsung), com Jetpack XR (Compose para XR, Scene) e ARCore; integração com Gemini.
• Suporta OpenXR e Unity/Unreal; e apps Android 2D como janelas.

7.4 OpenXR e o caminho multiplataforma

• OpenXR (Khronos) é o padrão comum de runtime XR — Quest, Android XR, PC VR, e outros o implementam. Programar contra OpenXR (ou uma engine que o usa) dá portabilidade.
• Unity (com o XR Interaction Toolkit / OpenXR plugin) e Unreal são o caminho para publicar no maior número de headsets com uma base de código. Ver Unity.
• visionOS fica um pouco à parte — o suporte a Unity existe (via PolySpatial) mas o "melhor" de visionOS é nativo (SwiftUI + RealityKit).

7.5 Nativo × Unity × WebXR

8.1 Scene understanding

• Plane detection (chão, paredes, mesas) e mesh / scene reconstruction (a geometria da sala) — o app pode usar o ambiente: pousar objetos em superfícies reais, fazer coisas quicarem no chão, colar UI numa parede.
• No visionOS e no Quest, o usuário faz uma varredura da sala (ou o sistema mantém um modelo); o app pede permissão para acessá-lo.

8.2 Occlusion

• Objetos reais devem tapar os virtuais (sua mão passa na frente do robô virtual, o sofá esconde a bola). Sem isso, o virtual "flutua" e quebra a ilusão de MR.
• Feito com o depth do dispositivo (ou a malha da sala) escrito no depth buffer antes de renderizar o virtual. WebXR tem o módulo depth-sensing; engines nativas têm occlusion pronta.
• Hand occlusion específico (as mãos tapando a UI) é quase sempre esperado.

8.3 Anchors persistentes e compartilhadas

• Persistent / world anchor: você deixa um objeto na sua mesa, fecha o app, volta amanhã — está lá. O sistema salva a âncora (localmente ou na nuvem).
• Shared spatial anchor: duas pessoas na mesma sala veem o mesmo objeto no mesmo lugar — colocalização. Base de jogos e revisão de design multiusuário presenciais.
• Cross-device/cross-platform é o difícil (cada sistema tem seu serviço de anchor na nuvem — Meta, ARCore Cloud Anchors, Apple).

8.4 Multiusuário

• Remoto: pessoas em lugares diferentes num espaço compartilhado — SharePlay (visionOS, via FaceTime), sessões próprias (netcode — ver Unity), avatares (Spatial Personas no visionOS, avatares Meta).
• Colocalizado: mesma sala, shared anchors + sincronização de estado por rede local.
• Sincronizar posição de objetos e ações entre clientes é o mesmo problema de rede de jogos (autoridade, interpolação, latência).

8.5 Passthrough, câmera e privacidade

• visionOS: o app não tem acesso à imagem crua das câmeras nem ao mapa detalhado da sala nem ao ponto exato do olhar (recebe só o alvo já resolvido de uma interação). Isso limita alguns usos (CV custom) mas é uma escolha de privacidade forte.
• Quest: acesso a passthrough e à malha da sala com permissão (e recentemente uma API de câmera para desenvolvedores, com restrições).
• Projete assumindo o modelo mais restritivo se quiser portabilidade.

8.6 Spatial audio

• Som posicionado no espaço 3D com HRTF (o cérebro localiza a fonte), oclusão e reverberação acústica da sala (um som atrás da parede soa abafado), e ambisonics para ambientes.
• É um enorme reforço de presença e de direção de atenção (um som à esquerda faz você virar). Ver IA de Voz e Áudio e Produção e Edição Musical.

9.1 Casos que realmente pegam

• Treinamento e simulação — soldagem, procedimentos médicos, segurança, atendimento; ROI claro (menos material, menos risco, repetível, medível).
• Design review 3D — arquitetura, produto, automotivo, cenografia: ver em escala 1:1 antes de fabricar.
• Campo e manutenção com AR — instruções sobrepostas ao equipamento, assistência remota "veja o que eu vejo".
• Telepresença / colaboração 3D em times distribuídos.
• Saúde — reabilitação motora, terapia de exposição, distração para dor.
• Varejo — "veja o móvel/tênis/maquiagem" via AR mobile (o de maior alcance, e o mais fácil — model-viewer).
• Não pega (hoje): substituir o desktop para trabalho o dia todo, redes sociais imersivas de massa, reuniões genéricas.

9.2 Distribuição e custo

• Lojas: App Store (visionOS), Meta Horizon Store, Google Play (Android XR) — revisão, comissão, alcance limitado à base instalada.
• Web: WebXR não precisa de loja — link, atualização instantânea, menor alcance de recursos.
• Empresarial: distribuição gerenciada (MDM), device management de uma frota de headsets.
• Custo: produção 3D é cara (modelagem, otimização, teste em device); um app espacial "sério" custa bem mais que um app 2D equivalente. A base instalada ainda é pequena — dimensione a aposta.

9.3 QA em XR

• Conforto é caso de teste: sessões longas com várias pessoas, medir enjoo, fadiga, "gorilla arm".
• Matriz de dispositivos: Quest 2/3/3S, Vision Pro, PC VR, Android XR — cada um com hardware, campo de visão, input e performance diferentes.
• Ambientes reais: sala clara/escura, pequena/grande, bagunçada; iluminação para hand/eye tracking.
• Frame rate monitorado o tempo todo; profilers do device.
• Testar de pé e sentado, com pessoas de alturas diferentes, canhotas, com óculos.

9.4 Acessibilidade em XR

• Modos de conforto (Módulo 2) como acessibilidade: teleporte, snap turn, vignette, "reduzir movimento" — essenciais, não opcionais.
• Sentado / altura ajustável: nunca exigir ficar de pé, agachar, ou alcançar longe; oferecer recentralizar e ajustar a altura da UI.
• Sem as mãos: navegação por olhar + dwell, por voz, por cabeça — para quem não pode usar as mãos.
• Legendas espaciais para áudio/fala (posicionadas, legíveis, não presas na cara); audiodescrição.
• Baixa visão: magnificação do sistema, alto contraste, tamanho de texto; daltonismo (não só cor — ver Cor).
• Audição: não depender só de spatial audio para informação crítica; sinal visual redundante.
• visionOS, Quest e Android XR têm APIs de acessibilidade (VoiceOver espacial, etc.) — use-as.

9.5 Privacidade extrema

• Eye tracking revela atenção, intenção, estado cognitivo, e é biométrico — dado altíssimamente sensível. Por isso o visionOS não entrega o olhar ao app. Se você tiver acesso (pesquisa, alguns modos), trate como dado de saúde: consentimento explícito, minimização, não usar para publicidade/perfilamento.
• Mapa da casa: a geometria da sala, os móveis, as pessoas ao redor — não exfiltre, não guarde além do necessário.
• Expressões faciais / corpo (para avatares): idem — biométrico.
• Câmera de passthrough: pode capturar terceiros sem consentimento; APIs restringem por isso.
• Aplique os princípios da apostila Governança de IA, Ética & EU AI Act e as regras de privacidade (LGPD/GDPR) — e note que XR gera categorias de dado que a lei ainda está alcançando.

9.6 Uso responsável

• Pausas, avisos de tempo de uso, limites para menores.
• Não force VR onde uma tela resolve — respeite o custo físico e cognitivo do usuário.
• Cuidado com desconforto psicológico (alturas, espaços fechados, conteúdo intenso) — avisos e opções de sair.

10.1 Onde XR pesa

• XR / spatial designer: a experiência espacial — conforto, interação, UI, playtesting.
• WebXR developer: experiências 3D/AR na web (e-commerce, marketing, ferramentas, protótipos).
• Unity/Unreal XR developer: apps e jogos para Quest/PC VR/Android XR.
• visionOS developer: Swift + RealityKit para o ecossistema Apple.
• 3D technical artist: pipeline de assets, otimização, shaders para o orçamento de XR.
• Setores: treinamento corporativo, arquitetura/AEC, automotivo, saúde, defesa, varejo, entretenimento.

10.2 Roadmap de estudo (6–8 semanas)

10.3 Banco de perguntas (com a resposta que aprova)

10.4 Projetos de portfólio que geram entrevista

1. Experiência WebXR (âncora): uma cena AR com hit test (pousar objeto numa superfície), occlusion (depth), um persistent anchor e spatial audio — three.js/R3F, testada no Quest e no Android, com fallback 2D.
2. App nativo "hello spatial": um visionOS (SwiftUI + RealityKit) ou Quest (Unity + Meta XR SDK) com uma janela + um volume 3D + interação por mãos/olhar, e o raciocínio de conforto.
3. Visualizador de produto AR: model-viewer + glTF otimizado + USDZ, integrado numa página de e-commerce fake, com o pipeline de asset documentado (Blender → Draco/KTX2 → USDZ).
4. Estudo de conforto: a mesma cena com locomoção suave vs teleporte vs vignette, com relato de teste com 5 pessoas.
5. UI espacial: um app 2D redesenhado para o espaço, com os três tipos de âncora demonstrados e a justificativa de cada escolha.

10.5 Fontes para continuar

• WebXR: a especificação do W3C Immersive Web e immersiveweb.dev (samples); docs de three.js WebXR, @react-three/xr, Babylon.js WebXR, A-Frame; model-viewer (modelviewer.dev).
• visionOS: Apple — Human Interface Guidelines (seção de spatial), "Design for spatial user interfaces", as sessões da WWDC sobre visionOS/RealityKit; a documentação de RealityKit e ARKit.
• Meta: as Meta Quest design guidelines e a documentação do Meta XR SDK / Interaction SDK / Spatial SDK; o blog de desenvolvedores da Meta.
• Android XR: a documentação do Jetpack XR e ARCore; OpenXR (Khronos).
• Fundacional: The VR Book (Jason Jerald); palestras de Michael Abrash; o continuum de Milgram & Kishino; guias de AR do Google.
• Nesta trilha: Realidade Aumentada, Computação Gráfica & Three.js, 3D em Tempo Real & Motion Graphics para Web, Unity, Blender 3D, Motion de Interface, Cor, Tipografia, Acessibilidade Digital & WCAG, IA de Voz e Áudio.