Projeto Integrador

Um ambiente que três aparelhos diferentes abrem pelo mesmo endereço

Aqui se constrói um mesmo ambiente que sobrevive a três formas incompatíveis de ser olhado.

Quantas vezes um objeto tridimensional precisa ser programado para existir numa janela, dentro de um visor e pousado sobre uma mesa real? A resposta intuitiva é três. A resposta que este percurso persegue é uma.

O projeto que acompanha esta obra é um ambiente interativo servido em três regimes pelo mesmo endereço. Quem o abre no computador vê uma cena numa janela, girada pelo cursor. Quem o abre num visor entra nela em escala real. Quem o abre no celular a vê apoiada sobre uma superfície do próprio cômodo.

O domínio é escolha de quem constrói. Uma oficina de montagem, um laboratório de instrumentos, um jogo de encaixe, uma maquete arquitetônica: qualquer cena em que objetos sejam selecionados, movidos, orientados e posicionados serve. O que não é escolha é a estrutura por baixo dela.

A economia que sustenta o percurso. Existe uma camada que traduz cursor, controle rastreado e toque numa mesma noção de apontar. A lógica que decide o que foi selecionado, o que está sendo segurado e onde a peça encaixou não sabe qual dos três está em uso. É essa economia que torna os três regimes comparáveis, em vez de justapostos.

Construir isso enquanto se lê tem um efeito que a leitura sozinha não produz. Cada capítulo enuncia uma restrição — o orçamento de quadro, a escala corporal, o conforto, a estabilidade do registro — e o ambiente próprio de quem lê é onde essa restrição vira número. O capítulo diz que quadros perdidos causam mal-estar; o visor de quem construiu é que diz quantos.

A obra traz, em paralelo, uma implementação de referência completa. Ela é o exemplo resolvido: está ali para ser estudada, comparada e contestada, nunca copiada. Divergir dela é legítimo — desde que quem divergiu saiba dizer por quê.

O apoio dessa referência diminui de propósito ao longo da leitura. Nos primeiros capítulos ela mostra a estrutura quase inteira, e o que se pede é reproduzir com variação. Nos últimos ela mostra o critério, e o desenho fica por conta de quem constrói.

Esse desvanecimento tem um nome antigo e uma razão prática. Estrutura demais no início sobrecarrega; estrutura demais no fim mantém dependente. O ponto de equilíbrio é aquele em que a próxima camada ainda assusta um pouco e mesmo assim sai.

Construir junto muda o que se lê. Um capítulo lido antes de existir código é informação. O mesmo capítulo lido com o ambiente aberto ao lado vira diagnóstico: a frase que parecia genérica passa a explicar exatamente o comportamento estranho da tela. Ler e construir em paralelo é o método, não uma sugestão de ritmo.

Onde este ambiente roda, e por que isso restringe o projeto

A plataforma não é detalhe de configuração: ela decide o que a cena pode custar e quem consegue abri-la.

O ambiente vive no navegador, sobre a interface de realidade estendida que ele expõe. Três classes de aparelho o alcançam: o computador comum, o visor autônomo pelo navegador embarcado e o celular com câmera. Nada é instalado, nada é empacotado para uma loja, nada exige cabo.

Isso tem um preço, e ele aparece cedo. A interface de sessão imersiva só existe em contexto seguro, o que significa endereço servido sob conexão cifrada. Um ambiente perfeito, aberto por um endereço comum, simplesmente não entra em sessão — e a mensagem de erro raramente diz isso com clareza.

Um aparelho está fora, e é melhor saber antes. O navegador de um dos sistemas móveis mais difundidos não implementa a interface de realidade estendida. Quem depender dele para o regime imersivo descobrirá isso na pior hora possível. O caminho por marcador impresso existe justamente para que nenhum aparelho fique sem nada para mostrar.

flowchart LR
    U["Um endereco unico"] --> S{"O que este<br/>aparelho declara?"}
    S -->|"nenhuma sessao"| D["Janela no desktop:<br/>camera em orbita,<br/>ponteiro do cursor"]
    S -->|"sessao imersiva"| V["Visor:<br/>escala real,<br/>raio do controle"]
    S -->|"sessao sobre o real"| A["Camera:<br/>objeto pousado<br/>na superficie fisica"]
    D --> M["A mesma logica<br/>de montagem"]
    V --> M
    A --> M

A máquina prevista é modesta de propósito: processamento gráfico integrado, sem placa dedicada. Essa modéstia é o que dá sentido ao orçamento de cena. Contar triângulos e chamadas de desenho só vira competência quando existe um teto real a respeitar.

O regime em janela é o caso base. Roda em qualquer máquina, sem equipamento algum, e é para onde tudo o mais degrada quando o aparelho não oferece melhor.

O regime imersivo é onde a escala aparece. A mesma cena que parecia correta na tela revela, no visor, que a bancada está na altura do peito e as peças têm o tamanho de um armário.

O regime sobre o real é onde o registro é cobrado. Um objeto apoiado numa mesa física precisa continuar ali quando quem observa anda em volta.

Duas escolhas de ferramenta ficam de fora, e as duas por decisão de conteúdo. Motores de jogo completos resolvem sozinhos quase tudo o que este percurso ensina a resolver. Bibliotecas auxiliares de alto nível entregam agarre e deslocamento prontos, e o que elas entregam pronto é justamente o assunto.

A abstração de apontar não pode vir de fora. Se a camada que unifica cursor, controle e toque chega pronta numa dependência, o projeto perde o único trecho em que os três regimes se encontram. Usar a biblioteca é razoável em produção; aqui ela apaga o que se estava construindo.

O que continua legítimo é a biblioteca de renderização e o carregador de formato de troca. A fronteira é simples de enunciar: o que desenha triângulos e lê arquivos pode vir pronto, o que decide o que o usuário está fazendo, não.

Há ainda um emulador de navegador que simula a entrada em sessão e a geometria da cena. Ele resolve o ciclo de sessão e não resolve mais nada. Conforto, escala corporal e registro contra superfície física exigem o aparelho — usar o emulador como prova desses três é engano documentado.

O que cada etapa do percurso acrescenta ao artefato

Nenhuma etapa produz um exemplo descartável: cada uma deixa o mesmo ambiente um pouco mais capaz do que estava.

O artefato é um só, do começo ao fim. Isso tem uma consequência incômoda e útil: uma lacuna deixada para trás reaparece adiante, em vez de sumir. A camada de entrada mal desenhada na parte sete cobra o preço na parte dez, quando o regime imersivo vira um segundo programa em vez de um segundo caminho de entrada.

flowchart TD
    subgraph AR1["Saber onde a maquina esta"]
        E1["Contínuo entre<br/>sintetico e real"] --> E2["Dispositivos e<br/>graus de liberdade"]
    end
    subgraph AR2["Construir o ambiente e pagar por ele"]
        E3["Grafo de cena"] --> E4["Modelagem"] --> E5["Ativos e orcamento"] --> E6["Regime nao imersivo<br/>entregue"]
    end
    subgraph AR3["Interacao como camada"]
        E7["Ponteiro e selecao"] --> E8["Agarre e encaixe"] --> E9["Ciclo de sessao"]
    end
    subgraph AR4["O mundo ganha corpo"]
        E10["Presenca, escala<br/>e conforto"] --> E11["Locomocao"]
    end
    subgraph AR5["Do sintetico ao fisico"]
        E12["Registro e ancoragem"] --> E13["Marcador e<br/>degradacao"] --> E14["Integracao"]
    end
    AR1 --> AR2 --> AR3 --> AR4 --> AR5

Todas as etapas adiante têm trabalho de construção. Nenhuma é puramente expositiva — nem a mais conceitual, que se resolve num artefato executável.

O contínuo entre o sintético e o real

O ambiente ainda não existe, e já há o que decidir. Esta etapa fixa o vocabulário do projeto por escrito: o que o ambiente vai substituir, o que vai sobrepor, contra o que vai se registrar.

O que fica pronto é a definição do domínio da cena, com a distinção declarada entre o que será visto num mundo próprio e o que será depositado sobre o mundo de quem observa. Essa distinção precisa sobreviver ao projeto inteiro como comportamento observável, não como rótulo.

Dispositivos, rastreamento e graus de liberdade

A primeira coisa executável do projeto não desenha nada. É a sonda que pergunta ao aparelho o que ele oferece — sessões suportadas, recursos opcionais, fontes de entrada, graus de liberdade — e escreve a resposta em algum lugar visível.

A etapa está concluída quando o mesmo endereço, aberto em três aparelhos distintos, produz três relatórios distintos. É o momento em que “dispositivos” deixa de ser tópico narrado e vira tópico observável.

Grafo de cena e laço de renderização

Aqui nasce a estrutura que sustenta todo o resto. A cena vira árvore de objetos com transformação própria, e o laço que a desenha passa a rodar contra um relógio, não contra a velocidade da máquina.

O que fica pronto é a cena mínima girando, com a hierarquia usada de verdade: mudar um objeto de pai precisa reposicioná-lo sem que ninguém recalcule nada à mão. Essa operação é a que sustenta pegar, encaixar e soltar mais adiante.

Técnicas de modelagem de ambientes virtuais

A cena ganha os objetos que a compõem, construídos por código ou trazidos de fora e ajustados. Escala, orientação e composição são decisão de quem constrói, e é essa decisão que a etapa registra.

Uma separação passa a existir aqui e não desaparece mais: a forma que se vê e o volume contra o qual se colide raramente são o mesmo objeto. Quem descobre isso tarde passa a depurar colisões que acontecem no lugar errado.

Ativos, formatos de troca e orçamento de cena

Uma cena com quatrocentos parafusos pode custar quatrocentas chamadas de desenho ou uma só. Esta etapa é onde essa diferença deixa de ser teoria.

O que fica pronto é a cena completa, com os objetos repetidos tratados como repetição, com nível de detalhe onde ele compensa, e com o custo medido em número — triângulos e chamadas contados, não estimados. O teto é o da máquina mais modesta prevista.

Realidade virtual não imersiva

O regime mais fácil de subestimar fecha aqui, e fecha entregue. Câmera em órbita controlada pelo cursor, cena completa, tudo funcionando sem equipamento algum.

A etapa está concluída quando o ambiente é utilizável por quem não tem nada além de um navegador. Também está concluída quando quem construiu sabe enunciar o que falta ali: não há escala corporal, não há alcance de braço, e a profundidade é inferida em vez de vista.

A camada de interação: ponteiro e seleção

Este é o ponto de virada do projeto, e ele cabe numa frase. Nenhuma linha da lógica de manipulação pode saber se quem aponta é um cursor, um controle rastreado ou um dedo na tela.

O que fica pronto é a abstração de apontar — origem, direção, acionamento, estado — com implementações independentes para cada forma de entrada, e uma única lógica de seleção consumindo todas. O retorno visual entra junto: sem realce, ninguém sabe o que está prestes a pegar.

Manipulação, agarre e encaixe

Soltar uma peça a três centímetros do encaixe deve funcionar. Soltá-la a trinta, não. O número entre os dois é decisão declarada, e ele determina se o ambiente parece generoso ou frouxo.

A etapa fecha quando o usuário age sobre os objetos da cena, e não apenas sobre botões: pegar, orientar, encaixar, soltar. A tarefa passa a ter estado, com ordem validada e recusa explicada — recusar sem dizer por quê é o defeito de interface mais comum em ambiente tridimensional.

Tecnologias de desenvolvimento e o ciclo de sessão

O ambiente aprende a entregar o controle. Entrar em sessão, negociar recursos opcionais, escolher espaço de referência, devolver o controle ao sair: o laço de render deixa de ser seu e passa a ser regido de fora.

O que fica pronto é a fronteira desenhada com clareza entre o que a plataforma resolve e o que foi escrito à mão. Essa fronteira é o que se defende quando alguém pergunta o que exatamente o projeto implementou.

Realidade virtual imersiva: presença, escala e conforto

O mundo ganha corpo, e os erros de escala aparecem todos de uma vez. A cena nasce ancorada no piso, o alcance do braço vira restrição de projeto, e o que está longe demais precisa ser trazido para perto por decisão de desenho.

A etapa está concluída quando a montagem inteira é cumprível dentro do visor, com quadros estáveis. Conforto entra como requisito, não como acabamento: latência e aceleração têm consequência física, e quem constrói precisa saber demonstrar o caso ruim tanto quanto o bom.

Locomoção em ambientes imersivos

Mover alguém por um mundo virtual sem que o corpo se mova é o problema que mais separou soluções boas de ruins nesta área. A solução vencedora abriu mão do movimento contínuo.

O que fica pronto é o deslocamento discreto — salto para um ponto mirado, giro em passos, redução do campo periférico — mais o tratamento dos limites da área física real. A comparação com o movimento contínuo se faz por custo em conforto, com critério declarado, nunca por preferência.

Realidade aumentada: registro, detecção de superfície e ancoragem

Aqui o objeto digital pousa sobre uma mesa que existe. A cena passa a se registrar contra o que o aparelho detectou do ambiente, e não contra um sistema de coordenadas inventado.

A etapa fecha quando o objeto permanece onde foi posto enquanto quem observa caminha em volta. Fecha também quando a perda de rastreamento tem comportamento definido e visível — porque ela acontece em uso real, e o que o sistema faz nesse instante é parte do projeto.

Registro por marcador e degradação graciosa

Nem todo aparelho oferece sessão sobre o mundo real. A alternativa é mais antiga e mais frágil: um padrão impresso, reconhecido pela câmera, servindo de origem para o mundo virtual.

O que fica pronto é o caminho alternativo funcionando e a escolha automática do melhor regime disponível. A diferença de qualidade entre os dois registros é conteúdo a explicar, não defeito a esconder. E a mensagem para o aparelho que não suporta algo precisa ser honesta e informativa, jamais uma tela em branco.

Implementação e integração de ambientes virtuais e aumentados

Um endereço, três regimes, e a decisão de qual abrir tomada pelo próprio ambiente a partir do que o aparelho declarou. A última etapa costura tudo o que veio antes.

O que fica pronto é o artefato completo, com o painel de informação dentro da própria cena e a documentação das decisões que o formaram. O fecho cobra a explicação do funcionamento acima da vistosidade do resultado — e é essa a competência que o percurso inteiro esteve construindo.

Como o trabalho se organiza no repositório

Um projeto que ninguém consegue executar a partir do que está escrito é um projeto que não existe fora da máquina de quem o escreveu.

O ambiente mora num repositório com três lugares, e cada um responde a uma pergunta diferente.

flowchart TD
    R["raiz do repositorio"] --> RM["README.md<br/>o que e, como se executa,<br/>o que ja funciona"]
    R --> DC["docs/<br/>decisoes de projeto,<br/>medicoes, limites conhecidos"]
    R --> SR["src/<br/>o ambiente em si"]
    SR --> S1["a cena e o que ela custa"]
    SR --> S2["a entrada, abstraida"]
    SR --> S3["a tarefa que o usuario cumpre"]
    SR --> S4["a escolha de regime"]

O arquivo de apresentação na raiz responde à pergunta de quem chega: o que é isto, como se põe para rodar, o que já funciona e em quais aparelhos foi visto funcionando. Ele é a primeira coisa lida e a última atualizada, e essa inversão é o motivo de tantos repositórios mentirem sobre si mesmos.

A pasta de documentação guarda o que o código não diz. As decisões tomadas e as descartadas, os números medidos, os limites conhecidos, a razão de cada tolerância escolhida. É ali que mora a resposta para “por que assim”, e é dela que sai qualquer explicação sustentável do projeto.

A pasta de fontes guarda o ambiente. Vale mantê-la dividida pelas responsabilidades que o percurso foi acrescentando — a cena e seu custo, a entrada abstraída, a tarefa com estado, a escolha de regime —, porque essa divisão é a mesma que torna possível trocar uma peça sem mexer nas outras.

Três coisas merecem estar escritas ali desde cedo, porque são as que ninguém reconstitui depois. Os números medidos, com a máquina em que foram medidos. As tolerâncias escolhidas, com o que se testou antes de escolhê-las. E os aparelhos em que o ambiente foi de fato aberto, com o que funcionou em cada um.

A última é a mais esquecida e a mais valiosa. Um ambiente que roda em três regimes tem um comportamento por aparelho, e afirmar que “funciona” sem dizer onde é uma afirmação vazia. A tabela de aparelhos testados é o documento que separa o projeto verificado do projeto suposto.

Vale também escrever o que não funciona. Limites conhecidos, defeitos aceitos e o caminho que foi tentado e abandonado valem mais que a descrição do que deu certo — porque são exatamente o que a próxima pessoa tentaria de novo.

Registre o histórico enquanto ele acontece. Um repositório com um único registro contendo tudo perde a informação mais barata que existe: a ordem em que as decisões foram tomadas. Marcar o estado do ambiente ao fim de cada etapa custa segundos e devolve um percurso reconstituível.

O que caracteriza um bom resultado

Um ambiente tridimensional impressiona com facilidade — e essa facilidade é exatamente o que torna difícil julgá-lo.

Quatro propriedades separam um ambiente que percorreu o assunto de um que passou ao largo dele. Nenhuma se enxerga numa demonstração de meio minuto, e todas se verificam abrindo o artefato.

Os dois regimes de imersão navegam por caminhos diferentes. Existe um modo percorrido por tela, sem equipamento, e um modo percorrido dentro do ambiente, com a posição da cabeça rastreada. Um faz o que o outro não faz. A mesma cena com um rótulo trocado não são dois regimes.

A ancoragem no mundo real vem de rastreamento efetivo. O objeto virtual se localiza em relação ao que o aparelho detectou — superfície, marcador, posição —, e não em relação à tela. Um desenho fixo por cima da imagem da câmera usa a câmera como papel de parede, e não como sensor.

O usuário age sobre os objetos, e não apenas sobre a interface. Pelo menos parte da cena responde a uma ação exercida sobre o próprio conteúdo virtual: mover, girar, encaixar, colidir. Interação com menu já existe em qualquer aplicativo comum, e não é disso que o assunto trata.

A cena foi composta pelo projeto, não herdada intacta. Formato escolhido, escala ajustada, hierarquia montada, custo medido e empacotamento decidido. É o trabalho de levar conteúdo bruto até um ambiente que roda num aparelho concreto — e é ele que não aparece quando um modelo pronto é arrastado para dentro de uma cena pronta.

flowchart TD
    Q1{"Os dois regimes de imersao<br/>navegam de formas diferentes?"}
    Q1 -->|nao| X1["A mesma cena com<br/>outro rotulo"]
    Q1 -->|sim| Q2{"O objeto ancorado sabe<br/>onde esta a superficie real?"}
    Q2 -->|nao| X2["Desenho fixo sobre<br/>a imagem da camera"]
    Q2 -->|sim| Q3{"O usuario age sobre os<br/>objetos, e nao so sobre menus?"}
    Q3 -->|nao| X3["Ambiente que so<br/>se olha"]
    Q3 -->|sim| Q4{"A cena foi composta e<br/>ajustada por decisao propria?"}
    Q4 -->|nao| X4["O exemplo de demonstracao<br/>publicado como resultado"]
    Q4 -->|sim| OK["O ambiente responde<br/>pelos quatro"]

Vale enunciar o que não conta, porque as quatro formas mais comuns de esvaziar um projeto desses são todas plausíveis e todas passam despercebidas numa demonstração.

Construir só o ambiente imersivo e apresentar a mesma cena vista sem o visor como “a versão não imersiva” não produz dois regimes: produz um regime e um aparelho ausente. O simétrico vale igual — construir só o visualizador de tela e afirmar que a cena “suporta” imersão. Suporte teórico não é experiência construída e verificada no aparelho.

Fixar o objeto numa posição de tela sobre o vídeo da câmera parece registro e não é. Restringir toda a interação a botões e menus deixa o conteúdo da cena intocado. E publicar o objeto de demonstração que veio junto com a biblioteca como conteúdo final da cena é o caso mais tentador de todos, porque o resultado impressiona: nada foi modelado, importado ou ajustado, e o assunto inteiro passou ao largo.

O critério final é a explicação, não a imagem. Um ambiente que funciona sem que se saiba dizer por que funciona não sustenta nada. Como o sistema sabe onde está a superfície, por que a âncora deriva, o que muda no laço de render quando a sessão assume o controle: quem construiu responde a isso, ou não construiu.

Mostrar o que foi construído

A demonstração que impressiona e a demonstração que convence raramente são a mesma — e a diferença está na ordem.

Uma apresentação de ambiente tridimensional falha quase sempre pelo mesmo motivo: começa pelo efeito mais espetacular, que depende do aparelho mais capaz, que é justamente o que não funciona na hora.

flowchart LR
    P1["Abrir pelo caso base:<br/>a janela que sempre funciona"] --> P2["Mostrar a mesma peca<br/>apanhada de outro jeito"]
    P2 --> P3["Trocar de aparelho<br/>sem trocar de endereco"]
    P3 --> P4["Exibir o caso ruim<br/>e explicar a correcao"]
    P4 --> P5["Fechar pela decisao<br/>mais dificil do percurso"]

Comece pelo caso base. A janela no computador comum sempre abre, e ela já mostra a cena inteira, a tarefa inteira e o custo medido. Só depois troque de aparelho, e faça a troca sem trocar de endereço — é a economia do projeto ficando visível em um gesto.

O momento mais forte de uma demonstração dessas costuma ser a mesma ação repetida de outro jeito. A mesma peça apanhada pelo cursor, depois pelo raio do controle, depois pela mão que se fecha sobre ela a poucos centímetros do rosto. Uma ação, três formas, e a mesma lógica por baixo.

Exiba o caso ruim de propósito. Em conforto, o contraexemplo ensina mais que o exemplo: movimento contínuo com aceleração, quadros caindo, e o mal-estar aparecendo em segundos. Mostrar o defeito e em seguida a correção prova domínio de um jeito que nenhuma cena bonita prova. Faça isso por poucos segundos e com quem foi avisado.

Prepare a demonstração para falhar. Aparelho que não pareia, rede que cai, sessão que não abre: nada disso é raro, e o que distingue quem domina o assunto é ter o caminho seguinte pronto. O regime em janela é esse caminho, e ele nunca depende de nada.

Tenha um registro gravado do que exige aparelho. Uma captura da sessão imersiva e do objeto ancorado sobre a mesa cobre o caso em que o equipamento não colabora na hora. Ela não substitui a demonstração ao vivo; existe para que a explicação continue de pé quando a demonstração não continuar.

Fale enquanto mostra, e fale do que não está aparecendo. A tela exibe o resultado; a decisão que o produziu é invisível. Enquanto a peça encaixa, cabe dizer qual tolerância permitiu aquilo e o que acontece fora dela — é o tipo de comentário que transforma uma cena em argumento.

Antecipe as perguntas difíceis, porque elas são sempre as mesmas três. Como o sistema sabe onde está a superfície. O que acontece quando o rastreamento se perde. Por que o mesmo código roda em aparelhos que declaram capacidades diferentes.

Feche pela decisão mais difícil do percurso, não pela mais vistosa. A tolerância de encaixe que precisou ser calibrada, a ordem de degradação escolhida entre aparelhos desiguais, o objeto que precisou perder detalhe para caber no orçamento. Quem escuta se lembra da decisão explicada; a cena bonita, essa todo mundo já viu.

Como o Projeto Integrador se organiza na disciplina

O Projeto Integrador é desenvolvido em grupos de cinco estudantes, o que rende oito grupos na turma cheia. A composição é fixa ao longo do período: trocar de grupo no meio do percurso desmonta o histórico que a arguição individual precisa poder consultar.

Metade das aulas semanais é reservada à prática e à tutoria, em sala, com o professor presente. Nada é exigido fora do horário de aula, e nenhuma atividade proposta é alheia ao projeto — atividade que não faz o projeto avançar compete com ele pelo tempo de quem estuda.

flowchart LR
    T["Aulas teoricas<br/>metade da carga semanal"] --> P["Aulas de pratica<br/>e tutoria"]
    P --> G1["Par piloto e navegador<br/>rodizio curto de papeis"]
    P --> G2["Revisao entre pares<br/>de outro grupo"]
    P --> G3["Ponto de controle<br/>com o professor"]
    G1 --> D["Diario de atividades<br/>atualizado no fim da sessao"]
    G2 --> D
    G3 --> D

Dentro do grupo, a unidade de trabalho é o par, não o grupo inteiro. A cada trecho, um integrante digita e outro revisa, antecipa erros e pensa no passo seguinte, com os papéis girando em intervalos curtos. Um grupo de cinco se reparte em pares simultâneos trabalhando em peças distintas, e o integrante restante entra no rodízio de um par existente em vez de abrir frente própria.

Trabalho individual dentro do grupo é o que a técnica existe para impedir. O padrão que a tutoria vigia é o do grupo em que um integrante concentra a implementação e os demais assistem. Ele produz um bom artefato e quatro arguições ruins, e o custo cai sobre quem foi deixado de fora.

Nas sessões de tutoria, a intervenção do professor decresce ao longo do período. Nos primeiros módulos ela é próxima e frequente; nos últimos, restringe-se a perguntas sobre decisões já tomadas. É o mesmo desvanecimento que o material aplica ao exemplo resolvido, agora na condução.

Entregas parciais e diário de atividades

As entregas parciais acompanham os cinco blocos de módulos, e cada uma corresponde ao estado do artefato descrito nas etapas do percurso — não a um trabalho paralelo. O que se entrega é o repositório no ponto em que aquele bloco fecha, com o histórico de versões e a documentação das decisões correspondentes.

flowchart TD
    B1["Bloco A<br/>vocabulario declarado<br/>e sonda de capacidades"] --> B2["Bloco B<br/>ambiente completo<br/>no regime nao imersivo"]
    B2 --> B3["Bloco C<br/>interacao abstraida<br/>e tarefa com estado"]
    B3 --> B4["Bloco D<br/>ambiente imersivo<br/>com conforto tratado"]
    B4 --> B5["Bloco E<br/>registro no mundo real<br/>e degradacao graciosa"]
    B5 --> F["Entrega final<br/>na semana seguinte<br/>ao ultimo modulo"]
    F --> A["Arguicao individual"]

Cada entrega parcial é acompanhada de uma demonstração curta em aula, feita por um integrante sorteado no momento. O sorteio não é armadilha: ele existe porque a alternativa — o grupo escolher quem apresenta — sempre elege o mesmo, e a apresentação deixa de informar sobre os outros quatro.

O diário de atividades é individual e atualizado ao fim de cada sessão de tutoria. Registra o que aquele estudante fez naquela sessão, com que par trabalhou, o que travou e o que ficou pendente. É documento curto, de poucas linhas, e é a principal evidência de contribuição individual que a rubrica consulta.

Pontualidade compõe nota própria (10%). O critério é a entrega no ponto combinado do percurso, e não a qualidade do que foi entregue — essa é avaliada pelos demais critérios. Entrega atrasada de estado incompleto vale mais que entrega ausente: o bloco seguinte pressupõe o anterior, e o grupo que não fecha um bloco arrasta o débito até o fim.

A entrega final ocorre na semana seguinte ao último módulo e reúne o artefato completo, a documentação das decisões e a apresentação. Prazos absolutos seguem o calendário acadêmico vigente, divulgado no início do período.

Rubrica de avaliação do Projeto Integrador

A rubrica é publicada agora, antes de o trabalho começar, e é a mesma consultada na devolutiva. Ela avalia a resolução do problema e a qualidade técnica; nenhum critério é estético.

Os pesos dos componentes da nota são fixos. Na Avaliação Contínua, as entregas parciais em grupo valem 15%, a verificação individual por bloco de módulos vale 5%, o engajamento no estudo pelo aplicativo vale 20% e a pontualidade vale 10%. Na Avaliação Final, o produto do Projeto Integrador vale 20% e a arguição individual vale 30%.

Dentro da avaliação do produto, os cinco critérios adiante têm peso equivalente, com a contribuição individual medida por estudante e não por grupo.

Critério	Insuficiente	Adequado	Excelente
Domínio conceitual	O grupo usa o vocabulário da área sem distinguir os regimes por comportamento observável	Distingue os regimes e explica o que cada um faz e não faz no próprio artefato	Explica também por que cada decisão foi tomada e o que teria mudado sob outra escolha
Cobertura do problema	Um ou mais tópicos da ementa não têm objeto no artefato	Todos os itens do checklist adiante existem e funcionam no aparelho-alvo	Os itens existem, funcionam e são articulados entre si por uma decisão de arquitetura declarada
Qualidade técnica	A lógica de manipulação ramifica por aparelho; a cena não cabe no orçamento medido	A entrada é abstraída, a cena cabe no orçamento e os números estão medidos e registrados	Os limites foram testados, documentados e tratados, incluindo perda de rastreamento e aparelho sem suporte
Comunicação e documentação	O repositório não permite a terceiro executar o artefato	Apresentação e documentação permitem reproduzir e entender as decisões	A documentação registra também o que foi tentado e abandonado, com a razão
Contribuição individual	Participou, mas não sabe explicar a própria parte nem relacioná-la à teoria	Explica a própria parte e a liga ao conteúdo do módulo correspondente	Explica a própria parte, as escolhas do grupo e o efeito delas sobre o restante do artefato

A demonstração bonita não fecha critério algum. Um ambiente tridimensional impressiona com pouco esforço, e essa facilidade é armadilha avaliativa conhecida nesta área. A cobrança recai sobre a explicação do funcionamento — como o sistema sabe onde está a superfície, por que a âncora deriva, o que muda no laço de render quando a sessão assume o controle.

Cobertura da ementa exigida do projeto

O checklist adiante é o instrumento de verificação de cobertura, e ele alimenta tanto o critério de cobertura do problema quanto as perguntas da arguição. Os rótulos entre parênteses remetem às propriedades técnicas descritas no corpo do Projeto Integrador.

Tópico da ementa	O que precisa existir no projeto
Conceitos de Realidade Virtual e Realidade Aumentada	Distinção entre substituição do ambiente e sobreposição ao ambiente real, observável no comportamento e registrada na documentação
Dispositivos	Sensores reais do aparelho produzindo dado de mundo consumido pelo projeto (I2)
Interação em ambientes virtuais e aumentados	Ao menos uma ação do usuário sobre o conteúdo virtual da cena, distinta de navegação de interface (I3)
Técnicas de modelagem de ambientes virtuais	Composição de cena a partir de malhas e texturas importadas, com hierarquia, escala e transformação ajustadas pelo projeto (I4)
Realidade Virtual não imersiva	Modo de navegação por tela, sem visor, funcionalmente distinto do modo imersivo (I1)
Realidade Virtual imersiva	Modo com rastreamento de cabeça, funcionalmente distinto do modo não imersivo (I1)
Tecnologias para desenvolvimento	Domínio demonstrável da pilha além da configuração padrão: algo do processo foi decidido e ajustado pelo grupo (I4)
Implementação de ambientes virtuais e aumentados	Artefato executável de fato no aparelho-alvo, não maquete nem vídeo de conceito

Um item ausente não é “projeto menos completo”: é um tópico da ementa sem objeto. O checklist é conferido na entrega de cada bloco, e não apenas no fim, porque trocar o recorte do projeto no último módulo custa o percurso inteiro.

A arguição individual

A arguição individual vale 30% da nota, o maior peso isolado do período. Cada estudante defende a própria parte e explica as escolhas técnicas do grupo, individualmente, com o artefato aberto.

As perguntas partem do que o estudante registrou no diário e do que o repositório mostra. Pede-se que ele execute um trecho, explique por que aquilo foi feito daquele modo, diga o que aconteceria sob outra decisão e aponte o limite conhecido daquele trecho. Não se pede recitação de definição.

Uma boa defesa não depende de o estudante ter escrito o projeto inteiro. Depende de ele saber onde cada coisa está, por que está assim e o que a sua parte exige das demais. O integrante que trabalhou num par e conhece a peça vizinha por conversa com o colega está exatamente no ponto esperado.

Três perguntas aparecem em toda arguição, e vale conhecê-las desde já. Como o sistema decide onde o objeto pousa quando é depositado sobre uma superfície real. O que o artefato faz quando o rastreamento se perde. E por que o mesmo código roda em aparelhos que declaram capacidades diferentes.

A quarta pergunta é sempre específica do projeto daquele grupo, e sai da documentação que ele mesmo escreveu. Uma tolerância escolhida, um objeto simplificado para caber no orçamento, uma ordem de degradação decidida entre aparelhos desiguais: a decisão registrada é o material da arguição.

Para que serve este peso. A arguição existe para reconhecer quem trabalhou, e é isso que ela mede primeiro. O efeito secundário é o de impedir que um estudante atravesse o período sendo carregado pelo grupo — somada à verificação individual por bloco, ela responde por 35% da nota, o suficiente para que isso não passe.

Uso de ferramentas de IA e integridade acadêmica

No desenvolvimento do projeto, o uso de ferramentas de inteligência artificial é permitido e precisa ser declarado: que trecho foi apoiado, de que modo, e o que o grupo verificou depois. A declaração vai na documentação do repositório, junto das demais decisões.

O uso é vedado na arguição individual e na verificação individual por bloco, onde o que se avalia é a autoria própria. Delegar ali esvazia o instrumento e configura fraude acadêmica.

Código que o grupo não sabe explicar conta como não entregue, qualquer que seja sua origem. O critério é o mesmo para código copiado de terceiro, gerado por ferramenta ou escrito pelo colega ao lado: quem apresenta responde por ele.

Apresentar como próprio, sem declaração, o que foi produzido por terceiro ou por ferramenta é plágio, e recebe o tratamento previsto na política acadêmica em vigor. A regra é combinada agora, no início: regra que só aparece na correção é armadilha.

Há um caso particular que merece nome, porque nesta área ele é frequente. Modelos tridimensionais, texturas e cenas prontas circulam livremente e podem ser usados, desde que a origem seja declarada e a licença permita. O que não conta é publicar o objeto de demonstração que veio com a biblioteca como conteúdo próprio da cena — não por ser proibido, mas por deixar sem objeto o tópico de modelagem da ementa.

Declarar não reduz nota. A declaração de uso de ferramenta ou de ativo de terceiro é informação de projeto, e projetos reais são construídos assim. O que reduz nota é o grupo não saber explicar o que integrou — e isso a arguição encontra com ou sem declaração.