El proyecto que demuestra el track entero
Un proyecto final con especificación completa, criterios de aceptación medibles y un plan de siete fases que atraviesa todas las decisiones del track.
Un track se cierra demostrando que se sabe hacer algo, no que se sabe contarlo. Este proyecto final está diseñado para que cada fase obligue a tomar una decisión distinta de las que has visto, y para que ninguna se pueda resolver copiando un ejemplo. Tiene una especificación concreta, criterios de aceptación que se miden con números y no con opiniones, y un plan por fases donde cada una produce algo que funciona. Al terminarlo tendrás una pieza de portafolio que un ingeniero sabrá leer, que es más de lo que puede decirse de la mayoría de las demostraciones bonitas.
- Ejecutar un proyecto completo con presupuesto y criterios de aceptación definidos de antemano.
- Atravesar en orden las decisiones de geometría, material, carga, integración, producción y accesibilidad.
- Verificar cada criterio con una medición reproducible, no con una impresión.
- Producir un artefacto defendible técnicamente, con sus compromisos documentados.
La especificación
Un configurador de producto en una página de comercio electrónico. No es el proyecto más vistoso, y está elegido a propósito: es el caso que más veces se encuentra un ingeniero en la vida real, es el que más restricciones tiene, y es donde la diferencia entre saber y no saber se nota inmediatamente.
Un objeto complejo (una bicicleta, una silla, una máquina de café) que el usuario puede rotar, del que puede cambiar tres o cuatro opciones (material, color, accesorios), y que tiene puntos de interés seleccionables con información asociada. Vive dentro de una página con texto y otros contenidos, no ocupa la pantalla entera, y tiene que funcionar en el móvil de gama media que el propio proyecto declare como objetivo.
Las restricciones son las que hacen el ejercicio:
| Criterio | Valor | Cómo se mide |
|---|---|---|
| Peso descargado hasta la primera interacción | Menos de 2,5 MB | Pestaña de red, caché vacía |
| Tiempo hasta interactivo en el dispositivo objetivo | Menos de 4 s en 4G | Perfilado con limitación de red |
| Fotogramas | 60 estables, percentil 90 bajo 20 ms | Ventana deslizante propia |
| VRAM de texturas | Menos de 120 MB | Auditoría de memoria |
| Llamadas de dibujo | Menos de 60 | renderer.info.render.calls |
| Fuga tras 20 montajes | Cero | renderer.info antes y después |
| Operable solo con teclado | Sí, al cien por cien | Recorrido manual sin ratón |
| Funciona sin WebGL | Sí, con contenido real | Aceleración desactivada |
| Respeta el movimiento reducido | Sí, sin perder información | Preferencia del sistema activada |
Ninguna de esas filas se puede responder con “creo que sí”. Esa es la idea.
Las siete fases
Fase uno: el HTML sin 3D. Se empieza por la alternativa, no por la escena. La página con el producto, sus imágenes por vista, los botones de configuración funcionando sobre esas imágenes, y la lista de puntos de interés como botones reales con sus descripciones. Tiene que ser una página completa y usable, que se pueda desplegar tal cual.
Empezar aquí no es un gesto de virtud: es lo que garantiza que la información existe en los datos y no solo en el grafo de escena, que es la condición sin la cual toda la accesibilidad posterior es imposible. Y sirve de sustituto durante la carga y en los dispositivos que no llegan.
Fase dos: el pipeline de assets. Antes de la primera línea de Three.js. El modelo se exporta a glTF binario, se comprime la geometría, se convierten las texturas a KTX2 con las dimensiones que exija el presupuesto, y se genera el manifiesto con rutas y tamaños. Al final de esta fase existe un script reproducible que convierte el modelo original en los ficheros que la web consume, y un número: cuánto pesa todo.
Si el número no cabe en el presupuesto, se corrige aquí. Corregirlo más tarde significa rehacer.
Fase tres: la escena mínima. La factoría con el contrato de cinco miembros, el registro de recursos, el ResizeObserver, la máquina de estados. El modelo cargado, una cámara con órbita, un mapa de entorno. Sin configuración, sin puntos de interés, sin post-procesado. Al final de esta fase la escena se monta y se desmonta veinte veces sin que renderer.info crezca, y ese es el único criterio para darla por buena.
Fase cuatro: la configuración. Cambiar material y color sin recrear nada. Aquí es donde se decide si las variantes son materiales distintos precargados o un material con uniforms, y la respuesta correcta depende de si cambian mapas (estructural, genera programas) o solo valores (uniforms, gratis). Al final de esta fase, cambiar de configuración no debe provocar ni una compilación de shader ni un pico en el tiempo de fotograma.
Es la fase que enseña más sobre claves de caché, porque el fallo se ve inmediatamente.
Fase cinco: la interacción y la accesibilidad. Los puntos de interés seleccionables desde la escena y desde los botones del DOM, llamando a la misma función. El canvas enfocable con foco visible, las flechas moviendo la cámara, Escape saliendo, Home restableciendo. La región viva anunciando los cambios. Y prefers-reduced-motion discretizando las transiciones de cámara en lugar de congelarlas.
Al final de esta fase se hacen las dos pruebas: recorrido completo con teclado desde la barra de direcciones, y recorrido con un lector de pantalla con los ojos cerrados.
Fase seis: la producción. La pantalla de carga con progreso ponderado por bytes, compileAsync antes de mostrar, la detección de capacidad con niveles de calidad, el manejo de la pérdida de contexto, el límite de tiempo en las descargas, y la degradación a la alternativa en los tres caminos de fallo. Al final de esta fase se prueban los fallos a propósito: sin aceleración, con red limitada al máximo, con el contexto perdido a la fuerza.
Fase siete: la integración y la verificación. La escena como isla, cargada en diferido cuando entra en el viewport, con el motor fuera del paquete inicial. Y el paso de verificación en la construcción que calcula la ocupación estimada de las texturas y falla si se pasa del presupuesto.
Al final, la tabla de criterios se rellena con números medidos, no con estimaciones.
Haz un despliegue al final de cada fase. Siete despliegues funcionando valen más que uno perfecto al final, porque cada uno se puede enseñar, medir y comparar con el anterior. Y si el proyecto se abandona en la fase cuatro, lo desplegado sigue siendo una página completa y usable, no un esqueleto.
Los compromisos que hay que documentar
Un proyecto técnico se juzga tanto por lo que hace como por lo que sabe explicar de por qué lo hace así. Cuatro decisiones de este proyecto tienen alternativas defendibles, y elegir una y escribir el porqué es parte del ejercicio.
Una escena por producto o una escena reutilizada. Un renderer compartido que cambia de modelo es más rápido al navegar y más complejo de gestionar. Una escena por producto es más simple y paga la creación del contexto en cada cambio. Con un catálogo de tres productos, la simplicidad gana; con trescientos, no.
Variantes de material precargadas o generadas. Precargar las cuatro combinaciones de material cuesta memoria y elimina el parón al cambiar. Generarlas bajo demanda ahorra memoria y produce un parón la primera vez que se elige cada una. Con cuatro combinaciones, precargar; con cuarenta, generar y guardar las usadas.
Sombras dinámicas u horneadas. Un producto sobre un fondo neutro con un mapa de entorno y una sombra de contacto barata se ve muy bien y cuesta casi nada. Una sombra dinámica proyectada cuesta una pasada de geometría y un mapa en memoria, y aporta poco si la iluminación no cambia.
Post-procesado o ninguno. Un poco de bloom sobre los materiales metálicos mejora el aspecto y cuesta una pasada de pantalla completa, que en el dispositivo objetivo puede ser un tercio del presupuesto. La decisión depende de la cifra, y la cifra hay que medirla.
En los cuatro casos la respuesta correcta es la que se puede justificar con el presupuesto declarado en la especificación. Ese es todo el criterio.
Cuando termines, haz una cosa más que casi nadie hace y que vale por todo el proyecto: escribe una página con lo que no hiciste y por qué. Los efectos que descartaste al medir su coste, la técnica que probaste y retiraste porque no cabía en el presupuesto, la optimización que resultó ser irrelevante porque el cuello estaba en otro sitio. Esa página es la que distingue a alguien que ha construido algo de alguien que ha seguido un tutorial, porque solo se puede escribir habiendo medido. Y es, con diferencia, lo que más se lee en una revisión técnica: el código enseña qué decidiste, y solo esa página enseña que decidiste.
Y después
El track termina aquí, pero el aprendizaje sigue en tres direcciones que se refuerzan entre sí, y merece la pena nombrarlas para no perder el tiempo en las que no.
Hacia abajo, al hardware. Todo lo que has aprendido sobre draw calls, overdraw y programas de shader es una aproximación a cómo funciona una GPU. Bajar a WebGPU sin Three.js, escribir un pipeline a mano y ver el modelo de comandos y de recursos sin abstracción cambia definitivamente la forma de leer el rendimiento. No es un requisito para hacer buenas escenas, y es el mejor uso del tiempo si el rendimiento te interesa.
Hacia arriba, al contenido. La limitación de la mayoría de las experiencias 3D no es técnica: es que el modelo, la iluminación y la composición no están bien resueltos. Aprender a usar una herramienta de modelado lo suficiente para preparar tus propios assets, hornear tu propia iluminación y controlar tus propios UV multiplica lo que puedes hacer más que cualquier técnica de render.
A los lados, a los fundamentos. Las matemáticas del principio del track no eran un trámite: son el vocabulario. Un dominio real de espacios de coordenadas, de proyección y de los conceptos de la teoría de señales que hay detrás del filtrado y del antialiasing es lo que permite leer un artículo técnico y aplicarlo, en lugar de esperar a que alguien lo empaquete en una librería.
Y una idea final que atraviesa los cincuenta y tres niveles. La restricción no es el enemigo del 3D en la web: es su forma. Ninguna experiencia web memorable lo es por la cantidad de técnica que lleva. Lo es porque alguien entendió el presupuesto, eligió dos cosas que hacer bien, y las ejecutó hasta que fueron impecables en el peor dispositivo que se propuso soportar. Eso es lo que separa un nivel dios de una demostración impresionante, y no tiene nada que ver con saber más shaders.
Empieza por la fase uno hoy mismo, sin abrir Three.js. Escribe la página del producto con sus imágenes, sus botones de configuración y sus puntos de interés, y despliégala. Cuando funcione entera sin una línea de 3D, tendrás la mitad del proyecto hecha y la parte que más cuesta añadir después. La escena tridimensional que va encima es, a partir de ahí, una mejora sobre algo que ya funcionaba.