Tiki3d

O briefing

A Soarscape é uma empresa de levantamento 3D com centro de processamento próprio e software próprio. Esse software roda no Windows, e o problema era exatamente esse. O fundador queria levar o negócio para o mercado internacional e precisava de algo para mostrar, e os concorrentes estavam indo atrás da mesma ideia ao mesmo tempo. Software de desktop que precisa ser instalado não funciona bem como pitch.

Ele me chamou para construir o Tiki3d, o produto no navegador: subir uma captura em Gaussian splat, fazer a limpeza, montar um tour de câmera e mandar um link. Liderei o trabalho de web 3D de ponta a ponta, do pipeline de renderização às ferramentas de autoria e ao viewer que os clientes veem, e lançamos em cerca de quatro meses.

Copiando o PlayCanvas de propósito

Antes de fazer qualquer coisa sofisticada, o viewer precisava passar a sensação certa. O amortecimento da órbita, a curva do zoom, o jeito como a câmera se acomoda depois que você solta o mouse: se isso estiver errado, uma cena fotorrealista continua parecendo quebrada. Já vi gente chamar um renderer de "travado" com o frame rate em dia e só o easing fora do lugar.

Em vez de ajustar essas constantes no chute, li o código-fonte do viewer do PlayCanvas e portei direto para o nosso código as partes que definem a sensação da câmera. A equipe deles já tinha resolvido isso, o código estava lá para quem quisesse ler, e o meu trabalho era lançar um produto em quatro meses. Prefiro herdar um problema resolvido a descobrir tudo de novo. O mesmo raciocínio guiou o editor de modelos, onde refiz as ferramentas de seleção seguindo o comportamento do editor oficial, em vez de inventar minhas próprias convenções.

Essa decisão tem um custo real. Carregamos código que não escrevemos e que não dá para atualizar só subindo uma versão, então, quando o PlayCanvas mexe na parte interna da câmera, fazemos o diff na mão. Assumi esse custo conscientemente.

Ferramentas de seleção direto na nuvem de pontos

O editor de modelos tem Lasso, Brush e Polygon, além de Delete e Hide. Shift adiciona à seleção, Ctrl subtrai. O Brush tem um slider de tamanho. Tudo isso funciona sobre a própria representação em splats, sem nenhuma malha proxy no lugar.

Editar capturas é um trabalho sem glamour e constante. Scans reais chegam com uma cerca que você quer tirar, a janela de um vizinho que você não pode publicar, ruído solto no ar por causa de uma passada ruim. Cada um desses casos precisa de uma pessoa com um pincel, não de um algoritmo.

A parte que mais me importa é o botão Save as New. Apagar um milhão de splats é destrutivo, e um topógrafo que corta demais não deveria perder a captura. Salvar como um novo modelo mantém o original intacto, então as pessoas experimentam em vez de ficar pisando em ovos.

Medição, que é todo o argumento de negócio

Equipes de marketing querem um tour bonito. Topógrafos querem saber a distância entre duas coisas, e é esse número que decide se a plataforma é um brinquedo.

A medição por clique roda sobre a nuvem de splats, então as distâncias vêm da geometria capturada, e não de uma versão simplificada. É essa feature que faz o Tiki3d deixar de ser um viewer e virar algo pelo qual uma equipe de levantamento paga.

Animação como dado, não como gravação

As cenas reproduzem tours de câmera, e eu construí a autoria desses tours no editor de cenas. Um tour é um conjunto de grupos, cada um com posições de câmera e alvos de lookat, e com uma configuração de transição por etapa para easings como ease-in-out.

Guardar os tours como dados estruturados, e não como vídeo renderizado, compensou duas vezes. O viewer e o editor leem o mesmo formato, então o que o autor vê ao percorrer o tour é o que o cliente recebe. E como um tour é um pedacinho de JSON ao lado de uma captura enorme, mudar um movimento de câmera não custa nada em armazenamento nem em reexportação.

Formatos, orçamentos e o trabalho chato de confiabilidade

O viewer e o editor leem assets em tiles (formato nosso), SOG, SOG-LOD e PLY. Dá para juntar vários modelos numa cena e ajustar a posição e a rotação de cada um no editor.

Duas decisões daqui eu repetiria. A primeira é a validação no upload: os arquivos são verificados na entrada, e uma captura malformada é rejeitada no upload, em vez de falhar depois num loop de renderização, onde o erro não significa nada para o usuário. A segunda é expor os controles de desempenho. O viewer mostra o dispositivo ativo, um preset de LOD e um orçamento de splats, então quem está num hardware fraco pode baixar o orçamento e manter uma cena utilizável, em vez de ver a aba morrer. O Colorize LOD continua no build como visualização de debug, porque diagnosticar problemas de LOD no olho é muito mais rápido do que raciocinar sobre eles.

O que eu mudaria

O código de câmera portado é o que não sai da minha cabeça. Foi ele que nos fez lançar no prazo, e hoje é a parte menos portável do sistema. Se eu refizesse o Tiki3d, colocaria esse comportamento atrás de uma interface nossa desde o começo, para que a implementação emprestada ficasse numa caixa só, fácil de trocar, em vez de se espalhar pelo viewer.

Todo o resto eu manteria, principalmente a escolha de tratar edição e medição como features de primeira classe. A maior parte do trabalho com splats na web para em renderizar algo fotorrealista no navegador. Deixar as pessoas cortarem, medirem e dirigirem a cena foi o que fez do Tiki3d algo que a Soarscape podia colocar na frente de um mercado internacional, e não só mais uma demo.