flowchart TD
A["Um sistema qualquer,<br/>de um fabricante qualquer"] --> B{"Pergunta de categoria:<br/>isso é virtual ou aumentada?"}
A --> C{"Pergunta de decisão:<br/>o que o programa pede<br/>e o que ele recebe?"}
B --> B1["Resposta rápida"]
B1 --> B2["Nenhum campo preenchido<br/>Nenhuma linha de código"]
C --> C1["Que espaço de referência<br/>o sistema adota?"]
C --> C2["O que ele rastreia?"]
C --> C3["Contra o que a cena<br/>é registrada?"]
C1 --> D["Sistema descrito,<br/>sem citar o nome do produto"]
C2 --> D
C3 --> D
1 O contínuo entre o sintético e o real
Cinco palavras precisam ficar de pé antes de o primeiro triângulo aparecer na tela.
Cinco palavras que passam a ter sentido preciso. Contínuo, imersão, presença, registro e espaço de referência. Nenhuma delas exige um polígono desenhado, e as cinco decidem coisas que nenhuma escolha de material conserta depois.
Ponha duas pessoas diante da mesma demonstração, uma depois da outra, e pergunte o que elas viram. A primeira conta que esteve dentro de uma oficina. Chão, paredes, uma bancada à frente. Nada do quarto onde ela de fato estava. A segunda conta que viu uma bancada pousada sobre a mesa da sala, com o abajur e a caneca ainda ali do lado. As duas descrevem corretamente o que aconteceu. O programa era o mesmo, e a diferença entre as duas experiências cabia em duas linhas de configuração.
Um desses relatos costuma receber o nome de realidade virtual, e o outro, o de realidade aumentada. Os nomes funcionam bem enquanto ninguém precisa decidir nada com eles. Na hora de decidir, eles falham. Um visor opaco que mostra a sala por câmeras entrega ao olho uma imagem inteiramente sintética de um ambiente inteiramente real. Não há sorteio honesto entre as duas etiquetas. O vocabulário de categorias serve para vender; para projetar, ele não serve.
Existe substituto. Há um jeito de descrever esses sistemas que dispensa o nome do produto e o formato do aparelho. Ele sobrevive à próxima geração de equipamento. Ele descreve o que o sistema faz, em vez da família a que ele pertence. É esse vocabulário que se monta aqui, peça por peça, sem desenhar uma superfície sequer.
1.1 A pergunta que não decide nada
A resposta é imediata, consensual e imprestável.
Qual é a pergunta que se faz diante de um aparelho novo? Quase sempre a mesma: isso aí é realidade virtual ou realidade aumentada? Ela pede que se decida a que caixa o objeto pertence antes de qualquer outra coisa. A resposta chega rápido e todo mundo concorda com ela. Na prática, ninguém consegue fazer nada com ela depois. Experimente respondê-la no caso das duas pessoas ali de cima: mesmo programa, mesmo aparelho, dois relatos incompatíveis. Se a classificação depende do que está rodando naquele instante, ela classifica a sessão. O nome impresso na caixa nunca decidiu coisa alguma.
A primeira tentativa de salvar a pergunta é olhar para o equipamento. Ela sobrevive a uns dez segundos de contato com o parque real de aparelhos. Um visor recente é opaco e tem câmeras na frente. Ele tapa a sala inteira e desenha uma oficina no lugar dela. Ele também retransmite a sala aos seus olhos e deposita uma bancada sobre a mesa que está ali. Mesmo hardware, mesmo minuto, mesma cadeira. O celular é o caso simétrico. Ele é tratado como aparelho de realidade aumentada por causa da câmera traseira.
E exibe também uma cena que você gira com o dedo, sem referência nenhuma ao ambiente em volta.
Vamos por partes, porque o terceiro caso fecha a porta de vez. Um visor opaco moderno mostra a sala através de câmeras, com a imagem processada e reapresentada nas telas internas. Do ponto de vista da óptica, cada pixel que chega ao olho é sintético. Nenhuma luz da sala atravessa coisa alguma. Do ponto de vista de quem está usando, aquilo é a sala, com a caneca no lugar certo e a porta onde ela sempre esteve. O caso mais sintético possível é também um dos mais reais possíveis. A pergunta de classificação não tem o que dizer sobre ele. Nenhuma das duas etiquetas descreve o que aquele programa faz com o ambiente da pessoa.
Antes de seguir. Pegue o aparelho mais próximo de você e tente enquadrá-lo numa das duas etiquetas. Depois pergunte o que muda na sua resposta se o programa aberto nele for trocado. Se a etiqueta mudar junto, ela nunca foi propriedade do aparelho.
O que sobra quando o nome sai é o software: o que o programa pede e o que ele recebe. São três decisões técnicas explícitas, e cada uma é observável de fora, sem consultar o manual do fabricante. Que espaço de referência o sistema adota, isto é, onde fica a origem do mundo que ele desenha? O que ele rastreia — a cabeça, as mãos, o aparelho, nada? E contra o que a cena é registrada, ou seja, a que coisa do mundo físico a posição dos objetos virtuais está presa?
Há um teste rápido para saber se uma resposta serve: tente escrever código a partir dela. De “isso é realidade aumentada” não sai uma linha. Não se sabe que espaço de referência pedir, que permissão solicitar, o que fazer quando o aparelho não tiver câmera. De “o programa pede um espaço ancorado no chão e mantém a imagem da sala visível” sai a chamada de abertura de sessão inteira, com o tratamento de falha junto. O mercado, enquanto isso, seguiu multiplicando etiquetas. Depois de virtual e aumentada vieram mista e estendida. Nenhuma delas acrescentou um campo que se pudesse preencher. Um vocabulário que se renova a cada dois anos informa alguma coisa sobre si mesmo. E não é coisa técnica.
1.2 Um eixo, e o que ele se recusa a medir
Dois engenheiros trocaram a pergunta da área em 1994, e a troca ainda organiza o vocabulário.
Em 1994, na Universidade de Toronto, Paul Milgram e Fumio Kishino publicaram uma taxonomia de sistemas de exibição que fez uma coisa aparentemente modesta. Eles pararam de perguntar se um visor de ver-através “era” realidade virtual. Passaram a perguntar quanto de cada lado o sistema exibia: quanto do ambiente físico chegava aos olhos, quanto do sintético entrava no lugar. A modéstia é aparente, porque a troca mexe na estrutura da pergunta. Uma pergunta de fronteira admite duas respostas e obriga a escolher uma. Uma pergunta de grau admite infinitas posições. E obriga a medir.
Chame de c a fração da imagem apresentada que tem origem sintética. O eixo é o intervalo percorrido por ela:
c \in [0,\,1]
NotaDefinição — Contínuo entre ambiente real e ambiente sintético
Um sistema de exibição visual apresenta a quem observa uma composição de duas origens: o ambiente físico em que a pessoa está e o ambiente sintético produzido pela máquina. O contínuo entre ambiente real e ambiente sintético é o intervalo fechado percorrido pela fração de origem sintética. O extremo inferior marca a apresentação exclusivamente física; o superior, a exclusivamente sintética.
Todo sistema que apresenta as duas origens ao mesmo tempo ocupa uma posição interna. Essa posição pertence ao que o aparelho está executando naquele momento, e viaja com a sessão.
O menor exemplo concreto está no primeiro parágrafo destas páginas. Na primeira descrição a fração é máxima, porque nada do quarto chega aos olhos. Na segunda ela fica perto de zero, porque quase tudo o que se vê é a sala. Um mesmo programa cobre, portanto, um conjunto de posições no eixo, e nunca um ponto só. Veja só o que a definição não exige: nada de imagem bonita, nada de aparelho caro, nada de crença. O eixo mede proporção de origem, e para por aí.
AvisoQuatro coisas que a posição no eixo não informa
Conforto. Duas sessões na mesma posição podem diferir em enjoo, peso no pescoço e cansaço visual.
Custo. Um aparelho de mil reais e um de vinte mil executam o mesmo regime e ocupam a mesma posição.
Nitidez. Resolução, contraste e qualidade do material são independentes da proporção de origem.
Crença. Quanto a pessoa se comporta como se aquilo fosse real é assunto de outra grandeza. É a omissão mais séria das quatro.
A quarta é a mais séria por um motivo específico. Ninguém confunde a etiqueta do produto com a do preço, e por isso as três primeiras não fazem estrago. Mas quase todo mundo diz “esse é mais imersivo” querendo dizer que a pessoa acreditou mais. Aí duas grandezas passam a dividir a mesma palavra, sem que nenhuma delas possa mais ser discutida em separado.
A consequência que mais rende também cabe numa frase: a posição no eixo é atributo do que está executando. “Qual dos dois é mais imersivo?” tem resposta, porque é pergunta sobre equipamento. “Qual dos dois está mais para o lado sintético?” fica sem resposta enquanto ninguém disser o que cada um está executando. Um ambiente com vários regimes ocupa um conjunto de pontos. O desenho desse conjunto é decisão de projeto explícita.
E a segunda metade da pergunta carrega o peso: o que ele mantém idêntico entre as posições que cobre? Se cada uma for coberta por um programa diferente, a comparação entre elas diz respeito às duas implementações. Nada aos regimes.
flowchart LR
R["c = 0<br/>só o ambiente físico"] --- M["0 < c < 1<br/>as duas origens<br/>ao mesmo tempo"] --- S["c = 1<br/>só o ambiente sintético"]
T1["exibe:<br/>a cena numa janela,<br/>o mundo intocado em volta"] -.-> R
T2["preserva:<br/>o mundo continua visível,<br/>a cena pousa sobre ele"] -.-> M
T3["substitui:<br/>o mundo some,<br/>a cena ocupa tudo"] -.-> S
Para virar instrumento de projeto, o eixo precisa de uma forma que um programa consiga carregar. E aí a coisa fica interessante. O contínuo inteiro cabe num tipo de dado com três valores. O que distingue os regimes, na hora de escrever código, é o que cada um faz com o ambiente de quem observa. Um o substitui inteiro. Outro o preserva visível e deposita a cena sobre ele. Um terceiro exibe a cena por uma janela, sem tocar no ambiente em volta.
os três tratamentos, em modes/regimes.ts
/**
* 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 realQuatro linhas, três valores, e uma decisão de projeto escondida no meio. Os três moram num tipo só, o que obriga todo regime a se declarar por um deles. A alternativa preguiçosa seria um campo booleano do tipo imersivo: true. Ele funcionaria até o dia em que aparecesse o terceiro caso. Quando isso acontece, já existem quarenta lugares no programa perguntando se o regime é imersivo. Prefiro o tipo de três valores desde a primeira linha, e a conta é real. Cada seleção sobre ele precisa cobrir três ramos, e o verificador de tipos reclama quando falta um.
Um detalhe de escrita contraria o que a maioria faria sozinha. Os três valores são cadeias de texto, e nunca números ou constantes de uma enumeração. Cadeia de texto é mais lenta de comparar e ocupa mais memória. Nada disso importa: a comparação acontece uma vez por sessão. O ganho aparece num relatório, num registro de execução ou numa mensagem de erro. No fim das contas, quem lê preserva entende na hora, e quem lê 1 vai procurar a tabela.
1.3 Imersão é do aparelho, presença é sua, registro é da geometria
Uma cena feia pode convencer o corpo; uma cena linda pode não convencer ninguém.
Três palavras costumam ser usadas como sinônimos, e as três descrevem coisas diferentes. A confusão entre elas sai cara. É ela que faz um grupo inteiro concluir que o caminho para um ambiente convincente passa por comprar uma placa de vídeo melhor.
1.3.1 As duas que moram em lados opostos do rosto
Comece pela mais fácil. Imersão é propriedade do sistema, e se mede sem que ninguém vista coisa alguma. Dois aparelhos podem ser comparados numa planilha, com os números publicados pelo fabricante e com os que se medem na bancada. As quatro grandezas objetivas que descrevem a imersão cabem numa tupla só, e é assim que elas aparecem escritas:
I = (\phi,\; \ell,\; g,\; f)
NotaDefinição — Imersão
Imersão é a extensão em que um sistema apresenta estímulos sensoriais que substituem os do ambiente físico. É propriedade do sistema, mensurável independentemente de quem o usa. Quatro grandezas a descrevem. O campo de visão coberto pela imagem. A latência entre o movimento do corpo e a atualização correspondente da imagem. O número de graus de liberdade rastreados. E a cadência com que as imagens são apresentadas.
Um monitor de mesa cobre uns poucos graus do campo de visão de quem está sentado, rastreia zero graus de liberdade e apresenta imagens numa cadência confortável. Um visor cobre a maior parte do campo, rastreia seis graus de liberdade da cabeça e apresenta imagens numa cadência mais alta. Os números existem, os dois se medem, e a comparação não depende da opinião de ninguém. Repare no que a definição não pede: resolução, qualidade de material, contagem de triângulos, realismo da iluminação. Um sistema pode ter imersão alta e exibir cubos cinzentos.
NotaDefinição — Presença
Presença é a resposta de quem usa o sistema a esse sistema: a disposição a se comportar, dentro do ambiente apresentado, como se comportaria num ambiente físico com as mesmas propriedades. É atributo da pessoa, e se observa por comportamento. Desviar de um obstáculo que não existe. Hesitar diante de uma queda desenhada. Estender a mão até a distância certa de um objeto que não está lá. A definição não faz referência alguma à fidelidade visual do que é apresentado.
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. Um palco vazio com a marcação certa sustenta duas horas de peça. Um cenário caprichado não salva um ator entrando pela porta errada. A evidência mais barata cabe num experimento com dois programas na mesma máquina. De um lado, arestas de arame sem material nenhum, que respondem ao movimento da cabeça sem atraso perceptível. Do outro, uma cena caprichada que responde meio segundo depois. A primeira segura quem a usa. A segunda produz desconforto em poucos minutos, e a pessoa tira o aparelho.
O que sustenta a crença é o acordo entre o que o corpo faz e o que a cena responde. A cabeça vira, a imagem acompanha na hora certa, e o sistema nervoso recebe a confirmação que espera do mundo físico. Imagem atrasada entrega uma contradição. E contradição entre canais sensoriais é a receita conhecida do mal-estar. A separação é assimétrica, e a assimetria importa. Alta imersão não garante presença, porque um sistema com a ficha técnica toda em ordem falha se puser o chão na altura errada. Já presença sem alguma imersão é difícil de obter, porque a resposta do corpo depende de que os estímulos cheguem.
1.3.2 O registro tem gabarito ao lado, e cobra a ordem do esforço
A terceira palavra é a mais estreita das três, e a estreiteza é o que a torna útil.
NotaDefinição — Registro
Registro é a relação geométrica entre o que o sistema desenha e o mundo físico visível: o grau em que um objeto sintético aparece na posição, na orientação e na escala que ele ocuparia se estivesse fisicamente ali.
Registro só está definido onde há mundo físico visível. Num regime que substitui o ambiente por inteiro, não existe contra o que registrar, e a palavra não se aplica.
Uma xícara desenhada sobre uma mesa real dá o menor exemplo possível. Com bom registro ela fica no mesmo lugar quando quem observa anda em volta; com registro ruim ela desliza, atravessa a borda ou flutua alguns centímetros acima da madeira. O erro é geométrico e se mede em centímetros e em graus, porque o mundo físico está ali do lado e pode ser fotografado junto com o desenho. Duas famílias de erro se distinguem nessa medida, e confundi-las manda o conserto para o lugar errado. O erro estático persiste com todo mundo parado, por defeito de calibração ou de origem. O erro dinâmico só aparece durante o movimento: o objeto parece nadar e volta ao lugar assim que a pessoa para. É defeito de tempo, da mesma família do atraso que derruba a presença.
Num regime a palavra fica sem significado nenhum. Aquele que tapou a sala inteira tem imersão alta e registro indefinido — indefinido, e não ruim, porque a grandeza ficou sem objeto. Nos regimes que preservam o mundo visível, em compensação, a fronteira entre palco e pintura afrouxa: sombra projetada e oclusão deixam de ser enfeite e viram evidência de posição. Um objeto sem sombra sobre a mesa real parece flutuar mesmo com a geometria impecável, porque tudo em volta dele tem sombra e ele não tem.
Separadas as três, cai uma consequência de projeto que contraria o que quase todo mundo faria sozinho. Escala correta antes de material bonito. Quadro estável antes de sombra suave. Caixas cinzentas na altura certa antes de mecanismo lindíssimo na altura do peito. O argumento é de custo de correção. Trocar o material de um objeto leva minutos. Descobrir no fim que a bancada foi modelada com o dobro do tamanho real significa refazer alturas, alcances, tolerâncias e a disposição do ambiente inteiro. E refazer com a cena cheia, quando cada mudança quebra outras três.
O efeito colateral incomoda, e é bom saber dele antes. Durante boa parte da construção o ambiente é feio, e quem olha de fora conclui que o trabalho não avançou. A conclusão é compreensível, porque a evidência visível de progresso ficou por último de propósito. O critério que sobrevive a essa pressão é de contabilidade — pergunte, a cada item da lista, quanto custaria corrigi-lo depois.
flowchart TD
subgraph EQ["No equipamento"]
I["Imersão<br/>campo de visão, latência,<br/>graus rastreados, cadência"]
end
subgraph PE["Na pessoa"]
P["Presença<br/>comportamento observado<br/>diante da cena"]
end
subgraph GE["Na geometria entre cena e mundo"]
G["Registro<br/>erro de posição e orientação,<br/>em centímetros e graus"]
end
I -->|"não garante"| P
P -->|"precisa de alguma"| I
G -->|"indefinido quando<br/>o mundo é substituído"| X["sem objeto<br/>contra o que medir"]
| Grandeza | Onde ela mora | Como se mede | O que a medida não prova |
|---|---|---|---|
| Imersão | no equipamento | ficha técnica e bancada: campo de visão, latência, graus rastreados, cadência | que alguém vá se comportar como se estivesse lá |
| Presença | na pessoa | comportamento observado e relato de quem usou | que a imagem seja bonita, nem que o aparelho seja caro |
| Registro | na geometria entre cena e mundo | erro de posição e de orientação, em centímetros e graus | que o ambiente seja confortável ou convincente |
A coluna da direita é a que costuma faltar em relatório técnico. Número apresentado sem o seu alcance acaba usado para responder à pergunta errada. A ficha técnica de um visor responde por imersão, e vai ser citada em alguma reunião como prova de que o ambiente convence.
1.4 O que a sessão faz com o mundo, e onde ela põe o zero
As duas linhas de configuração da primeira página, agora com nome.
Um regime que substitui o ambiente precisa de uma imagem opaca: cada pixel entregue ao olho vem da cena sintética. Um regime que preserva o ambiente precisa do contrário, com a imagem sintética ocupando parte do campo e deixando o resto passar. São modos de composição óptica, e a interface que governa essas sessões os nomeia diretamente. O fundo opaco esconde o mundo. O aditivo soma a luz sintética à luz que já chega ao olho. E a mistura por transparência combina as duas segundo um valor de opacidade que a própria cena controla, pixel a pixel.
a composição do fundo, em modes/regimes.ts
/**
* 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';O comentário desse arquivo diz uma coisa que a definição não dizia: o valor só é legível com uma sessão aberta. Antes disso o programa tem uma expectativa, que é o modo pretendido, e ela pode ser desmentida pelo aparelho no instante em que a sessão começa.
1.4.1 O preto que não existe
No modo opaco o preto é uma cor como qualquer outra: o painel emite pouca luz naquele ponto, e a sombra funciona como sombra em qualquer material. Veja bem o que acontece no modo aditivo: a operação é uma soma, e não existe subtração disponível. Nenhum pixel consegue retirar luz que já estava chegando ao olho. Desenhar preto ali significa somar zero, e somar zero é não desenhar. A sombra desaparece, o objeto fica translúcido nas regiões escuras, e um material preto se torna literalmente invisível.
Na prática, a consequência é imediata. Contorno, aresta e região de sombra precisam ser desenhados com luz: uma borda clara sobrevive à soma, uma borda preta não. Um material desenhado para o regime opaco e reaproveitado no aditivo não fica pior — ele some. Vale para tudo o que informa dentro da cena, e texto escuro sobre fundo claro vira mancha luminosa ilegível pairando no ar. A inversão funciona nos dois modos, com uma ressalva: texto claro sobre fundo transparente depende do que estiver fisicamente atrás, e uma parede branca ensolarada apaga qualquer letra. No sentido inverso a perda é menor, e existe. Um material todo em contorno luminoso funciona no modo opaco e fica pobre, porque o preto estava disponível e ninguém o usou.
Nada disso se ajusta por configuração no fim do trabalho. É restrição da óptica do aparelho, e ela decide como cada material vai ser construído quando a paleta da cena é escolhida. A mistura por transparência é o terceiro caso, e desmonta a leitura binária. Ali a opacidade vive num valor por pixel, que a cena escreve enquanto desenha. Se ela cobrir metade do campo de visão com material opaco, metade do que se vê é sintético. Se cobrir uma moldura num canto, quase tudo o que se vê é o quarto. A fronteira entre substituir e sobrepor mora nesse valor, e um mesmo programa a atravessa várias vezes por segundo.
Daí a regra de escrita que poupa uma tarde de depuração: o modo de composição é resposta, e nunca configuração. Guarde separados o esperado, que é decisão de projeto, e o obtido, que é fato do aparelho. Um campo só obriga a sobrescrever a expectativa com a resposta, e o que se perde é justamente a informação de que houve divergência.
1.4.2 Onde nasce o zero do mundo
Três degraus separam o caso mais livre do caso mais preso. O que muda de um para o outro é uma pergunta só: quem decide onde fica a origem do mundo virtual. Subir a escada é perder liberdade, e cada degrau perdido compra algo que o anterior não tinha.
NotaDefinição — Espaço de referência
Espaço de referência é o sistema de coordenadas em que as poses do ambiente são expressas, junto com a regra que fixa a sua origem e a sua orientação em relação ao mundo físico.
Um espaço de referência se caracteriza por três coisas: onde fica a origem, quem a determina, e o que acontece com ela quando quem usa o sistema se desloca. Duas cenas com a mesma geometria e espaços de referência diferentes produzem experiências distintas.
Uma coordenada dá o menor exemplo possível. Se a origem é um ponto arbitrário escolhido por quem modelou, dois metros à frente dela são dois metros de mundo virtual, sem relação com nada. Se a origem é o chão do espaço físico, os mesmos dois metros são dois metros do chão da sala onde a pessoa está de pé. A coordenada não mudou uma vírgula, e a frase que ela exprime mudou inteira. Repare também no que a definição não exige: precisão, estabilidade, qualidade de rastreamento. Um espaço de referência mal rastreado continua sendo um espaço de referência, e o erro dele se mede contra a origem que ele mesmo declarou. A qualidade da medida é assunto separado da regra que fixa o zero.
flowchart TD
D1["Degrau 1<br/>origem: ponto arbitrário da cena<br/>quem decide: quem modelou"] --> G1["ganha: liberdade total<br/>perde: escala corporal"]
D1 --> D2["Degrau 2<br/>origem: o chão do espaço físico<br/>quem decide: o rastreamento"]
D2 --> G2["ganha: altura e alcance de braço<br/>arrisca: piso estimado fora do lugar"]
D2 --> D3["Degrau 3<br/>origem: superfície real detectada<br/>quem decide: o ambiente, medido"]
D3 --> G3["ganha: registro conferível a olho nu<br/>arrisca: a superfície muda de lugar"]
No primeiro degrau a origem é um ponto arbitrário da cena. Ninguém tem argumento para discordar, porque não existe nada no mundo físico contra o que conferi-la. É o caso da cena numa janela, com a câmera orbitando o conteúdo: liberdade total, e escala corporal nenhuma, porque não há corpo no sistema de coordenadas. No segundo, a origem passa a ser o chão do espaço físico, estimado pelo rastreamento, e uma bancada declarada a noventa centímetros nasce na altura de uma bancada. No terceiro, a origem é uma superfície real detectada, a liberdade cai a quase zero e o que se obtém é o registro no sentido estrito da definição anterior.
A face desagradável cresce junto. No primeiro degrau nada pode dar errado com a origem, porque não há nada contra o que ela erre. No segundo, o aparelho pode estimar o piso acima ou abaixo do real, e a cena inteira nasce deslocada. No terceiro, a superfície detectada muda de lugar quando o aparelho revisa o que acha do ambiente, e o objeto que estava sobre a mesa passa a estar atravessado nela. Cada degrau troca liberdade por informação do mundo, e informação do mundo vem com incerteza embutida.
| Degrau | Origem do mundo virtual | Quem a decide | O que se ganha |
|---|---|---|---|
| 1 | ponto arbitrário da cena | quem modelou | liberdade total de composição |
| 2 | chão do espaço físico | o rastreamento do aparelho | escala corporal e alcance de braço |
| 3 | superfície real detectada | o ambiente, medido pelo aparelho | registro conferível a olho nu |
Os três degraus diferem em quatro perguntas: o que se faz com o mundo, que espaço de referência se pretende, o que se rastreia e contra o que se registra. A forma natural de escrevê-los é uma lista de registros com os mesmos campos.
o regime declarado campo a campo, em modes/regimes.ts
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;
}Essa forma decide mais do que parece. Um regime que precisasse de um campo próprio, ausente nos outros dois, avisaria que voltamos a tratar o contínuo como caixas separadas. Campo exclusivo é categoria com outra roupa. Daí o erro previsível, que se comete sem má-fé: declarar os três regimes e escrever, nos três, o mesmo espaço de referência, o mesmo rastreamento e o mesmo registro. O texto fica bonito, o código compila, e o que existe é uma cena só com três rótulos trocados. A conferência que desmascara isso é mecânica — compare as três entradas entre si, e se duas forem idênticas nesses campos, uma delas não existe.
O campo do espaço de referência guarda um vocabulário que se repete em qualquer interface desse tipo. Um espaço ancorado em quem observa viaja junto da cabeça. Um espaço local fixa a origem onde a sessão começou, sem prometer saber onde está o chão. Um espaço local com chão acrescenta essa promessa, e a altura passa a significar altura. Um espaço sem limites cobre área maior que a sala, e em troca a origem pode ser corrigida durante o uso. Quanto mais o espaço promete sobre o mundo físico, mais coisas ele pode errar. Na prática, escolher o que promete mais é reflexo comum e quase sempre errado.
1.4.3 A tabela do documento é a mesma do código
Essa declaração campo a campo tem um gêmeo em prosa, e o gêmeo mora na especificação do projeto.
os três regimes lado a lado, em docs/especificacao.md
| Aspecto | Na janela | No visor | Pela câmera |
| --- | --- | --- | --- |
| Como se olha | câmera em órbita, mouse | pose da cabeça, seis graus | pose do aparelho na mão |
| Como se aponta e age | raio do cursor, clique | raio do controle, gatilho | toque na tela sobre o objeto |
| Escala da cena | 1:1 | 1:1, corpo de pé | 1:2 sobre a mesa |
| Origem do mundo virtual | ponto arbitrário da cena | chão do espaço físico | superfície real detectada |
| O que a cena faz de diferente | nada além do essencial | alcance de braço passa a existir | o suporte fica preso à mesa real |
| O que não existe aqui | escala corporal, alcance de braço | o mundo real | o cenário em volta, e o chão virtual |Seis linhas, três colunas, e cada célula é uma afirmação que pode ser desmentida por observação. A escala não é a mesma nos três. Na janela e no visor a cena aparece em tamanho real. Pela câmera do celular ela vem reduzida à metade, porque uma bancada em tamanho real não cabe na mesa de ninguém. A última linha é a mais valiosa e a menos comum em documentos desse tipo — ela diz o que não existe em cada regime.
Só que uma declaração escrita envelhece de um jeito perverso: continua parecendo correta por meses depois de ter deixado de ser. Ninguém a lê procurando divergência, porque ela não mudou — quem mudou foi o código, noutro arquivo, num dia em que o documento nem foi aberto. Veja o roteiro completo. O projeto declara que o regime imersivo usa o chão como origem. Três meses depois, alguém troca o espaço de referência para resolver uma falha de rastreamento. A tabela segue afirmando a versão antiga, com toda a autoridade de um arquivo versionado. Duas fontes que descrevem a mesma coisa não se mantêm sincronizadas por disciplina. Ou uma deriva da outra por procedimento, ou as duas divergem. E a divergência silenciosa sempre chega primeiro a quem lê.
1.5 Doze retas penduradas no teto
O visor que Ivan Sutherland montou em 1968 precisava ficar suspenso do teto do laboratório por um braço mecânico articulado. O braço não estava ali apenas para segurar peso: ele também media a posição da cabeça de quem vestia o aparelho, lendo os ângulos das próprias juntas. O apelido pelo qual o equipamento ficou conhecido, espada de Dâmocles, descreve a imagem de quem entrava embaixo dele, e veio depois, dado por outras pessoas. O trabalho foi apresentado nos anais de uma conferência de computação daquele ano.
O que aquele aparelho exibia eram arestas de arame. Um cubo era doze segmentos de reta flutuando no ar, e o ar era a sala do laboratório, visível através da óptica semitransparente das duas pequenas telas. Reconstrua a cena com calma, porque ela é o contraexemplo mais antigo e mais barato de tudo o que se discutiu até aqui. A pessoa move a cabeça. Os segmentos giram na direção certa, na hora certa, e ela relata ter visto um cubo. Sem textura, sem sombra, sem cor. Geometria coerente com o corpo (e nada mais que isso) bastou.
flowchart LR
B["Braço mecânico<br/>preso ao teto"] -->|"sustenta o peso"| V["Visor na cabeça"]
B -->|"lê os ângulos<br/>das próprias juntas"| C["Computador"]
C -->|"doze segmentos de reta"| V
V -->|"óptica semitransparente"| O["Olho"]
L["A sala do laboratório"] -->|"a luz atravessa o vidro"| O
A escolha do braço merece um olhar menos reverente do que costuma receber. Ele não foi adotado por ser a melhor forma concebível de medir a posição de uma cabeça. Já estava ali, sustentando um peso que nenhum pescoço aguentaria, e ler os ângulos das juntas de uma estrutura rígida era a informação mais barata disponível. A distância entre o que se anunciava e o que se entregava também já estava dentro daquele laboratório. O aparelho se apresentava como um visor tridimensional acoplado à cabeça, e o que ele conseguia pôr ali eram doze retas. As duas coisas são verdadeiras ao mesmo tempo, e o espaço entre elas é a régua com que a área pode se medir desde então.
Trinta e um anos depois, Frederick Brooks publicou um balanço da área numa revista de computação gráfica. Ele trabalhava no assunto desde os anos 1960. Em Chapel Hill, havia posto químicos (gente com trabalho de bancada a fazer) para encaixar moléculas com um braço mecânico de retorno de força montado sobre a bancada. O que escreveu em 1999 foi que a realidade virtual havia passado de “quase funciona” a “mal e mal funciona”. Dizia isso de sistemas cuja imagem já era melhor que a de qualquer coisa exibida numa feira dez anos antes. O critério dele era o comportamento dos químicos, que preferiam usar o sistema a não usá-lo. Preferência medida em gente que tem trabalho a fazer é evidência de outra natureza que uma demonstração bonita.
Uma ressalva sobre o aparelho de 1968, e ela é sobre o que estas páginas não afirmam. Os números do equipamento — peso, campo de visão, resolução do traçado — circulam em versões que não batem entre si, e nenhuma delas é repetida aqui. O que se afirma é o que a descrição original sustenta. O braço, a suspensão, a leitura dos ângulos das juntas, as duas telas com óptica semitransparente e as arestas de arame. E é essa óptica que desfaz uma cronologia contada com frequência ao contrário. Quem usava aquele visor via as arestas e via a sala ao mesmo tempo, somadas pelo vidro: pela definição do contínuo, o sistema estava numa posição intermediária. O ancestral do campo nasceu do lado que hoje se chama de aumentado.
1.6 Tudo isto antes do primeiro polígono
O que se faz ali dentro? A pergunta parece simples demais para merecer uma seção, e é a que mais estraga quando fica sem resposta. Quem começa um ambiente tridimensional tende a responder pelo assunto — uma oficina, um museu, uma estação espacial —, e assunto não é tarefa. Um museu é um lugar, e lugar nenhum tem estado final, critério de conclusão ou possibilidade de estar errado.
A tentativa ingênua é escolher a cena primeiro e descobrir a tarefa depois. Ela é sedutora por um motivo honesto: no começo nada custa nada, e ampliar o escopo nessa fase é grátis. A conta chega mais tarde e no lugar errado, porque o defeito não aparece enquanto se modela. Ele aparece na primeira vez que alguém precisa dizer o que acontece quando o usuário pega um objeto e o solta em algum lugar. Ali é preciso responder se aquele lugar era o certo, e não há como, porque nunca se escreveu o que era certo.
1.6.1 Três perguntas e nenhum polígono
A ordem que sobra é a inversa: a tarefa primeiro, a cena depois. A primeira pergunta é a tarefa, e a restrição de forma é o que a torna útil — ela cabe em uma frase. A restrição serve de diagnóstico, porque uma tarefa que precisa de um parágrafo é mais de uma tarefa. “Montar um mecanismo encaixando as peças na ordem correta” cabe numa frase. “Explorar um ambiente industrial e aprender sobre processos de manufatura” também caberia, e não diz o que a pessoa faz com as mãos.
A segunda é o inventário: que objetos compõem essa tarefa, e apenas os que ela toca. Uma bancada tem tampo, pés e talvez uma luminária, e nada disso participa de encaixar peça nenhuma. Confundir o cenário com o inventário é o caminho mais curto para modelar quarenta objetos e descobrir que cinco bastavam. A terceira é o estado final: o que caracteriza a tarefa concluída, escrito de modo que alguém possa olhar e decidir. Sem ele não há como saber se a pessoa terminou, e sem isso não há retorno nem razão para continuar. Veja só a diferença que a formulação faz. “As cinco peças estão nos encaixes correspondentes e o mecanismo gira” passa no teste, porque dá para ver. “O usuário compreendeu o funcionamento do mecanismo” não passa: não existe pixel que mostre compreensão.
Há uma quarta pergunta que fica de fora, e a ausência é decisão. Não se pergunta ainda como a pessoa faz aquilo, se com o dedo, com o mouse ou com um controle na mão. A forma de agir depende do regime, e o domínio precisa sobreviver aos três. Escrever “arrastar com o dedo” na delimitação amarra o modelo ao celular antes de o modelo existir.
a tarefa e o estado final, em dominio/dominio.ts
/**
* 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;
}Quatro linhas, e a decisão que elas tomam é manter os dois campos juntos. Tarefa e estado final costumam morar em lugares diferentes: a tarefa vira uma frase no documento, e o estado final, uma condição perdida no código de validação. Postos lado a lado, um cobra o outro. Repare que os dois são texto, e não estrutura. Uma frase em português não é verificável pela máquina, e em troca é verificável por gente, agora, antes de existir máquina.
flowchart TD
T["A tarefa em uma frase"] --> N["O inventário:<br/>só os objetos que a tarefa toca"]
N --> E["O estado final,<br/>observável na cena"]
E --> V["Conferência do modelo:<br/>peça órfã, encaixe órfão,<br/>encaixe citado que não existe"]
V --> Q["Duas frases em português,<br/>antes de qualquer polígono"]
E --> D["A especificação:<br/>14 seções em quatro blocos"]
D --> F["Toda frase admite<br/>ser contrariada por medida"]
1.6.2 O modelo que se confere sozinho
Escritas a tarefa, o inventário e o estado final, aparece uma classe de erro que não é de digitação nem de lógica: a inconsistência do modelo. Uma peça que não encaixa em lugar nenhum. Um encaixe declarado que nenhuma peça usa. Uma peça que aponta para um encaixe que o suporte não declara. Nenhum dos três impede o programa de rodar. Todos produzem, mais adiante, um ambiente em que a pessoa tenta concluir a tarefa e não consegue, sem que apareça erro nenhum na tela.
Execute um deles até o fim. Suponha cinco peças e cinco encaixes, e que alguém tenha chamado um encaixe de topo na lista do suporte e de tampa na lista da peça correspondente. Duas palavras razoáveis para a mesma coisa. No fim das contas, o programa carrega o modelo sem reclamar e monta a cena. A peça que deveria fechar o mecanismo nunca encaixa — o encaixe que ela cita não existe, e o encaixe que existe não recebe peça nenhuma. Dois defeitos, uma origem, zero mensagens.
a conferência do modelo, em dominio/dominio.ts
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;
}Com a conferência no lugar, o mesmo modelo produz duas frases antes de qualquer coisa ser desenhada. O defeito deixa de ser uma frustração no fim e vira duas mensagens de texto no começo. Repare no que a função devolve: uma lista de frases em português, e não um valor booleano. Um false informa que há defeito e obriga quem lê a caçar qual. A frase diz o nome da peça e o nome do encaixe — é isso que permite consertar sem abrir o depurador. O que ela não verifica também informa — ordem dos passos, razoabilidade das folgas, interesse da tarefa, nada disso. Verifica coerência interna do modelo, e a pobreza da verificação é o que a torna executável antes de existir cena, geometria ou interação.
Vai aqui um juízo meu, com a conta junto: prefiro que ela rode sempre, na abertura do ambiente, e não apenas num teste automatizado. São alguns milissegundos por execução, com um resultado que quase sempre é uma lista vazia. Aceito a troca de bom grado. O teste que roda em outro lugar é o teste que alguém desliga na semana em que ele atrapalha. E o modelo inconsistente atravessa capítulos inteiros até que a peça não encaixe diante de outra pessoa.
1.6.3 A frase que pode estar errada
Uma especificação de projeto é um documento em que toda frase pode estar errada. É o critério inteiro, e ele se aplica frase a frase, com o dedo na tela: aquela afirmação admite ser contrariada por alguma observação futura? “A peça encaixa com folga de dois centímetros” admite, porque basta medir e dar três. “A experiência será fluida e envolvente” não admite coisa alguma. A segunda é uma não-frase com formatação de frase, e a diferença cobra caro — uma frase ruim se conserta, uma não-frase se apaga. Especificação sem número é intenção com formatação melhor.
A forma que um documento desses assume se repete de projeto para projeto. São quatorze seções em quatro blocos, que respondem, nesta ordem, pela cena, pelas regras, pela máquina e pelo trabalho. A cena diz o que existe, em quantos exemplares e com que tamanho em metros. As regras dizem o que a pessoa faz, quando a tarefa está concluída e com que tolerância. A máquina diz o que acontece nos diferentes regimes e o que sai primeiro quando não couber. O trabalho diz de onde vem cada ativo, em que ordem se constrói e o que ainda está em aberto.
A ordem dos blocos vem da mesma aritmética do custo de correção. Cena e regras se reescrevem enquanto não houver geometria. A máquina só se decide depois de haver o que medir, e o trabalho depende dos três anteriores. O bloco da cena guarda o item que mais se esquece, e ele é uma coluna de números — o tamanho de cada objeto em metros. Sem isso o inventário é uma lista de nomes, e listas de nomes atravessam projetos inteiros sem que ninguém compare a peça de cinco centímetros com a bancada de dois metros. A unidade tem de estar escrita, porque a palavra “unidades” é o lugar onde a escala vai se perder mais adiante.
as tolerâncias de encaixe, em docs/especificacao.md
| Encaixe | Folga de posição | Folga de ângulo | Por quê |
| --- | --- | --- | --- |
| Corpo na base | 3,0 cm | 15° | peça grande, encaixe único, sem vizinho para confundir |
| Eixo no furo | 1,5 cm | 10° | furo estreito; folga maior faria o eixo saltar sozinho |
| Engrenagens nos dentes | 2,0 cm | 8° | os dois encaixes são vizinhos, e folga grande troca um pelo outro |
| Tampa no topo | 3,0 cm | 20° | último passo; apertar aqui só produz irritação |
Todos os valores são **provisórios** e serão medidos no aparelho. O que se sabe
antes de medir é a forma do erro nos dois extremos: folga grande demais faz a peça
saltar para o lugar sem que a pessoa tenha acertado, e a montagem perde sentido;
folga pequena demais transforma o encaixe em tortura de precisão. O valor final é
o que sobreviver a esse intervalo, e o registro do que foi testado antes de
escolhê-lo vale tanto quanto o número escolhido.Nenhum desses valores foi medido. Estão escritos como provisórios, com a razão de cada um ao lado, e serão conferidos no aparelho. Poderia parecer que escrever número não medido é pior do que não escrever número nenhum, e é o contrário: o número provisório é falseável, e a medição futura pode contradizê-lo. A ausência de número não pode ser contrariada por medição nenhuma.
O que se sabe antes de medir é a forma do erro nos dois extremos, e isso é conhecimento de verdade. Folga grande demais faz a peça saltar para o lugar sem que a pessoa tenha acertado, e a montagem perde o sentido. Folga pequena demais transforma o encaixe numa prova de pontaria. O valor final é o que sobreviver a esse intervalo. Repare na coluna da direita. Ela não repete o valor: diz por que aquele valor e não outro, e é esse tipo de razão que sobrevive quando o número mudar.
1.7 O primeiro estado da Bancada
Uma página que não desenha nada, e responde diferente em três aparelhos.
O ambiente que atravessa este livro chama-se Bancada: uma oficina de montagem servida em três regimes pela mesma URL. 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 — no monitor com o mouse, no visor com as mãos, ou depositado sobre uma mesa física da sala.
Neste ponto do percurso ela não desenha um polígono. O que existe é o vocabulário deste capítulo escrito como dado, e uma página que o confronta com o aparelho em que está aberta.
O domínio inteiro cabe num arquivo. Cinco peças — corpo, eixo, engrenagem grande, engrenagem pequena, tampa — e cinco encaixes no suporte: base, furo do eixo, dente maior, dente menor, topo. A tarefa em uma frase, o estado que a caracteriza concluída, e a lista de onde cada peça serve.
a delimitação escrita como dado, em dominio/dominio.ts
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'] },
Os identificadores de peça e de encaixe são tipos de união literal. Isso tem uma consequência que aparece na primeira vez que alguém digita errado: um nome inventado é recusado antes de qualquer execução, com o erro apontando para a linha em que ele foi escrito. Um nome inventado guardado num documento de texto, em vez disso, só apareceria no dia em que alguém fosse procurá-lo na cena e não achasse.
1.7.1 O que a página faz quando abre
Três coisas acontecem, nesta ordem, e a ordem foi escolhida.
Primeiro roda a conferência do domínio: peça órfã, encaixe órfão, encaixe citado que o suporte não declara. Ela vem antes de tudo porque o percurso inteiro se apoia nesse modelo, e um modelo inconsistente contamina cada capítulo seguinte.
Depois vem o levantamento de suporte, que é assíncrono — perguntar ao navegador quais regimes ele aceita é consulta ao aparelho, e não leitura de constante. Por último, a montagem do relatório, que recebe os dois resultados já prontos e não sabe nada sobre regimes.
O relatório sai em texto comum na página, e isso é provisório declarado como provisório. O painel definitivo da Bancada será diegético: um cartaz preso à própria bancada, lido de dentro do mundo. Ele não pode existir agora pelo motivo mais simples possível — não há mundo. O arquivo diz isso em comentário, porque um provisório sem nota vira decisão de projeto três capítulos adiante, e alguém gasta uma tarde tentando conciliar dois painéis que nunca deveriam coexistir.
Abra a mesma URL no computador do laboratório, no celular e no visor, e a última coluna do relatório muda em cada um. É a evidência mais barata deste ponto do percurso, e a única que produz fato em vez de argumento.
1.7.2 Os números que já estão escritos, e ainda não foram medidos
A especificação da Bancada mora em docs/especificacao.md, ao lado do código e no mesmo histórico de versões, com quatorze seções em quatro blocos: a cena, as regras, a máquina e o trabalho. Duas delas fixam números que nenhum aparelho confirmou ainda.
A primeira é a das folgas de encaixe. A segunda é a ordem de degradação, que responde à pergunta que ninguém quer fazer no começo: se não couber na máquina, o que sai primeiro?
a ordem de degradação, em docs/especificacao.md
**Ordem de degradação** — o que sai primeiro quando não couber:
1. as seis ferramentas de cenário, que não têm função na tarefa;
2. o chão e as paredes, substituídos por um plano liso;
3. o detalhe dos dentes das engrenagens, que caem para uma forma simplificada;
4. a bancada importada, substituída pela caixa paramétrica que ela representa.
O que **não** sai em nenhum caso: as cinco peças, os cinco encaixes e o retorno
visual do encaixe. Degradar até perder a tarefa não é degradar, é desistir.
A ordem tem uma lógica, e ela é a distância até a tarefa. Sai primeiro o que não participa dela. Depois o ambiente em volta. Depois o detalhe do que participa. E por último o objeto importado, substituído pela forma paramétrica que ele representa — a linha mais dolorosa da lista, porque desfaz a contramedida que existia para impedir a cena de ser inteiramente construída por código.
O que não degrada está em negrito de propósito: as cinco peças, os cinco encaixes e o retorno visual do encaixe. É onde essa lista costuma se perder. Cortando sempre na direção do que é fácil de cortar, chega-se, sem nenhum passo obviamente errado, a um ambiente que abre, roda liso e não sustenta mais a tarefa que o justificava.
1.8 O que já está decidido antes de existir um polígono
Nada disto desenha um polígono, e mesmo assim já decide o que o resto vai poder fazer.
Volte às duas pessoas do começo. No fim das contas, elas nunca estiveram em categorias diferentes: descreviam duas posições no mesmo eixo, produzidas por duas escolhas de espaço de referência e duas escolhas de composição do fundo. O que parecia diferença de categoria era diferença de quatro campos preenchidos, e nenhum deles custa uma linha de código. As duas linhas de configuração da primeira página agora têm nome. Uma escolhia entre a origem arbitrária da cena e o chão do espaço físico, e a outra, entre esconder o mundo e deixá-lo passar.
Cinco coisas passam a estar ao seu alcance. Situar um sistema no contínuo pelo que ele faz com o ambiente de quem observa. Separar imersão, presença e registro, sabendo em qual das três a fidelidade visual entra e em qual ela não entra. Dizer, diante de um ambiente qualquer, contra o que a cena está registrada e quem decidiu a origem do mundo virtual. Delimitar um domínio pela tarefa, pelos objetos e pelo estado final. E escrever uma especificação em que cada frase possa estar errada. Nenhuma delas depende de biblioteca, de linguagem ou de aparelho, e todas continuarão valendo quando o equipamento que está hoje na prateleira estiver num museu.
Repare também no que ficou de fora, escolhido um a um: qualidade de imagem, contagem de triângulos, formatos de arquivo, bibliotecas. Um ambiente com o espaço de referência errado não fica menos errado com material melhor. E fica a pergunta que Brooks deixou implícita no balanço de 1999, a mais barata de fazer. Diante de qualquer demonstração que impressione — a sua, a de outra pessoa, a de um fabricante numa feira —, pergunte como o sistema descobriu onde estava o chão. Quem responde tem um sistema. Quem não responde tem uma demonstração.
O que vem agora sai do papel para o repositório: as três decisões destas páginas, escritas onde elas podem ser cobradas.
Tarefa 1: Escolher a cena e delimitar o domínio
O ambiente que acompanha a leitura precisa de uma cena antes de precisar de uma linha de código, e a cena não é escolha de gosto: cada uma endurece uma parte diferente do trabalho e amolece outra. Serve qualquer cena em que objetos sejam selecionados, movidos, orientados e postos em algum lugar certo — uma das propostas no Projeto Integrador, com o custo já mapeado ao lado, ou uma inventada do zero, desde que ela responda em duas linhas cada às quatro perguntas que fecham aquela lista: o que se faz ali com as mãos que não seja apertar botão, o que muda de verdade quando o ambiente vai para o visor, o que ele precisa provar contra uma mesa de verdade, e que número ele produz que possa sair diferente do esperado, contra qual alternativa.
O que fica pronto é a cena escolhida com a razão da escolha escrita em termos de custo — que parte do trabalho ela endurece, e qual é a armadilha que ela traz junto —, mais a delimitação do domínio: 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. Escolher é também a única decisão do percurso cara demais para desfazer no meio: trocar de assunto depois que o ambiente começou a existir custa o que já foi construído.
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.
Tarefa 3: Especificar o projeto em quatorze seções
A cena escolhida e os regimes declarados respondem por onde o projeto começa, e não pelo que ele será. O resto das decisões — quantos objetos existem, de onde eles vêm, que tamanho têm em metros, o que o ambiente aceita, o que recusa e como avisa, quanto disso cabe na máquina e o que sai primeiro quando não couber — ou é decidido por escrito agora, ou é decidido por acidente depois, com o ambiente meio construído e a decisão custando o dobro.
O que fica pronto é um documento em Markdown, em docs/especificacao.md, versionado junto do código, com quatorze seções em quatro blocos: a cena (identificação, experiência, inventário de objetos, escalas em metros), as regras (ações, tarefa e validação, tolerâncias de encaixe em centímetros e graus, retorno ao usuário), a máquina (os três regimes lado a lado, orçamento e ordem de degradação, comportamento quando dá errado) e o trabalho (origem e licença de cada ativo, plano de construção por blocos, riscos e decisões em aberto). A declaração de regime da tarefa anterior é a espinha de uma dessas seções, e não se reescreve: entra como está.
O teste de cada frase do documento é mecânico e implacável — ela pode estar errada? “A peça encaixa com folga de dois centímetros” pode, e por isso serve. “A experiência será fluida e envolvente” não pode, e por isso não diz nada. Especificação sem número é intenção com formatação melhor.