Construir un mundo abierto en el navegador, parte 11: modo basado en políticas, no modo codificado
Por Oleg Sidorkin, director de tecnología y cofundador de Cinevva
¿Acabas de llegar? Consulta la guía de la serie. Explica qué es un spike y contiene enlaces a todas las partes.
Después del capítulo sobre el caos de las uniones, teníamos que dejar de reaccionar y empezar a establecer reglas.
El Spike 23 sustituyó el comportamiento improvisado por reglas de política explícitas. En lugar de que los chunks hicieran lo que indicara su estado local, ahora un sistema central de políticas tomaba las decisiones. ¿Qué nivel de LOD recibe este chunk? ¿Se renderiza como mapa de alturas o mediante marching cubes? ¿Necesita celdas de transición y, de ser así, en qué caras? Las respuestas procedían de una función de políticas que evaluaba la distancia a la cámara, el historial de ediciones y los estados de resolución de los chunks vecinos.
Abrir el Spike 23 en una pestaña nueva ↗ · Ver el código fuente
La asignación de LOD basada en la distancia utilizaba anillos concéntricos alrededor de la cámara, de forma similar al concepto de clipmap, pero aplicado a la cuadrícula de chunks. Los chunks del anillo 0 reciben MC a resolución completa. Los del anillo 1 reciben MC a media resolución. Los del anillo 2 y posteriores usan el modo de mapa de alturas. La restricción de adyacencia era fundamental: para dos chunks vecinos cualesquiera exigimos que
La lógica de cambio entre HM y MC comprobaba el mapa de bits de ediciones de cada chunk. Si un chunk tenía alguna edición volumétrica —cuevas, túneles o esculpidos del terreno—, permanecía en modo MC independientemente de la distancia. Los chunks sin editar podían pasar al modo de mapa de alturas cuando se alejaban lo suficiente. Este enfoque híbrido nos proporcionaba libertad volumétrica donde importaba y eficiencia donde no.
Desde fuera, este spike parecía más pequeño que algunos de los anteriores. En la práctica, supuso una mejora importante en la calidad de vida durante el desarrollo.
Cuando el sistema puede explicar por qué un chunk ha cambiado de modo, se pierde menos tiempo haciendo conjeturas. Añadimos superposiciones codificadas por colores: verde para los chunks de mapa de alturas, azul para los chunks MC y naranja para las caras con transiciones activas. Cuando la visibilidad de las uniones dispone de controles de renderizado específicos, disminuye la ambigüedad de la depuración visual. Cuando los rangos de dibujo están vinculados explícitamente a los recuentos de vértices activos del sistema de políticas, los fantasmas de geometría obsoleta dejan de hacerte perder toda la tarde.
También rediseñamos el comportamiento de la cámara en este spike. Los spikes anteriores tenían controles de órbita sencillos, adecuados para capturas de pantalla pero inútiles para reproducir errores. El Spike 23 añadió una cámara de vuelo con WASD, velocidad configurable, opción para bloquear la altitud y lectura de la posición. Parece algo menor. Pero marcaba la diferencia entre «vi un error en algún lugar cerca de esa cresta» y «el error aparece en la posición (142, 12, -67), mirando hacia el noroeste».
La idea clave de este capítulo es que las políticas no redujeron la complejidad, sino que la organizaron. Seguía existiendo el mismo número de casos límite. Pero ahora cada caso límite tenía un nombre, una condición de activación y un lugar en el código donde se podía establecer un punto de interrupción. Es otro tipo de victoria, y es lo que determina si un sistema puede seguir evolucionando o si se derrumba bajo su propio peso.
Al terminar el Spike 23, teníamos una capa de comportamiento para el campo cercano lo bastante predecible como para conectarla a una estrategia de anillos de clipmap para el campo lejano sin temer constantemente errores derivados de su interacción.
En la parte 12 abordamos el Spike 24, donde las transiciones entre anillos, la niebla del skybox y la integración de shaders específica de cada versión de Three.js cierran este capítulo del proyecto.
Tecnologías mencionadas en este capítulo
Política de LOD basada en la distancia. Una función central que asigna a cada chunk un nivel de LOD y un modo de renderizado según su distancia a la cámara, el historial de ediciones y los estados de sus vecinos. Los anillos concéntricos de distancia determinan el LOD base: anillo 0 = MC a resolución completa, anillo 1 = MC a media resolución, anillo 2 o superior = modo de mapa de alturas. La función de políticas se ejecuta en cada fotograma a medida que se mueve la cámara y activa las transiciones de los chunks. Esto sustituye las decisiones improvisadas de cada chunk por un sistema de reglas predecible y fácil de depurar. Consulta la selección de LOD controlada por la GPU para ver el equivalente con shaders de cómputo.
Restricciones de adyacencia. El algoritmo Transvoxel solo admite relaciones de resolución 2:1. Si dos chunks vecinos difieren en más de un nivel de LOD —por ejemplo, LOD 0 junto a LOD 2—, las tablas de transición no pueden producir una geometría de unión válida. El sistema de políticas lo impide aumentando la resolución del chunk con menor nivel de detalle cuando la diferencia de LOD supera 1. Esta propagación de restricciones puede producirse en cascada: aumentar la resolución de un chunk puede obligar a hacer lo mismo con sus vecinos. La implementación consiste en una sencilla pasada iterativa que converge en 2 o 3 iteraciones para las configuraciones de cuadrícula habituales.
Mapa de bits de ediciones para seleccionar el modo. Cada chunk mantiene un mapa de bits que registra si contiene ediciones SDF volumétricas —cuevas, túneles o esculpidos—. Los chunks con alguna edición permanecen en modo marching cubes independientemente de la distancia, lo que conserva las modificaciones del creador. Los chunks sin editar pasan al modo de mapa de alturas cuando están lo bastante lejos de la cámara, lo que ahorra recursos de cómputo y memoria. El mapa de bits es un único indicador por chunk, pero puede ampliarse para registrar la densidad de las ediciones y tomar decisiones de modo más detalladas.
Superposiciones de visualización para depuración. Renderizado de chunks codificado por colores, donde verde = modo de mapa de alturas, azul = modo MC y naranja = caras con transiciones activas. Superposiciones por chunk con números de nivel de LOD, etiquetas de modo y controles para activar la visualización de la malla alámbrica. Son herramientas de desarrollo, no funcionalidades incluidas en el producto final, pero compensan su coste una y otra vez al depurar transiciones de LOD y artefactos en las uniones. Combinadas con una cámara de vuelo controlada mediante WASD que muestra la posición exacta en el mundo, convierten «vi un error en algún sitio» en «el error aparece en (142, 12, -67) con esta configuración de LOD».
Parte 11 de 12.
Anterior: Parte 10 - El caos de las uniones y el jefe final de las esquinas
Siguiente: Parte 12 - Anillos, niebla del cielo y lo que volveríamos a hacer
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide