WebGL e Three.js

Shaders, não texturas

O fundo de nebulosa por trás deste globo não é uma textura — é um fragment shader a executar ruído fractal Brownian motion (fbm) em tempo real, combinado com uma segunda passagem de ruído para misturar duas paletas de cor sobre a esfera. As estrelas também não são sprites: cada uma é um ponto GPU renderizado com desvios de fase por vértice para que cintilem de forma independente, a uma fração das chamadas de desenho que um método baseado em sprites custaria.

Escrever shaders diretamente significa que o aspeto exato — cor, velocidade de movimento, esbatimento do brilho — é ajustável ao valor exato, sem ficar limitado ao que uma biblioteca de partículas pré-construída decida expor como opção.

Recursos reais, iluminação real

Os modelos 3D carregam como recursos GLTF/DRACO comprimidos, descodificados no lado do cliente, com um primitivo de reserva trocado até o modelo real terminar de ser transmitido — para que a cena nunca esteja vazia enquanto um recurso de vários megabytes carrega numa ligação lenta. Os materiais que chegam sem o seu próprio mapa de textura recebem um material padrão com valores ajustados de rugosidade/metalicidade/emissividade, em vez de serem renderizados planos e sem luz.

A iluminação é um pequeno conjunto deliberado — uma luz direcional principal, uma luz de contorno ténue do lado oposto — em vez de depender apenas da luz ambiente, o que é o que dá ao globo forma real em vez de parecer um círculo verde plano.

Uma câmara, decisões informadas

Cada cena WebGL que construo partilha uma única PerspectiveCamera entre todo o conteúdo renderizado, o que importa ainda mais quando uma cena tem várias partes em movimento (ver a entrada do diário sobre CSS3D) — uma única fonte de verdade para a posição e o campo de visão mantém tudo na cena, DOM ou WebGL, em verdadeiro acordo de perspetiva.