WebGL y Three.js

Shaders, no texturas

El fondo de nebulosa detrás de este globo no es una textura — es un fragment shader ejecutando ruido fractal Brownian motion (fbm) en tiempo real, combinado con un segundo paso de ruido para mezclar dos paletas de color sobre la esfera. Las estrellas tampoco son sprites: cada una es un punto GPU renderizado con desfases de fase por vértice para que titilen de forma independiente, a una fracción de las llamadas de dibujo que costaría un enfoque basado en sprites.

Escribir shaders directamente significa que el aspecto exacto — color, velocidad de movimiento, caída del brillo — es ajustable al valor exacto, sin limitarse a lo que una librería de partículas preconstruida decida exponer como opción.

Recursos reales, iluminación real

Los modelos 3D se cargan como activos GLTF/DRACO comprimidos, decodificados en el cliente, con un primitivo de respaldo intercambiado hasta que el modelo real termina de transmitirse — de modo que la escena nunca está vacía mientras un activo de varios megabytes carga en una conexión lenta. Los materiales que llegan sin su propio mapa de textura reciben un material estándar con valores ajustados de rugosidad/metalicidad/emisividad, en lugar de renderizarse planos y sin luz.

La iluminación es un pequeño montaje deliberado — una luz direccional principal, una tenue luz de contorno desde el lado opuesto — en lugar de depender solo de la luz ambiental, que es lo que le da al globo forma real en vez de parecer un círculo verde plano.

Una sola cámara, decisiones informadas

Cada escena WebGL que construyo comparte una única PerspectiveCamera entre todo el contenido renderizado, algo que importa aún más cuando una escena tiene varias partes en movimiento (ver la entrada del diario sobre CSS3D) — una sola fuente de verdad para la posición y el campo de visión mantiene todo en la escena, DOM o WebGL, en verdadero acuerdo de perspectiva.