flowchart LR
R["Ambiente real puro<br/>nenhuma imagem sintetica"] --> A["O real domina<br/>e recebe acrescimos<br/>construidos"]
A --> B["O construido domina<br/>e recebe pedacos<br/>do real"]
B --> S["Ambiente sintetico puro<br/>nada do comodo<br/>onde voce esta"]
A -.- N1["A engrenagem apoiada<br/>na sua mesa"]
B -.- N2["A oficina inteira,<br/>com suas maos reais<br/>capturadas por camera"]
1 O contínuo entre o sintético e o real
Duas linhas de configuração separam um mundo inteiro de um objeto pousado sobre a sua mesa — e a diferença não está na qualidade da imagem.
Este capítulo não desenha nada na tela, e isso é de propósito. O que você leva daqui é um vocabulário que classifica sistemas por decisão técnica, três grandezas que a conversa cotidiana embaralha, e uma delimitação de domínio escrita de um jeito que possa ser desmentida depois. Leia com um sistema qualquer em mente — o jogo de celular que espalha bichos na calçada, o painel projetado no vidro do carro — e vá classificando enquanto lê.
1.1 Rótulo não classifica aparelho
Em 1994, dois engenheiros desistiram de uma briga trocando a pergunta — e é essa troca que organiza tudo o que vem depois.
Em 1994, Paul Milgram, engenheiro da Universidade de Toronto, publicou com Fumio Kishino uma taxonomia de visores. A área estava travada numa discussão que não andava. Cada aparelho novo reacendia a mesma briga: aquilo era realidade virtual ou não era? A saída dos dois foi elegante e quase preguiçosa. Eles pararam de fazer a pergunta.
Repare onde estava o problema. Os aparelhos eram inocentes; o formato da pergunta condenava qualquer resposta. Toda pergunta do tipo “isto é X?” exige uma fronteira, e ninguém conseguia desenhar uma que não jogasse casos absurdos para o lado errado. É a velha armadilha do monte de areia: em que grão exato ele deixa de ser um monte?
Os dois trocaram aquilo por uma pergunta de grau. Quanto de mundo real este sistema mostra? Quanto de mundo construído? Perguntas de grau admitem medida, e medida admite comparação entre coisas que ninguém precisou batizar de antemão — inclusive as que ainda nem existiam. Daí saiu um eixo contínuo, com o ambiente real puro numa ponta e o ambiente sintético puro na outra.
Entre as pontas ficam duas faixas, separadas por quem domina. Numa o real domina e recebe acréscimos; na outra o construído domina e recebe pedaços do real. O celular que mostra a sua mesa com uma engrenagem apoiada nela cai na primeira. O visor que exibe uma oficina inteira, mas desenha as suas mãos capturadas por câmera, cai na segunda. Nenhum dos dois precisou de comitê para caber ali.
Pense num sistema que você usa. Ele acrescenta coisas ao cômodo onde você está, ou substitui o cômodo inteiro? E, se acrescenta, o que ele acrescenta fica preso a algum ponto do mundo, ou apenas flutua na sua frente? Guarde a resposta: ela vai ser cobrada duas seções adiante.
Toda ferramenta boa tem um recorte, e esconder o recorte transforma ferramenta em superstição. O contínuo mede uma coisa só: a relação entre o que é exibido e o mundo de quem observa. Ele não mede preço, não mede nitidez, não mede conforto. E não mede o quanto a pessoa acredita no que vê. Essa é outra grandeza, com outro nome. Confundir as duas é o defeito conceitual mais caro da área.
1.1.1 Três palavras que dizem duas coisas
Agora a parte incômoda de qualquer capítulo de vocabulário. Três palavras centrais circulam com dois significados cada, e as leituras não são compatíveis. A primeira é realidade mista. Na taxonomia de 1994 ela nomeia a faixa inteira entre os dois extremos, o que faz da realidade aumentada uma sub-região dela. Uma contém a outra; irmãs elas não são.
Depois veio a leitura comercial, e ela não é absurda. Ali realidade mista virou nome de categoria de produto. São sistemas em que objetos sintéticos encostam no mundo real, são tapados por ele e respondem à geometria da sala. O problema não é a segunda leitura existir. É as duas circularem no mesmo texto sem ninguém avisar qual está valendo. Imagina um requisito escrito assim: o sistema deve suportar realidade mista. Na primeira leitura, quase tudo cumpre. Na segunda, foram pedidos reconhecimento de superfícies, oclusão por profundidade e colisão com a sala. Meses de diferença numa expressão só.
A segunda palavra é imersivo, que virou elogio. “Uma experiência imersiva” costuma significar apenas que a experiência foi envolvente. Imersão, no uso técnico, é grandeza do sistema, medida em graus e em milissegundos. A distância entre os dois usos é a distância entre uma medida e um adjetivo. A terceira palavra está no nome da área. No uso comum, virtual quer dizer falso. No uso técnico, quer dizer gerado por computação, sem implicar falsidade alguma.
A saída não é inventar palavra nova — vocabulário privado isola o texto e não convence ninguém de fora. É escrever o critério no lugar do rótulo, sempre que o rótulo puder ser lido de duas formas. Em vez de “suporta realidade mista”, escreva o que o sistema faz: reconhece superfícies, oclui objetos sintéticos atrás de objetos reais, mantém a âncora enquanto o observador caminha. Ninguém interpreta essas três frases de dois jeitos, e todas são testáveis.
1.2 Geometria, tipos e olhos novos
Nada aqui exige experiência prévia com visores — exige três hábitos que você provavelmente já tem.
Ninguém precisa ter construído um ambiente tridimensional antes de abrir estas páginas. O pressuposto é mais modesto e cabe em três hábitos. O primeiro é geometria de transformações: você já compôs translação, rotação e escala, e já viu uma hierarquia de objetos em que mover o pai move o filho. O que muda aqui é a exigência, não o conteúdo. A mesma matriz que compunha uma imagem passa a ser recalculada dezenas de vezes por segundo, contra a posição de uma cabeça que se move sozinha.
O segundo é modelagem de domínio com tipos. Você já escreveu uma estrutura que descreve um conceito e já deixou o compilador recusar um valor impossível. É exatamente essa habilidade que a primeira tarefa cobra, e ela chega antes de qualquer desenho na tela. Parece uma inversão estranha para uma área que vive de imagem. Não é: o que não couber num tipo vai caber num comentário, e comentário não recusa nada.
O terceiro é a atenção a quem usa. Você já viu alguém tropeçar numa interface que parecia óbvia para quem a construiu? Aqui isso pesa mais do que em qualquer tela plana. Interface tridimensional falha em lugares que o autor já não enxerga, porque ele decorou o caminho, e nenhuma releitura de código substitui um par de olhos novos diante da cena.
O que você não precisa ter é equipamento. O regime que exibe a cena numa janela comum roda em qualquer computador, e é nele que a maior parte das decisões é tomada. O visor confirma escolhas; ele raramente as descobre.
1.3 Três verbos e uma escada
A pergunta que substitui o rótulo é rude e cabe em oito palavras: o que este sistema fez com o cômodo?
Existe uma pergunta melhor do que “isto é realidade aumentada?”. Ela é grosseira e produtiva: o que este sistema fez com o cômodo onde a pessoa está? Só há três respostas. Ele substituiu o cômodo, preservou-o, ou exibiu algo sem tocá-lo. A classificação sai desses três verbos, e nenhum depende de marca, de preço ou do nome que o fabricante deu à linha.
Comece pelo caso fácil. Um visor opaco no rosto substitui o cômodo: você não vê a sala, vê o que o sistema desenhou no lugar dela. A promessa embutida aí é pesada. Se o mundo inteiro é responsabilidade do sistema, o chão precisa estar na altura certa. E a imagem precisa acompanhar a cabeça sem atraso perceptível.
O segundo caso preserva o cômodo, e parece mais modesto do que é. A sala continua visível e o sistema deposita coisas sobre ela. O objeto depositado tem de ficar onde foi posto, e errar isso é visível a olho nu. A engrenagem desliza sobre a mesa, e ninguém precisa de instrumento para ver o erro. O terceiro caso não toca no cômodo — uma janela numa tela mostra um ambiente construído, e a sala continua sendo a sala.
Não precisar acertar escala corporal nem registro não significa valer menos, e essa confusão custa caro. Esse terceiro regime roda em qualquer máquina comum e é para onde tudo degrada quando o aparelho não oferece coisa melhor. Um ambiente que só existe com o visor no rosto deixa de existir para a maioria das pessoas. Aqui ele é o caso base, e não a sobra.
1.3.1 Cada degrau custa mais mundo real
Todo ambiente tridimensional tem uma origem, o ponto onde as coordenadas valem zero. Parece detalhe de implementação sem consequência, e é a decisão mais reveladora de todas, porque expõe contra o que o mundo construído está preso. Numa janela na tela a origem é arbitrária: quem modelou a cena a fixou onde quis, e não existe nada externo com que discordar.
Num visor opaco ela deixa de ser arbitrária. A origem passa a ser o chão do espaço físico onde a pessoa está de pé. O sistema passa a depender de uma medida que não controla. Chão estimado dez centímetros abaixo do real produz bancada alta demais. O corpo percebe o erro antes de a cabeça conseguir explicá-lo. No terceiro caso, a origem vem de uma superfície escolhida dentro do ambiente: a mesa, o tampo do balcão, o chão à sua frente.
flowchart TB
Q{"O que o sistema fez<br/>com o comodo onde<br/>a pessoa esta?"}
Q -->|"substituiu"| S["O chao e responsabilidade sua<br/>origem presa ao piso medido"]
Q -->|"preservou"| P["O objeto tem de ficar<br/>onde foi posto<br/>origem numa superficie real"]
Q -->|"nao tocou"| E["Janela numa tela<br/>origem arbitraria<br/>nada externo para conferir"]
E --> R0["registro: nenhum"]
S --> R1["registro: parcial<br/>o chao e real, as paredes nao"]
P --> R2["registro: completo<br/>o erro aparece como escorregao"]
Registro é o nome técnico dessa dependência: a relação geométrica entre o que foi desenhado e o mundo físico visível. Leia o desenho de baixo para cima e repare no que cresce a cada degrau: a quantidade de mundo real que o sistema precisa acertar. Qualidade de imagem fica de fora dessa conta. No degrau mais baixo não há registro nenhum, e isso não é defeito — não existe mundo visível contra o qual registrar.
O efeito colateral costuma surpreender quem começa: quanto mais alto o degrau, mais barato fica errar de forma visível. Um ambiente inteiramente construído esconde os próprios erros de posicionamento, porque não há referência externa que os denuncie. Um objeto pousado na mesa não esconde nada. Daí a regra de método que inverte a intuição: construa pelo regime mais fácil, confira pelo mais exigente que o seu equipamento alcançar.
1.4 Por onde a luz do cômodo chega aos olhos
Duas soluções ópticas, contas de latência opostas, e uma delas nunca consegue desenhar preto.
Um sistema que preserva o cômodo tem um problema óptico antes de qualquer problema de software. A luz da sala precisa chegar aos olhos junto com a imagem gerada, e há duas famílias de solução. Numa, a luz real chega direto e a imagem é somada a ela por um espelho semitransparente ou por um guia de onda. É o ver-através óptico. Na outra, câmeras capturam a sala e o sistema compõe a imagem sobre esse vídeo, numa tela opaca.
flowchart TB
Q{"Por onde a luz do<br/>comodo chega aos olhos?"}
Q -->|"direto, somada<br/>por espelho ou guia de onda"| O["Ver-atraves optico"]
Q -->|"por camera, composta<br/>numa tela opaca"| V["Ver-atraves por video"]
O --> O1["mundo sem atraso,<br/>imagem gerada atrasada:<br/>o desencontro aparece"]
O --> O2["soma luz e nunca subtrai:<br/>nao desenha preto,<br/>nao oclui"]
V --> V1["mundo e imagem atrasam<br/>juntos e podem ser coerentes"]
V --> V2["controla cada ponto:<br/>oclui, escurece,<br/>responde pela seguranca"]
Comece pela conta de latência, porque ela é contraintuitiva. No ver-através óptico o mundo real chega instantaneamente, o que soa como vantagem pura. O mundo chega sem atraso e a imagem gerada chega atrasada. O desencontro entre os dois é justamente o que o observador percebe. Quanto melhor a visão do mundo, mais evidente fica o atraso do que foi desenhado sobre ele. No ver-através por vídeo os dois atrasam juntos, e podem atrasar de forma coerente. Em troca, a sala inteira chega aos seus olhos com atraso.
Há uma segunda diferença, e ela é definitiva. O ver-através óptico soma luz e nunca subtrai. Um sistema que só soma luz não consegue desenhar preto nem esconder o que está atrás do objeto virtual. Pense numa engrenagem escura que deveria tapar a mesa. Se o sistema apenas acrescenta luz, a mesa continua visível através dela, e a peça parece um fantasma pousado no ar. O ver-através por vídeo controla cada ponto da imagem final e pode substituir a região onde o objeto está.
Uma pista de campo, com o dedo
Diante de um aparelho que você não conhece, tape uma das câmeras frontais com o dedo. Se a imagem do mundo escurecer, é ver-através por vídeo. Se a sala continuar visível e apenas alguma função de rastreamento degradar, é ver-através óptico.
1.4.1 Quatro sistemas que ninguém vende como realidade virtual
O teste de um vocabulário técnico não é explicar os casos para os quais ele foi feito. É explicar os que ninguém tinha em mente quando ele foi proposto. Pegue quatro sistemas que existem fora de qualquer laboratório. Faça a cada um a mesma pergunta: o que ele fez com o cômodo, e contra o que registra o que exibe?
O painel que projeta informação no vidro de um carro preserva a estrada e soma luz a ela, portanto é ver-através óptico no sentido estrito. E o registro? A velocidade projetada não fica presa a ponto nenhum da estrada; ela flutua no campo de visão, e isso é deliberado. Acabamos de descobrir, com um exemplo banal, que preservar e registrar são decisões independentes.
A projeção que cobre a fachada de um prédio e a faz parecer desmoronar tem registro exigente. Meio metro de escorregão mata a ilusão para a praça inteira. Mas repare em quem observa. Ele está certo para quem olha do ponto de projeção e progressivamente errado para quem se afasta. O terceiro caso é o mais desconcertante: um robô com câmera, controlado à distância, cuja imagem chega a um visor. Você vê um lugar real onde não está, nada ali é sintético, e mesmo assim há rastreamento de cabeça e presença altíssima.
O quarto caso é o mais antigo e o mais instrutivo. Um simulador de voo com cabine física de verdade e paisagem projetada nas janelas: onde ele cai no eixo? A tentação é responder realidade virtual, porque produz presença alta e treina pilotos. Olhe de novo com o critério na mão. A cabine é preservada inteira, incluindo manetes, assentos e o peso do cinto no ombro; o que foi substituído foi apenas a janela.
O sistema preserva o mundo local e substitui o mundo distante, ocupando dois pontos do eixo ao mesmo tempo. Isso não é defeito da taxonomia — ela classifica o que é exibido, e partes diferentes do campo de visão são exibidas de formas diferentes. E deixa uma lição de projeto cara de aprender pelo caminho errado. Reproduzir o mundo é sempre mais caro do que preservar o pedaço dele que já está certo. A cabine física resolve de graça escala, peso, textura e retorno de força.
1.5 Três grandezas que se medem em lugares diferentes
Um objeto grosseiro com o tamanho certo é aceito pelo corpo; um objeto lindíssimo com meio segundo de atraso enjoa em minutos.
A frase acima parece paradoxal e não é. Ela só surpreende quem confunde três coisas distintas. Imersão é propriedade do sistema. Presença é resposta da pessoa. Registro é relação com o mundo físico. Cada uma tem o seu instrumento de medida, e nenhum dos três serve para as outras duas.
flowchart TB
P["A mesma sessao,<br/>tres perguntas diferentes"] --> I["Imersao<br/>onde se mede: no aparelho"]
P --> PR["Presenca<br/>onde se mede: na pessoa"]
P --> RG["Registro<br/>onde se mede: contra o<br/>mundo fisico visivel"]
I --> I2["campo de visao, latencia,<br/>graus de liberdade,<br/>taxa de atualizacao"]
PR --> P2["comportamento observavel:<br/>desviar, hesitar,<br/>estender a mao"]
RG --> R2["o objeto fica onde foi posto<br/>enquanto voce anda em volta"]
Imersão é o que o sistema oferece, e mede-se sem vestir nada. É a extensão em que ele entrega estímulos coerentes e substitui os do ambiente real, descrita por grandezas do próprio equipamento. Campo de visão, latência entre movimento e imagem, graus de liberdade rastreados, taxa de quadros. Repare no que a definição não exige: ela nem sequer menciona um observador humano. Guarde a assimetria numa frase curta: imersão é condição, não resultado.
Presença é a resposta perceptual e comportamental de alguém a um ambiente mediado. Nela, a pessoa age como se estivesse no lugar exibido, apesar de saber que não está. O menor exemplo é físico. Alguém com o visor no rosto estende a mão devagar para tocar algo que não existe, e o braço desacelera perto do objeto. A definição não fala de textura nem de contagem de polígonos.
Presença é o palco acertando escala e tempo; fidelidade é a pintura do cenário, e cenário pintado não segura ninguém no lugar. O que o palco precisa acertar é curto e duro. Escala compatível com o corpo, resposta sem atraso perceptível, coerência entre o que se faz e o que acontece em seguida. Por isso se mede presença observando comportamento, e não perguntando impressão.
A terceira grandeza é a mais restrita, e a restrição é a informação mais útil sobre ela. Registro é a correspondência geométrica entre posição, orientação e escala de um objeto sintético e as do referencial real a que ele foi associado. Avalia-se sempre do ponto de vista de quem observa. Num ambiente que substitui o mundo não há referencial visível, logo não há registro a avaliar. E a palavra escala esconde um detalhe: um objeto na posição certa com o dobro do tamanho está tão errado quanto um deslocado.
1.5.1 A espada de Dâmocles e o cubo de arame
Em 1968, Ivan Sutherland apresentou um visor acoplado à cabeça que ninguém conseguia vestir, de tão pesado. A solução foi pendurá-lo: um braço mecânico articulado, preso ao teto do laboratório, segurava o aparelho sobre quem sentava embaixo. O apelido que a máquina ganhou descreve a cena com precisão — espada de Dâmocles. E o que aquilo desenhava? Arestas de arame flutuando no campo de visão, sem superfície, sem cor, sem sombra.
Mesmo assim, produziu em quem o usou a impressão sólida de estar diante de um objeto tridimensional. Por quê? A explicação decide onde você vai gastar o seu tempo. Um cubo de arame visto de um ângulo fixo é um emaranhado ambíguo de linhas. O mesmo cubo girando com o pescoço deixa de ser ambíguo em menos de um segundo.
O cérebro desfaz a ambiguidade pelo movimento, não pela textura, e esse mecanismo é barato de acionar. Não pede iluminação correta, não pede sombra, não pede contagem alta de polígonos. Pede que a imagem responda ao movimento na hora certa — requisito de tempo, não de aparência. Sutherland acertou escala e resposta ao movimento, errou em quase tudo o mais, e o campo nasceu ali.
Tem ainda um detalhe contado como anedota que é a peça de engenharia mais interessante do conjunto. O braço não servia apenas para segurar peso: também media a posição e a orientação da cabeça de quem estava embaixo. Era rígido, com juntas de geometria conhecida, e sabendo o ângulo de cada junta sabe-se onde está a ponta. Uma peça, dois problemas, nenhum sensor a calibrar.
Isso tem nome hoje: rastreamento por infraestrutura externa. Algo de fora conta ao aparelho onde ele está, e a certeza depende da rigidez desse algo. O braço tinha precisão excelente e liberdade ridícula. Toda escolha de rastreamento troca uma coisa por outra, e aquela trocou movimento por certeza.
Sutherland não parou no braço. O mesmo trabalho descreve um segundo medidor da posição da cabeça, este por ultrassom, sem contato mecânico com o teto. Os dois foram construídos, e os dois foram usados. A comparação entre eles antecipa em meio século uma discussão que a área ainda tem. O rígido acertava mais e prendia mais; o sem contato libertava e errava mais.
Eu diria que o braço envelheceu melhor do que a fama dele sugere, e o motivo é simples: ninguém jamais o viu perder a referência. Ele não perdia porque não procurava. Sensor que não procura não se engana, e a escolha entre os dois arranjos nunca foi sobre qual mede melhor. Foi sobre qual erro se prefere ter.
Falta o detalhe que desmonta a expectativa mais comum sobre 1968. As duas telas minúsculas, uma por olho, não entregavam a imagem direto à vista: o desenho chegava aos olhos refletido em espelhos semitransparentes. E espelho semitransparente deixa passar o que está atrás dele. Quem usava aquele aparelho via as arestas de arame e via a sala do laboratório, ao mesmo tempo, sobrepostas.
Aplique ali o critério dos três verbos. O cômodo continuava visível, o desenho se somava a ele, e a coerência entre os dois dependia de o sistema saber onde estava a cabeça. Somar luz sem nunca subtrair é a definição de ver-através óptico, montada duas seções atrás com aparelhos sessenta anos mais novos. O ancestral do campo inteiro não nasceu no extremo sintético. Nasceu do lado que hoje se chama de aumentado, e a área levou décadas para voltar até lá.
Uma ressalva sobre esses relatos, e ela cobra alguma coisa de quem escreve. Números daquele aparelho, como campo de visão, peso e taxa de atualização, circulam em versões que não batem entre si, e boa parte vem de recontagem, não do trabalho original. Não os repito aqui. Número errado dito com confiança é pior do que número nenhum, e o que o próprio trabalho descreve já basta ao argumento: duas telas, espelhos semitransparentes, dois medidores de posição da cabeça e uma sala inteira servindo de referência.
1.5.2 O que a imagem compra, e o que ela não compra
Separar presença de fidelidade é perigoso quando se leva a ideia longe demais. Ela produz o raciocínio oposto e igualmente errado: que aparência não importa, que textura é vaidade, que o cubo cinza basta. Aparência importa — só não importa para aquilo. Comece pela função mais esquecida, que é o reconhecimento: se a pessoa não distingue a engrenagem grande da pequena, nenhuma quantidade de presença resolve a tarefa.
A segunda função tem nome feio para uma ideia simples: a forma de um objeto sugere o que se pode fazer com ele. Uma alça sugere puxar; um encaixe visível sugere onde a peça entra. A terceira é a que mais interessa daqui em diante. Sombra e oclusão funcionam como evidência de posição, e chamá-las de enfeite sai caro. Um objeto sem sombra flutua, mesmo estando geometricamente no lugar certo. O olho usa o contato com a superfície para confirmar onde a coisa está. Repare no que acabou de acontecer com a tese: no regime que preserva o mundo, parte da aparência vira registro, e ali a separação entre palco e pintura se afrouxa.
flowchart TB
R{"Em que regime<br/>a cena roda?"}
R -->|"janela na tela"| J["Invista em legibilidade:<br/>sem escala corporal,<br/>resta entender o que se ve"]
R -->|"mundo substituido"| V["Invista em resposta ao<br/>movimento e em escala"]
R -->|"mundo preservado"| A["Invista em estabilidade<br/>do registro: tremor destroi<br/>mais que falta de brilho"]
Suponha que você tenha tempo para melhorar uma coisa só. A resposta muda com o regime, e é aqui que a teoria começa a pagar. No que exibe pela janela, invista em legibilidade; no que substitui o mundo, em resposta ao movimento e em escala; no que preserva o mundo, em estabilidade do registro. A resposta certa nunca foi textura, e nunca foi ignorar a aparência. Uma pergunta curta decide o que entra na cena: este detalhe está ajudando a pessoa a entender ou a acreditar?
O antídoto contra a demonstração vistosa. Frederick Brooks passou anos em Chapel Hill pondo químicos para encaixar moléculas com um braço mecânico de retorno de força montado sobre a bancada. Três décadas depois de Sutherland, no balanço de 1999, escreveu que a realidade virtual tinha saído do estágio de quase funcionar para o de mal e mal funcionar. Quem escreveu aquilo trabalhava na área e tinha motivo de sobra para exagerar na direção contrária. Diante de qualquer coisa que funcione na tela, faça a pergunta dele: como o sistema descobriu onde estava o chão?
1.6 O eixo virou um campo que o programa lê
A taxonomia de 1994 acabou virando três valores que a plataforma informa em tempo de execução.
Há um momento em que uma ideia teórica passa a ser algo que um programa consegue ler, e para o contínuo entre o real e o sintético esse momento chegou. A plataforma de realidade estendida do navegador informa, para cada sessão ativa, como o fundo da cena é composto — e são três os valores possíveis. Reconhece a lista? São os três verbos, traduzidos para a linguagem da composição de imagem.
flowchart LR
S["Sessao ativa informa<br/>o modo de composicao<br/>do fundo"] --> OP["opaco"]
S --> AD["aditivo"]
S --> MP["mesclado por<br/>transparencia"]
OP --> V1["substituir:<br/>o chao e responsabilidade sua"]
AD --> V2["preservar somando luz:<br/>proibido depender de preto"]
MP --> V3["preservar compondo video:<br/>pode ocluir, herda o atraso"]
Fundo opaco significa que nada do mundo real chega aos olhos: corresponde a substituir, e carrega a promessa mais pesada dos três. Fundo aditivo é o ver-através óptico escrito como valor de configuração, e vem com uma proibição embutida. Você não pode contar com preto, nem desenhar nada cujo sentido dependa de tapar o que está atrás. Fundo mesclado por transparência é o ver-através por vídeo. Dá para ocluir, escurecer e desenhar preto, e herda-se a responsabilidade sobre o atraso da imagem do mundo.
Os três valores não descrevem aparelhos, e essa distinção é a razão de eles existirem. Descrevem o que está acontecendo naquela sessão, naquele instante, no aparelho em que a página abriu. Isso é o contínuo virando dado, e dado é confrontável, ao contrário de opinião.
Existe aí uma diferença silenciosa entre dois momentos, e confundi-los produz um erro difícil de rastrear. Um sistema pode declarar o que pretende, antes de qualquer execução, e pode ler o que veio, porque com a sessão aberta o valor real está lá. Os dois quase sempre coincidem, e é exatamente quando não coincidem que a informação vale ouro.
Intenção escrita em prosa tem uma propriedade curiosa e perigosa: ela continua parecendo certa meses depois de ter deixado de ser. Nada nela apodrece, nenhum campo fica vermelho, nenhuma verificação falha. Compare com o código, que quebra quando o tipo muda embaixo dele. Daí sai uma decisão que parece exagerada e não é — a delimitação do domínio e a declaração dos regimes são escritas como dados tipados, e não como texto corrido.
1.6.1 Sim, não, e não sei
Escrita a declaração, sobra confrontá-la com o aparelho onde a página está aberta. A pergunta é a mais grossa possível: este aparelho entra neste regime? Ela parece ter duas respostas e tem três. Sim, não, e não sei. A terceira é a que quase todo mundo esquece de tratar, e produz o erro de diagnóstico mais caro desta área.
Um navegador sem a interface de realidade estendida não está dizendo que o aparelho não serve. Está dizendo que não sabe responder. Confundir as duas coisas produz uma afirmação falsa sobre o equipamento, com aparência de dado técnico. É a pior forma de falsidade que um relatório pode conter, porque ninguém desconfia dela.
A mesma página, aberta sem conexão cifrada, não expõe a interface. O aparelho é o mesmo, o programa é o mesmo, e a resposta muda. Quem tratou ausência de resposta como negativa conclui que o equipamento não serve e passa horas procurando defeito no lugar errado.
O agravante é que o relatório errado não quebra nada: ele roda, preenche a tabela e apresenta um resultado plausível. Ninguém abre um chamado por causa de um relatório que funciona, e o defeito só aparece quando alguém tenta explicar por que dois computadores idênticos deram respostas diferentes. Toda vez que você mapear “não consegui obter” para o mesmo valor de “obtive e é negativo”, estará embutindo uma mentira ali. Ela é barata de evitar agora e cara de rastrear depois.
O que um relatório honesto informa
Três estados, nunca dois: o regime é suportado, não é suportado, ou não houve resposta utilizável. O terceiro precisa dizer por que — plataforma sem a interface, ou página fora de contexto seguro. Sem essa distinção, o relatório afirma sobre o aparelho coisas que só valem sobre o ambiente de execução. E vale o ceticismo devido: responder que suporta um regime significa apenas que a sessão pode ser aberta, não que a experiência será boa.
1.7 O ambiente deste livro começa sem desenhar nada
A implementação de referência que acompanha a obra nasce como duas declarações tipadas e uma pergunta feita ao aparelho.
O ambiente que serve de exemplo resolvido ao longo destas páginas chama-se Bancada. É uma oficina de montagem: sobre a bancada estão as peças de um mecanismo e um suporte com encaixes, e quem usa o ambiente monta o mecanismo peça por peça.
Ele foi escolhido pelos critérios da seção do domínio, não por gosto. A tarefa cabe em uma frase, tem estado final observável, exercita selecionar, apanhar, orientar e encaixar, e cabe no alcance dos braços de alguém de pé.
Neste primeiro capítulo, a Bancada não renderiza um único polígono. O que ela entrega é a delimitação do domínio escrita como dado tipado.
src/bancada/dominio/dominio.ts
// ---------------------------------------------------------------------------
// Delimitação do domínio da Bancada.
//
// Este arquivo é a Tarefa 1 do Projeto Integrador escrita como dado, e não como
// texto solto num documento à parte. O motivo é operacional: a delimitação
// precisa ser confrontável com o que o ambiente faz mais adiante, e texto em
// documento não se confronta com nada. Aqui ela é tipada, e o compilador passa
// a cobrar o que antes dependia de alguém reler a ata da reunião.
//
// Nada nesta etapa desenha, carrega malha ou abre sessão. A cena chega quando
// houver grafo de cena; o encaixe, quando houver interação. O que existe agora é
// a descrição do que aquele ambiente terá de suportar.
// ---------------------------------------------------------------------------
/** Identificador de uma peça manipulável da oficina. */
export type PecaId =
| 'corpo'
| 'eixo'
| 'engrenagem-grande'
| 'engrenagem-pequena'
| 'tampa';
/** Identificador de um encaixe do suporte de montagem. */
export type SocketId =
| 'base-do-suporte'
| 'furo-do-eixo'
| 'dente-maior'
| 'dente-menor'
| 'topo';
/**
* Uma peça do mecanismo. `sockets` lista os encaixes que a aceitam — uma peça
* que não serve em lugar nenhum é um objeto decorativo, e a delimitação existe
* justamente para não deixar objeto decorativo entrar como se fosse conteúdo.
*/
export interface Peca {
readonly id: PecaId;
readonly nome: string;
readonly sockets: readonly SocketId[];
}
/**
* A tarefa que o ambiente suporta, enunciada em uma frase, mais o estado que a
* caracteriza concluída. Os dois campos andam juntos de propósito: tarefa sem
* estado final é intenção, e é o que produz a cena bonita e vazia.
*/
export interface TarefaDoAmbiente {
readonly enunciado: string;
readonly estadoFinal: string;
}
export interface Dominio {
readonly nome: string;
readonly descricao: string;
readonly tarefa: TarefaDoAmbiente;
readonly pecas: readonly Peca[];
readonly sockets: readonly SocketId[];
}
export const BANCADA: Dominio = {
nome: 'Bancada',
descricao:
'Uma oficina de montagem: sobre uma bancada de trabalho estão as peças de um ' +
'mecanismo e um suporte com encaixes, e quem usa o ambiente monta o mecanismo ' +
'peça por peça.',
tarefa: {
enunciado:
'Montar o mecanismo encaixando cada peça no suporte, na ordem em que uma ' +
'depende da outra.',
estadoFinal:
'As cinco peças estão encaixadas nos sockets compatíveis, na ordem válida, ' +
'e o mecanismo montado gira.',
},
pecas: [
{ id: 'corpo', nome: 'Corpo', sockets: ['base-do-suporte'] },
{ id: 'eixo', nome: 'Eixo', sockets: ['furo-do-eixo'] },
{ id: 'engrenagem-grande', nome: 'Engrenagem grande', sockets: ['dente-maior'] },
{ id: 'engrenagem-pequena', nome: 'Engrenagem pequena', sockets: ['dente-menor'] },
{ id: 'tampa', nome: 'Tampa', sockets: ['topo'] },
],
sockets: ['base-do-suporte', 'furo-do-eixo', 'dente-maior', 'dente-menor', 'topo'],
};
/**
* Confere que todo socket citado por alguma peça existe no suporte e que todo
* socket do suporte recebe alguma peça. Devolve a lista de inconsistências, que
* é vazia quando o domínio fecha.
*
* O porquê de isto ser código, e não conferência a olho: a delimitação vai ser
* editada muitas vezes ao longo do percurso, e um socket órfão sobrevive a
* qualquer releitura distraída — some só quando alguém tenta encaixar, muitos
* módulos adiante, quando trocar de domínio já custa caro.
*/
export function inconsistenciasDoDominio(dominio: Dominio): string[] {
const declarados: ReadonlySet<SocketId> = new Set(dominio.sockets);
const usados: Set<SocketId> = new Set();
const problemas: string[] = [];
for (const peca of dominio.pecas) {
if (peca.sockets.length === 0) {
problemas.push(`A peça "${peca.nome}" não encaixa em socket nenhum.`);
}
for (const socket of peca.sockets) {
if (!declarados.has(socket)) {
problemas.push(
`A peça "${peca.nome}" cita o socket "${socket}", que o suporte não declara.`,
);
}
usados.add(socket);
}
}
for (const socket of dominio.sockets) {
if (!usados.has(socket)) {
problemas.push(`O socket "${socket}" não recebe peça alguma.`);
}
}
return problemas;
}
Repare no que o compilador passa a cobrar. Os identificadores de peça e de encaixe são tipos de união literal, e um nome inventado é recusado antes de qualquer execução. Note também a função que devolve as inconsistências. Ela é a conferência mecânica da seção do domínio: peça sem encaixe e encaixe sem peça aparecem em milissegundos, sem que ninguém releia a lista.
A segunda declaração registra o que cada regime faz com o mundo de quem observa. Os campos são os mesmos nos três, e essa uniformidade é o próprio argumento do contínuo.
src/bancada/modes/regimes.ts
// ---------------------------------------------------------------------------
// Declaração dos três regimes da Bancada.
//
// Este arquivo é a Tarefa 2 do Projeto Integrador. Ele não abre sessão, não
// renderiza e não detecta nada: declara, regime a regime, o espaço de referência
// pretendido, o que será rastreado e contra o que a cena será registrada.
//
// Escrever isso antes do código tem uma consequência barata e boa: mais adiante,
// quando os regimes existirem de fato, a declaração pode ser confrontada com o
// comportamento observado. Declaração que ninguém guarda não se confronta com
// coisa alguma, e o projeto perde o único registro de qual era a intenção.
// ---------------------------------------------------------------------------
/**
* Os três regimes do ambiente. Os dois primeiros nomes coincidem com os modos de
* sessão da API XR do navegador de propósito — é o que permite perguntar ao
* aparelho, sem tradução no meio, se ele suporta o que declaramos.
*/
export type RegimeId = 'inline' | 'immersive-vr' | 'immersive-ar';
/**
* O que o regime faz com o ambiente de quem observa — a distinção que separa os
* três antes de qualquer detalhe técnico.
*/
export type TratamentoDoMundo =
| 'substitui' // o ambiente sintético toma o lugar do ambiente real
| 'preserva' // o ambiente real permanece visível e recebe o sintético sobre si
| 'exibe'; // o ambiente sintético é mostrado por uma janela, sem tocar o real
/**
* Modo de composição do fundo, tal como a API XR o nomeia. É o ponto em que o
* contínuo entre o real e o sintético deixa de ser desenho de livro e vira um
* valor que a sessão informa: fundo opaco esconde o mundo, os outros dois o
* deixam passar. Só é legível com uma sessão ativa, e por isso aqui ele é o
* valor ESPERADO — a leitura do valor real chega quando houver sessão.
*/
export type ModoDeComposicao = 'opaque' | 'additive' | 'alpha-blend';
export interface Regime {
readonly id: RegimeId;
readonly nome: string;
readonly tratamentoDoMundo: TratamentoDoMundo;
/** Espaço de referência pretendido, no vocabulário da API XR. */
readonly espacoDeReferencia: 'viewer' | 'local' | 'local-floor' | 'unbounded';
/** O que o sistema rastreia neste regime, em uma frase. */
readonly rastreia: string;
/** Contra o que a cena é registrada — a origem do mundo virtual. */
readonly registroContra: string;
readonly composicaoEsperada: ModoDeComposicao;
/** Por que este regime existe no projeto, e não como enfeite comparativo. */
readonly papel: string;
}
export const REGIMES: readonly Regime[] = [
{
id: 'inline',
nome: 'Realidade virtual não imersiva',
tratamentoDoMundo: 'exibe',
espacoDeReferencia: 'viewer',
rastreia: 'nada do corpo; a câmera obedece ao mouse',
registroContra: 'a origem arbitrária da própria cena, fixada por quem a modelou',
composicaoEsperada: 'opaque',
papel:
'É o caso base e o destino de quem não tem headset: a bancada inteira precisa ' +
'ser montável aqui.',
},
{
id: 'immersive-vr',
nome: 'Realidade virtual imersiva',
tratamentoDoMundo: 'substitui',
espacoDeReferencia: 'local-floor',
rastreia: 'a pose da cabeça e a das duas mãos, com seis graus de liberdade',
registroContra:
'o chão do espaço físico onde a pessoa está, o que faz a bancada nascer na ' +
'altura certa em vez de flutuar',
composicaoEsperada: 'opaque',
papel:
'É onde escala corporal e alcance de braço passam a existir — e nenhum dos ' +
'dois tem equivalente na janela do desktop.',
},
{
id: 'immersive-ar',
nome: 'Realidade aumentada',
tratamentoDoMundo: 'preserva',
espacoDeReferencia: 'local-floor',
rastreia:
'a pose da cabeça, a das mãos e as superfícies que o aparelho encontra no ' +
'ambiente',
registroContra:
'uma superfície real escolhida no ambiente, à qual a bancada permanece presa ' +
'enquanto a pessoa caminha em volta',
composicaoEsperada: 'alpha-blend',
papel:
'É o único regime em que errar o registro é visível a olho nu: a bancada ' +
'desliza sobre a mesa, e ninguém precisa de instrumento para notar.',
},
];
export function regimePorId(id: RegimeId): Regime {
const encontrado: Regime | undefined = REGIMES.find((regime) => regime.id === id);
if (encontrado === undefined) {
// Inalcançável enquanto REGIMES cobrir RegimeId, e é o compilador que garante
// isso ao construir a lista. O lançamento existe para o caso de alguém
// acrescentar um id ao tipo e esquecer a entrada correspondente.
throw new Error(`Regime não declarado: ${id}`);
}
return encontrado;
}
Os identificadores dos regimes coincidem com os modos de sessão da plataforma. Isso permite perguntar ao aparelho, sem tabela de conversão no meio, se ele suporta o que foi declarado. O modo de composição aparece ali como valor esperado, e não lido: o valor real só existe com sessão ativa, e sessão ainda não é assunto aqui.
Falta o confronto. A última peça faz ao navegador a pergunta de triagem — este aparelho entra neste regime? — e devolve os três estados possíveis, em vez de dois.
src/bancada/modes/verificacao.ts
// ---------------------------------------------------------------------------
// Confronto entre o que declaramos e o que o aparelho oferece.
//
// A Tarefa 2 termina numa declaração de intenção, e intenção envelhece bem
// demais: continua parecendo certa muito depois de ter deixado de ser. Este
// arquivo faz a pergunta correspondente ao navegador em que a página está aberta
// e devolve as duas colunas lado a lado.
//
// O que ele NÃO faz, e a distinção importa: não abre sessão, não mede graus de
// liberdade, não enumera fontes de entrada nem lista capacidades opcionais. Isso
// é a sonda de capacidades, que pertence ao módulo de dispositivos. Aqui a
// pergunta é a mais grossa possível — "este aparelho entra neste regime?" —, que
// é exatamente a que o conceito deste módulo suporta.
// ---------------------------------------------------------------------------
import { REGIMES, type Regime, type RegimeId } from './regimes';
/**
* `desconhecido` não é sinônimo de `nao`. O navegador sem a API XR não está
* dizendo que o aparelho não serve — está dizendo que não sabe responder, e
* tratar as duas coisas como a mesma é o erro que faz um relatório honesto
* virar um relatório confiante e errado.
*/
export type Suporte = 'sim' | 'nao' | 'desconhecido';
export interface LinhaDoRelatorio {
readonly regime: Regime;
readonly suporte: Suporte;
readonly observacao: string;
}
/** A API XR do navegador, quando existe. */
function sistemaXr(): XRSystem | undefined {
return navigator.xr;
}
async function suporteDe(id: RegimeId): Promise<Suporte> {
const xr: XRSystem | undefined = sistemaXr();
if (xr === undefined) {
return 'desconhecido';
}
try {
const suportado: boolean = await xr.isSessionSupported(id);
return suportado ? 'sim' : 'nao';
} catch {
// Alguns navegadores rejeitam a promessa em vez de devolver `false` — para
// um modo de sessão que não reconhecem, ou fora de contexto seguro. Nos dois
// casos o que se sabe é que não houve resposta utilizável.
return 'desconhecido';
}
}
function observacaoDe(regime: Regime, suporte: Suporte): string {
if (suporte === 'sim') {
return `Declarado com registro contra ${regime.registroContra}. Falta confrontar em sessão.`;
}
if (suporte === 'nao') {
return 'Este aparelho não entra neste regime. É informação sobre o aparelho, não defeito do código.';
}
return 'Sem API XR neste navegador, ou página fora de contexto seguro (HTTPS).';
}
export async function levantarRelatorio(): Promise<LinhaDoRelatorio[]> {
const linhas: LinhaDoRelatorio[] = [];
for (const regime of REGIMES) {
const suporte: Suporte = await suporteDe(regime.id);
linhas.push({ regime, suporte, observacao: observacaoDe(regime, suporte) });
}
return linhas;
}
O terceiro estado é a decisão de desenho que mais rende aqui. Navegador sem a interface, ou página fora de contexto seguro, produz ausência de resposta, e não negativa sobre o aparelho. Abrir a mesma página no computador, no celular e num visor devolve três relatórios diferentes. É a primeira coisa observável do percurso, e ela não desenha nada.
1.8 Um domínio que não pede nada de ninguém
O erro mais caro deste ponto do percurso não custa nada na hora em que é cometido, e é por isso que ele passa.
Peça a dez pessoas que descrevam um ambiente tridimensional e você recebe dez cenários. Uma estação espacial. Um museu. Uma floresta com bichos. Todas são cenas, e nenhuma é um ambiente interativo — a diferença não está no tamanho nem no capricho. Uma cena se olha. Um ambiente interativo faz alguém tentar alguma coisa, conseguir ou falhar, e saber qual dos dois aconteceu.
flowchart TB
D["Dominio escolhido"] --> T["Tarefa em UMA frase<br/>com uma acao e um fim"]
T --> E["Estado final observavel<br/>de fora, sem abrir o codigo"]
E --> C{"Conferencia mecanica"}
C -->|"peca sem encaixe"| X1["decoracao disfarcada<br/>de conteudo"]
C -->|"encaixe sem peca"| X2["passo da tarefa que<br/>voce esqueceu de escrever"]
C -->|"tudo emparelhado"| OK["dominio fechado"]
O que separa os dois cabe numa palavra que quase nunca aparece nas dez descrições espontâneas: tarefa. E a exigência não é de roteiro — ninguém está pedindo enredo, motivação de personagem ou justificativa temática. É seca: existe algo que a pessoa está tentando fazer neste ambiente, e esse algo cabe em uma frase. Uma frase é curta demais para esconder ambiguidade, e é por isso que ela é difícil de escrever.
Tente com um museu virtual. O que a pessoa está tentando fazer? Andar e olhar descreve um passeio, e passeio não tem fim. Ambiente sem fim obriga alguém, capítulos adiante, a inventar um critério artificial de sucesso — e critério artificial acaba virando pontuação em que ninguém acredita. Agora tente com uma oficina de montagem: a pessoa encaixa cada peça no lugar certo, na ordem em que uma depende da outra. Tem começo, meio, fim, e tem erro possível.
Erro possível é o que torna o ambiente ensinável, porque ambiente em que nada pode dar errado não ensina nada. Há um segundo critério, igualmente duro: a tarefa precisa exercitar as quatro ações que os capítulos seguintes constroem — selecionar um objeto, apanhá-lo, orientá-lo e pô-lo num lugar certo. Uma maquete de cidade sobrevoada é bonita e não exercita nenhuma das quatro.
1.8.1 O fim tem de ser visível de fora
Tarefa sem estado final declarado é intenção, e intenção não se verifica. Por isso os dois campos andam sempre juntos. O estado final é a descrição do que se vê quando a tarefa está cumprida, e a palavra que carrega o peso ali é vê. Faça o teste mais barato que existe: alguém que nunca abriu o seu código, olhando a cena, consegue dizer se a tarefa terminou?
Se a resposta depender de consultar uma variável interna, o estado final não é observável — é anotação sobre a cena, não propriedade dela. Um exemplo ruim cabe em cinco palavras: o usuário completou a montagem. Isso repete a tarefa com outras palavras. Um exemplo bom é mais longo de propósito: as cinco peças estão encaixadas nos lugares compatíveis, na ordem válida, e o mecanismo montado gira.
Repara no que o segundo tem e o primeiro não. Ele nomeia quantas peças, onde elas estão, e um comportamento visível que só acontece no fim. O movimento final costuma ser dispensado como enfeite e não é: ele anuncia sozinho que a tarefa terminou, sem relatório de depuração nenhum. E ambiente cujo fim se anuncia assim é ambiente que você consegue testar com quem nunca o viu.
Agora o erro previsível. O domínio cresce sem resistência porque, neste ponto, nada custa nada. Vinte peças em vez de cinco não pesam agora, e a conta chega adiante, multiplicada. Cada peça vai precisar de malha poligonal, volume de colisão, tolerância de encaixe e um passo na ordem de montagem.
O sinal de que o domínio inchou. Se você não consegue enunciar a tarefa em uma frase, ele está grande demais, e o sintoma é a frase com “e também” no meio, emendando uma segunda ação na primeira. O teste de bolso: conte os objetos distintos que a sua descrição menciona e multiplique por quatro, que é quanto artefato cada um vai exigir. Passou de algumas dezenas, não cabe no percurso. Cortar agora custa uma frase reescrita; cortar depois custa tudo o que já foi modelado em volta da parte cortada.
1.9 Sete decisões e nenhum polígono
Um capítulo inteiro sem um pixel na tela — o que se ganhou foi o direito de ser contradito.
Faça o balanço do que existe agora. Um vocabulário que classifica sistemas por decisão técnica, e não por rótulo de fabricante. Um critério de três verbos que separa o que o sistema faz com o cômodo. Uma escada de registro que mostra o que cada degrau custa em dependência do mundo real. Três grandezas separadas, cada uma medida num lugar diferente. E uma delimitação de domínio com tarefa e estado final.
flowchart LR
V["Vocabulario:<br/>substituir, preservar, exibir"] --> DEC["Declaracao tipada:<br/>dominio, tarefa,<br/>regimes pretendidos"]
G["Tres grandezas separadas<br/>por onde se medem"] --> DEC
E["Escada do registro:<br/>o que cada degrau custa<br/>em dependencia do real"] --> DEC
DEC --> Q["A pergunta que sobra:<br/>como o aparelho descobre<br/>onde esta o chao?"]
Some a isso o recorte prometido lá atrás, que agora vale como critério: o eixo não mede preço, nitidez, conforto nem crença. Quem o usar para decidir qualquer um dos quatro estará com a régua errada. Existe uma ordem tentadora para começar um projeto tridimensional — abrir a biblioteca gráfica, pôr um cubo na tela e decidir o resto depois.
Ela é tentadora porque produz resultado visível em minutos, e errada porque o cubo na tela não responde a nenhuma pergunta que importe. Qual é o espaço de referência daquele cubo? Contra o que ele está registrado, e de que tarefa ele participa? Sem essas respostas, ele é um enfeite que será reescrito três vezes; com elas, nasce no lugar certo da arquitetura.
Há um segundo motivo, e ele é sobre você. Quem começa pelo visível cria a expectativa de progresso visível, e o progresso desta área não é constante. Abstração de entrada, orçamento de quadro, estabilidade de âncora: os três são invisíveis enquanto funcionam e ensurdecedores quando falham. Começar pela camada declarativa calibra a expectativa desde o primeiro dia.
Vale ainda o ceticismo devido sobre a própria tese, porque ela tem bordas. A separação entre presença e fidelidade não vale para um ambiente cuja tarefa seja avaliar aparência. E presença por dois minutos não se sustenta pelo mesmo que presença por quarenta. Em exposição longa, incoerências pequenas somam e produzem aquele desconforto difuso que o usuário chama de cansaço. A formulação honesta é modesta: fidelidade não é condição necessária para presença, nem o primeiro lugar onde investir.
Duas coisas atravessam a fronteira deste capítulo. A distinção entre não suportar e não responder, que volta como o eixo do relatório de capacidades. E a ideia de que a origem do mundo construído pode estar presa a algo real. Fica a pergunta grande: como um equipamento que não sabe nada sobre a sua sala descobre onde está o chão dela? O braço mecânico cobrava a imobilidade de quem o usava. A resposta moderna é outra: o aparelho desenha a planta da sala enquanto atravessa a sala, e corrige o desenho toda vez que reconhece um canto por onde já passou.
O que fica pronto aqui é modesto e honesto sobre a própria modéstia. Existe para ser desmentido, campo por campo, pelo comportamento que vem adiante — e é isso que se pede agora.
Tarefa 1: Delimitar o domínio da cena
O ambiente que acompanha a leitura precisa de um domínio antes de precisar de uma linha de código. Uma oficina de montagem, um laboratório de instrumentos, uma maquete que se percorre: serve qualquer cena em que objetos sejam selecionados, movidos, orientados e postos em algum lugar certo.
O que fica pronto é a descrição do domínio escolhido, com a tarefa que o ambiente suporta enunciada em uma frase, os objetos que a compõem e o estado que caracteriza a tarefa concluída. Domínio sem tarefa produz uma cena bonita e vazia, e é ela que trava os capítulos de manipulação adiante.
Tarefa 2: Declarar o que cada regime faz com o mundo
Os três regimes do ambiente diferem pelo que fazem com o ambiente de quem observa: um o substitui inteiro, outro o mantém e deposita sobre ele, o terceiro o mostra por uma janela sem tocá-lo. Essa distinção precisa estar escrita antes de existir código, porque ela decide o que cada regime terá de provar depois.
O que fica pronto é o registro, por regime, do espaço de referência pretendido, do que será rastreado e contra o que a cena será registrada. Ao longo do percurso essa declaração vira comportamento observável, e comparar o que se escreveu aqui com o que o ambiente faz adiante é o exercício mais barato de honestidade técnica que o projeto oferece.