Construyendo un mundo abierto en el navegador, parte 4: Streaming antes que terrenos sofisticados

Por Oleg Sidorkin, CTO y cofundador de Cinevva

¿Acabas de llegar? Consulta la guía de la serie. Explica qué es un spike y enlaza todas las partes.

El streaming es donde suelen venirse abajo los proyectos que «se ven bien».

Se pueden ocultar muchas cosas en una imagen estática. No se puede ocultar un tirón de 40 ms al cruzar el límite de un chunk.

Probamos deliberadamente el streaming antes de crear una representación avanzada del terreno. Así obtuvimos una señal clara sobre el comportamiento de carga y descarga.

El Spike 6 validó la renovación de los chunks vecinos con contenido sencillo.

Abrir el Spike 6 en una pestaña nueva ↗ · Ver código fuente

Después pasamos al sistema de terreno real en el Spike 11: streaming de chunks de altura, con decodificación en un worker y refinamiento progresivo mediante cuadrículas de 17, 33 y 65 muestras.

Abrir el Spike 11 en una pestaña nueva ↗ · Ver código fuente

El orden importó más de lo que esperábamos. Si hubiéramos empezado directamente con chunks de altura comprimidos, la causa de cada tirón habría sido ambigua: un problema de decodificación, de subida de texturas o de actualización de geometría. El Spike 6 eliminó una capa de incertidumbre antes de que el Spike 11 añadiera complejidad.

Una lección práctica de este capítulo se trasladó a los spikes posteriores. Las pausas provocadas por las subidas deben medirse directamente, no deducirse a partir de los FPS medios. Los FPS medios ocultan los picos en el tiempo de fotograma, y esos picos son lo que realmente perciben los usuarios.

En la parte 5 entramos en el capítulo del coste visual, donde la vegetación, los shaders del terreno y las sombras en cascada compiten por el mismo presupuesto de fotograma.

Tecnología mencionada en este capítulo

Streaming basado en chunks. El mundo se divide en una cuadrícula de chunks independientes (normalmente de 64x64 metros). A medida que el jugador se mueve, los chunks del borde posterior se descargan mientras se cargan por streaming los del borde delantero. Así funciona el sistema de celdas de Skyrim: una cuadrícula de 5x5 celdas cargada alrededor del jugador que se va intercambiando a medida que este se desplaza. La versión para navegador añade la latencia de red a la ecuación, por lo que la precarga predictiva basada en la velocidad del jugador resulta fundamental. Consulta nuestra guía de arquitectura de streaming.

Refinamiento progresivo de mapas de alturas. Primero se envía el terreno a baja resolución y después se refina. Los tamaños de las cuadrículas no son arbitrarios: cada nivel es una cuadrícula de $(2^k+1)\times (2^k+1)$, de modo que $17=2^4+1$, $33=2^5+1$ y $65=2^6+1$. El $+1$ mantiene una muestra compartida en cada límite para que los chunks vecinos encajen, y cada paso cuadruplica aproximadamente el número de muestras ($n^2$ crece al duplicarse el lado). Una cuadrícula de 17x17 (el mínimo para un chunk de 64 m con un espaciado de 4 m) ocupa unos 200 bytes comprimida y permite renderizar al instante una superficie visible. Después se transmite el refinamiento de 33x33 y, por último, la resolución completa de 65x65. Cada nivel añade muestras sin sustituir los datos anteriores. Esto se corresponde directamente con los anillos de LOD de los clipmaps geométricos, donde el terreno lejano utiliza datos de baja resolución y el terreno cercano emplea la resolución completa. Consulta la carga progresiva de chunks.

Codificación delta y compresión. Los datos de los mapas de alturas se comprimen bien porque las celdas adyacentes tienen valores similares. La codificación delta almacena la diferencia entre cada celda y su valor previsto (el promedio de sus vecinas), concentrando los valores cerca de cero. Combinada con zlib o brotli, reduce un chunk de 65x65 de 8,4 KB sin comprimir a 1-2 KB comprimido. Con precisión reducida para chunks lejanos (8 bits en lugar de 16 bits): 0,5-1 KB. Consulta la compresión de datos del terreno.

Precarga predictiva. Consiste en cargar los chunks antes de que llegue el jugador. La distancia de anticipación debe cubrir cuánto recorre el jugador mientras se carga un chunk, $d_{\text{prefetch}}=v\cdot t_{\text{load}}$, por lo que aumenta con la velocidad: al caminar (5 km/h), se precargan 2 chunks por delante (128 m); al correr (15 km/h), se precargan 4. El anillo de carga se desplaza según la dirección de la velocidad. Una cola de prioridad ordena las solicitudes pendientes por urgencia y cancela las de chunks de los que el jugador se ha alejado. Consulta la precarga predictiva.

---

Parte 4 de 12.
Anterior: Parte 3 - Los spikes poco vistosos que nos salvaron
Siguiente: Parte 5 - Presupuestar los elementos visuales
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide