Caso de estudio 04 / 17JS Front-End
Arquitectura de renderizado en tiempo real para simular derrames en 3D
Rediseñé cómo llega a pantalla un modelo de derrames validado: física en un Web Worker, geometría creada una vez, avance ligado al frente.
Stack
- JavaScript
- CesiumJS
- WebGL
- Web Workers
- ImageBitmap
- Node.js
01 · Cómo funciona
- HoyaModificado en este trabajo
- Flujo de datos
Qué hace
Un gemelo 3D en el navegador, sin conexión, que muestra por dónde correría sobre el terreno real el fluido que escapa de un sistema de tuberías o de un canal, hasta dónde se extiende y con qué espesor se deposita.
Leer más
Funciona sin servidor y sin red, como herramienta guiada de escenarios para audiencias de ingeniería. Rediseñé el camino desde la salida de la simulación hasta los píxeles y dejé intacto un modelo físico ya validado.
5 conexiones· elige un componente para ver su recorrido
- Datos de la fuga a Worker: física + raster: punto, caudal, fluido
- Worker: física + raster a Hilo principal: ruta, espesor, halo raster
- Hilo principal a Forma en suelo + halo: construye geometría una vez
- Reloj de reproducción a Forma en suelo + halo: cada tick: solo atributosmodificado
- Forma en suelo + halo a Mapa 3D: dibuja sobre el terreno
02Resultados
- R01Cuanto más bajo, mejor
Rasterizado en el hilo principal, por escenario
Antes 1.7 s, después 0 s, a cero. Cuanto más bajo, mejor.AntesDespués - R02Cuanto más bajo, mejor
Mayor salto del frente de derrame por cuadro a 60 Hz, celdas
Antes 7, después 0.25, 28× menor. Cuanto más bajo, mejor.AntesDespués - R03Cuanto más alto, mejor
Píxeles físicos renderizados con escalado al 150 %
Antes 44%, después 100%, 2.3× mayor. Cuanto más alto, mejor.AntesDespués
Qué logró
- Arquitectura: física y renderizado en un solo hilo → física y rasterizado en un Web Worker, salida idéntica byte a byte, con respaldo en el hilo principal
- Rasterizado en el hilo principal por escenario: cerca de 1.7 s → 0
- Geometría del suelo: reconstruida en cada paso → creada una vez y actualizada solo por atributos
Leer más
- Reproducción: saltos del frente de hasta 7 celdas por cuadro → un avance constante de ¼ de celda, marcado por el propio frente
- Renderizado en pantallas escaladas: 44 % de los píxeles físicos → 100 %, con un depósito que se lee como suelo
- Superficie de la demo: nueve controles → cuatro más un menú
El desafío
El blanco obvio era el modelo. El perfilado apuntó a otra parte: convertir su salida en imágenes costaba unas 40 veces la física, todo en el hilo principal, con cada cuadro rasterizado como su propia capa de imagen y la geometría del suelo reconstruida en cada paso.
La reproducción tenía además un defecto de modelado. Un reloj lineal gastaba la mayor parte del avance del frente en los primeros instantes, así que el frente saltaba hasta siete celdas en un solo cuadro y luego se detenía, lo que tergiversa cómo se propaga una descarga.
Leer más
En pantallas escaladas el canvas renderizaba solo el 44 % de sus píxeles físicos, el depósito se leía como un brillo y no como suelo, y nueve controles se interponían entre la audiencia y el escenario.
Qué aprendí
Perfilar antes de tocar un modelo. El costo estaba aguas abajo, así que la decisión correcta fue dejar intacta una simulación validada y rediseñar a su alrededor; como nunca tocaba la página, pasó a un worker sin cambios, y una salida idéntica byte a byte demostró que el traslado era seguro.
Leer más
El ritmo de la reproducción es una decisión de modelado, no un detalle visual. Medí y descarté un sombreador de brillo húmedo y una reproducción más lenta. Las pruebas automáticas no ven una imagen: una revisión visual estructurada detectó cuatro fallas que todas las pruebas habían aprobado.
Stack
- JavaScript
- CesiumJS
- WebGL
- Web Workers
- ImageBitmap
- Node.js
Habilidades
- Arquitectura de renderizado
- Web Workers y concurrencia
- Visualización geoespacial 3D
- Diseño de reproducción de simulaciones
- Aseguramiento de calidad visual
