Generación de paisajes con LOD dinámico y streaming para mundos abiertos en el navegador

Los mapas de altura con ruido Perlin son el punto de partida habitual para el terreno procedimental. Superpón algunas octavas de fBm, aplica un gradiente de color y tendrás algo que parece un terreno. Todos los tutoriales terminan aquí. Pero los paisajes reales no parecen capas de ruido apiladas. Tienen valles fluviales excavados por el agua, acantilados moldeados por fracturas de tensión, y cuevas y arcos formados por la erosión a lo largo de millones de años. Tienen texturas correlacionadas —hierba en terrenos llanos, roca en pendientes pronunciadas y nieve por encima de la línea de árboles— que surgen de los mismos procesos físicos que dieron forma a la geometría.

Esta guía aborda lo que viene después del ruido: métodos de generación basados en principios físicos, representaciones volumétricas capaces de gestionar cuevas y salientes, síntesis neuronal de terrenos basada en difusión, y los pipelines de LOD y streaming controlados por GPU necesarios para renderizarlo todo en una pestaña del navegador a 60 fps.

Todo lo que se describe aquí está orientado a nuestra restricción específica: un mundo abierto multijugador que se ejecuta en WebGL 2 / WebGPU, se transmite por la red y puede ser editado por creadores.

Por qué los mapas de altura no son suficientes

Un mapa de altura almacena un valor de altura por cada punto de la cuadrícula. Es una función 2D: dadas las coordenadas (x, z), devuelve y. Esta representación es compacta, eficiente para la GPU y rápida de renderizar. Sin embargo, tiene limitaciones fundamentales que importan en un mundo para creadores.

Sin cuevas ni salientes. Un mapa de altura no puede representar un terreno en el que un mismo punto tenga dos alturas diferentes. Las cuevas, los arcos, los salientes de acantilados, los túneles y las islas flotantes son imposibles. Por eso Minecraft, No Man's Sky y Deep Rock Galactic necesitan terreno volumétrico.

Sin elementos verticales. Un acantilado vertical en un mapa de altura es una pendiente casi infinita, lo que provoca un estiramiento extremo de las texturas y artefactos de colisión. Los acantilados reales tienen elementos horizontales —cornisas y grietas— que un mapa de altura no puede representar.

El ruido parece ruido. Incluso con 8 octavas de fBm y deformación de dominio, el terreno tiene un aspecto artificial. Carece de la estructura direccional de la geología real: crestas, redes de drenaje, depósitos sedimentarios y pliegues tectónicos. Estos patrones surgen de procesos físicos, no de funciones de ruido.

Las modificaciones de los creadores son limitadas. Si los creadores solo pueden modificar alturas, no pueden excavar túneles, crear cuevas ni construir espacios subterráneos. Para que los creadores puedan dar forma de verdad a un mundo, la representación del terreno debe admitir tanto la sustracción como la adición.

La solución no consiste en abandonar por completo los mapas de altura. Siguen siendo la mejor representación para el 90 % del terreno que consiste en una superficie simple. La solución es un enfoque híbrido: terreno base con mapa de altura y capas volumétricas donde se necesite geometría compleja, generación físicamente correcta para crear formas del relieve realistas y síntesis neuronal para obtener la diversidad que el ruido no puede conseguir.

La respuesta rápida: lo que realmente construiríamos

Antes de entrar en detalle, este es el marco de decisión. El resto del artículo explica cada componente.

Representación del terreno

Usa un sistema híbrido de mapa de altura + SDF. El mapa de altura cubre todo el mundo —es barato, compacto y de eficacia probada—. Los volúmenes SDF solo existen donde se necesitan cuevas, salientes o elementos excavados por los creadores, quizá en un 5-10 % de los chunks. Así, el 90 % del mundo mantiene el coste de un mapa de altura, al tiempo que se admite geometría arbitraria donde sea necesaria.

Pipeline de generación

Ejecútalo en el servidor como un proceso encadenado:

1. Terrain Diffusion —o MESA para prompts de texto— genera el mapa de altura base a partir de una semilla. Esto sustituye el ruido por formas del relieve geológicamente realistas entrenadas con datos de elevación reales.
2. La erosión analítica —ley de potencia del flujo fluvial— refina el mapa de altura con redes fluviales y crestas en milisegundos.
3. TerraFusion o Geodiffussr genera texturas correlacionadas a partir del mapa de altura —o usa reglas procedimentales de pendiente y altitud como alternativa para WebGL 2—.
4. La simulación del ecosistema produce mapas de densidad de vegetación.
5. La erosión al estilo de Arenite genera volúmenes SDF para acantilados, arcos y cuevas allí donde el terreno los requiera.
6. Divide en chunks, comprime y sube a la CDN. Chunk medio: 2-8 KB. Chunk complejo con datos volumétricos: 20-100 KB.

Los creadores interactúan con este pipeline ajustando parámetros —«más húmedo», «más montañoso», «añadir cuevas»—, esbozando su intención o esculpiendo directamente con pinceles y herramientas SDF.

Estrategia de LOD

Capacidad del navegador	LOD del mapa de altura	LOD volumétrico	LOD de la vegetación
WebGPU	Quadtree controlado por GPU (CDLOD) con descarte mediante cómputo + dibujo indirecto	SDF multirresolución con marching cubes mediante cómputo + Transvoxel	ComputeInstanceCulling con dibujo indirecto
WebGL 2	Clipmaps geométricos con actualizaciones de anillos en la CPU	Mallas pregeneradas en 2-3 niveles de LOD, almacenadas en caché	Descarte de frustum en la CPU, InstancedMesh

Ambas rutas usan geomorphing en el sombreador de vértices para lograr transiciones sin saltos visibles. Ambas usan impostores de billboard para la vegetación distante. La ruta de WebGPU es más rápida —un presupuesto de 3,5 ms para el terreno—, pero la ruta de WebGL 2 también es viable —6,5 ms—.

Streaming

Carga progresiva: primero la geometría del terreno (<100 ms), después las texturas (<300 ms), luego la vegetación (<1 s) y, por último, los datos volumétricos (❤️ s). Precarga en función de la velocidad del jugador. Presupuesto de memoria: 256 MB en total para el terreno.

Edición

Pinceles de mapa de altura para esculpir la superficie —elevar, bajar, suavizar y erosionar—. Primitivas SDF para la edición volumétrica —excavar cuevas y añadir arcos—. Ambas operaciones son instantáneas en local, se sincronizan con el servidor en 100-300 ms y se transmiten a otros jugadores mediante actualizaciones delta.

Qué construir y en qué orden

Meses 1-2: Terreno con mapa de altura y clipmaps geométricos. Solo WebGL 2. Streaming desde la CDN. Materiales procedimentales según pendiente y altitud. Así se muestra el terreno en todos los navegadores. Usa ruido + erosión analítica para la generación —Terrain Diffusion puede esperar—.

Meses 3-4: Vegetación y atmósfera. Hierba y árboles instanciados por GPU a partir de mapas de densidad. Cielo procedimental con ciclo de día y noche. Niebla atmosférica. Mapas de sombras en cascada. El mundo empieza a sentirse como un lugar real.

Meses 5-6: Edición para creadores. Herramientas de pincel para mapas de altura. Sincronización basada en deltas para las modificaciones multijugador del terreno. Bloqueo espacial para la edición simultánea. Es entonces cuando los creadores empiezan a dar forma al mundo.

Meses 7-9: Terreno volumétrico y ruta de WebGPU. Capas SDF para cuevas y salientes. Marching cubes mediante cómputo de WebGPU. Transvoxel para los límites entre niveles de LOD. Herramientas de esculpido SDF. Esto desbloquea el conjunto completo de herramientas de creación.

Meses 10-12: Generación neuronal y pulido. Terrain Diffusion o MESA para el mapa de altura base. TerraFusion/Geodiffussr para las texturas. Ruido fasorial para el microdetalle. Teselado hexagonal para evitar la repetición. Texturizado virtual. Fusión laplaciana. El terreno alcanza una calidad apta para producción.

Este orden permite disponer de algo jugable al cabo de 2 meses, algo atractivo al cabo de 4, algo editable al cabo de 6 y algo de última generación al cabo de 12.

El resto de este artículo recoge la investigación que sustenta cada decisión.

Representaciones del terreno más allá de los mapas de altura

Campos de distancia con signo (SDF)

Un campo de distancia con signo almacena, en cada punto del espacio 3D, la distancia hasta la superficie más cercana. Los valores positivos están en el exterior, los negativos en el interior y el cruce por cero es la propia superficie. Los SDF representan formas 3D arbitrarias, incluidas cuevas, arcos y geometría flotante.

Para renderizar un SDF como una malla, se ejecuta marching cubes —o una variante— para extraer el cruce por cero en forma de triángulos. La resolución de la malla depende de la resolución de la cuadrícula: una cuadrícula SDF de 256x256x256 produce un terreno que cubre aproximadamente un chunk con una resolución de 1 metro.

Implementación en el navegador: marching cubes en WebGPU se ejecuta por completo en la GPU mediante sombreadores de cómputo. La implementación webgpu-marching-cubes de Will Usher procesa una cuadrícula de 256^3 en tiempo real en el navegador y alcanza un rendimiento comparable al nativo. El algoritmo es extremadamente paralelizable —cada celda se procesa de forma independiente—, por lo que resulta ideal para el cómputo en GPU.

@compute @workgroup_size(4, 4, 4)
fn marchingCubes(@builtin(global_invocation_id) id: vec3<u32>) {
    let sdfValues = sampleSDF(id);
    let caseIndex = classifyCell(sdfValues);
    if (caseIndex == 0u || caseIndex == 255u) { return; }
    let triangles = lookupTriangulation(caseIndex);
    let vertices = interpolateEdges(sdfValues, triangles);
    appendToMeshBuffer(vertices);
}

Coste de almacenamiento: un SDF de 256^3 con una precisión cuantizada de 8 bits ocupa 16 MB sin comprimir. Sin embargo, la mayor parte del volumen está vacía —lejos de la superficie—. La codificación por longitud de ejecución o el almacenamiento mediante octrees dispersos suelen reducirlo a 100-500 KB por chunk, un tamaño comparable al del terreno con mapas de altura.

Edición: el terreno SDF se presta de forma natural a la edición. Añadir material es una operación min() sobre el campo de distancia. Eliminar material —excavar— es una operación max() con una forma negada. Para fusionar formas con suavidad se usa smoothMin(). Estas operaciones se ejecutan en un sombreador de cómputo a velocidades interactivas.

Contorneado dual

Marching cubes coloca vértices en los bordes de la cuadrícula, lo que produce superficies suaves pero pierde los elementos definidos —bordes de acantilados y esquinas de rocas—. El contorneado dual coloca un vértice por celda en la posición que mejor representa la superficie dentro de esa celda, preservando los bordes y las esquinas definidos.

El algoritmo necesita tanto los valores del campo de distancia como las normales de la superficie —el gradiente del SDF— en cada punto de la cuadrícula. Resuelve un pequeño problema de mínimos cuadrados por celda para encontrar la posición óptima del vértice. El resultado es una malla que captura tanto el terreno suave como los elementos rocosos definidos.

Neural Dual Contouring (Chen et al., 2022, arXiv:2202.01999) sustituye el solucionador de mínimos cuadrados por una red neuronal que predice las posiciones óptimas de los vértices y los cruces de aristas. Consigue una mayor precisión en la reconstrucción de superficies y una mejor conservación de los elementos, especialmente en formaciones rocosas naturales complejas.

El algoritmo Transvoxel

El problema más difícil del terreno volumétrico no es generar la malla, sino las transiciones de LOD. Cuando un chunk de alta resolución está junto a otro de baja resolución, las mallas no coinciden en el límite y aparecen grietas visibles.

El algoritmo Transvoxel, diseñado por Eric Lengyel (transvoxel.org), resuelve este problema insertando celdas de transición especiales a lo largo de los límites entre distintas resoluciones. Estas celdas salvan la diferencia de resolución mediante triángulos adicionales que coinciden exactamente con ambos lados. El algoritmo reduce el complejo problema de los límites a 73 clases de equivalencia —frente a aproximadamente 1,2 millones de casos con un enfoque de fuerza bruta—.

Transvoxel está diseñado específicamente para aplicaciones en tiempo real cuyos datos de vóxeles cambian dinámicamente —modificaciones de los creadores, erosión y minería—. No está sujeto a patentes y se ha utilizado en juegos publicados como Space Engineers y Astroneer. Para un mundo en el navegador con terreno volumétrico editable, Transvoxel es la solución de LOD.

Híbrido: terreno base con mapa de altura + capas volumétricas

El enfoque práctico para un mundo abierto en el navegador es un sistema por capas:

Capa 1: El terreno con mapa de altura cubre todo el mundo. Es la representación barata y compacta para colinas onduladas, valles y montañas. Se transmite como pequeños fragmentos de mapa de altura por chunk —2-4 KB cada uno—. El renderizado usa clipmaps geométricos con un coste constante en la GPU.

Capa 2: Las capas volumétricas solo existen en los chunks donde se necesita geometría compleja. Las cuevas, los acantilados, los arcos, los túneles excavados por los creadores y los espacios subterráneos se almacenan como volúmenes SDF dispersos. Solo los chunks con datos volumétricos incurren en el coste de almacenamiento del SDF y de marching cubes.

Capa 3: Las modificaciones de los creadores se almacenan como ediciones SDF sobre las capas base. Cuando un creador excava un túnel, se almacena la forma SDF del túnel. El sistema de renderizado combina la superficie del mapa de altura con sustracciones y adiciones volumétricas para producir la malla final.

Este sistema híbrido casi no tiene costes adicionales en terreno llano —solo el mapa de altura— y escala únicamente donde existe complejidad. En un mundo típico, quizá solo un 5-10 % de los chunks necesite datos volumétricos.

Generación de terreno físicamente correcta

El ruido produce terreno aleatorio. La física produce terreno realista. La diferencia es visible: el terreno generado con ruido carece de estructura —presenta irregularidades aleatorias por todas partes—, mientras que el terreno físico tiene redes fluviales, crestas, abanicos aluviales y franjas de acantilados que surgen de la erosión y la tectónica.

Erosión hidráulica: la base

La implementación de erosión hidráulica de Sebastian Lague en acción. Las gotas de lluvia simuladas fluyen cuesta abajo, erosionan material según la velocidad y la pendiente, y depositan sedimentos cuando disminuye su velocidad, transformando el ruido plano en valles fluviales, crestas y abanicos aluviales.

El agua fluye cuesta abajo, recoge sedimentos y los deposita cuando pierde velocidad. Este único proceso, simulado durante millones de años virtuales, transforma un ruido sin rasgos distintivos en un terreno con elementos geológicos reconocibles. El enfoque basado en partículas deja caer gotas de lluvia simuladas sobre el mapa de alturas. Cada gota fluye pendiente abajo (siguiendo el gradiente), erosiona material según la velocidad y la pendiente, transporta sedimentos como carga disuelta y los deposita cuando la velocidad disminuye o se supera su capacidad. Después de 200.000-500.000 partículas, el terreno desarrolla:

• Valles fluviales que siguen la trayectoria del máximo flujo de agua
• Líneas de cresta que separan cuencas hidrográficas
• Abanicos aluviales donde los valles escarpados desembocan en llanuras
• Valles en forma de V en terrenos montañosos y en forma de U en terrenos glaciares

Implementación en GPU: La simulación de partículas se puede paralelizar. Cada partícula es independiente (la aproximación ignora la interacción entre partículas, lo cual resulta adecuado para la erosión). Un shader de cómputo WebGPU procesa 10.000 partículas por fotograma a 60 fps y completa 200.000 partículas en unos 3 segundos de tiempo real.

La implementación de código abierto de Sebastian Lague (GitHub) es el punto de partida estándar. Se ejecuta en un único hilo en C# y procesa un mapa de alturas de 1024x1024 en pocos segundos. La versión para GPU es entre 50 y 100 veces más rápida.

Erosión térmica

El agua no es la única fuerza erosiva. Los cambios de temperatura hacen que la roca se agriete y se desmorone (meteorización térmica). Cuando la pendiente entre dos puntos del terreno supera el ángulo de reposo de un material, este cae desde el punto más alto al más bajo. Esto produce:

• Taludes de derrubios en la base de los acantilados (acumulaciones de roca desprendida)
• Líneas de cresta suavizadas con el tiempo
• Perfiles dependientes del material (la roca dura conserva pendientes pronunciadas, mientras que el suelo blando se desploma hasta formar pendientes suaves)

La erosión térmica es más sencilla que la erosión hidráulica. Es una operación local: para cada celda, se compara la diferencia de altura con las celdas vecinas. Si la pendiente supera el umbral, el material se desplaza pendiente abajo. Se ejecuta como una única pasada de shader de cómputo por iteración y converge en 50-100 iteraciones.

Combinar la erosión hidráulica y la térmica produce terrenos con un aspecto mucho más natural que cualquiera de las dos por separado. El agua excava los valles; la erosión térmica suaviza las crestas entre ellos y llena los fondos de los valles de derrubios.

La ley de potencia de los cauces: erosión analítica

Investigaciones recientes ofrecen una alternativa a la simulación basada en partículas. La ley de potencia de los cauces (una ecuación geomorfológica que relaciona la tasa de erosión con el área de drenaje y la pendiente) puede resolverse analíticamente en lugar de simularse de forma iterativa.

Cordonnier et al. (2024, HAL) combinan la ley analítica de potencia de los cauces con procesos de deslizamiento de tierras y difusión de laderas. El resultado es una generación de terreno con fundamentos físicos que se ejecuta como una función matemática en lugar de como una simulación temporal. Se introduce un mapa de alturas basado en ruido y varios parámetros (tasa de precipitación, dureza de la roca, tasa de elevación tectónica) y se obtiene un terreno erosionado en milisegundos.

Este enfoque analítico resulta ideal para un mundo en el navegador porque se ejecuta una sola vez en el servidor durante la generación del terreno, no de forma iterativa. Los creadores pueden ajustar los parámetros («hacer esta región más montañosa» modifica la tasa de elevación; «hacerla más húmeda» aumenta las precipitaciones y profundiza los valles).

Arenite: erosión multifísica (SIGGRAPH 2025)

Arenite simula la tensión, la erosión eólica, la erosión fluvial y la deposición de partículas para generar arcos, chimeneas de hadas y cerros testigo a partir de roca estratificada. La generación en el servidor produce volúmenes SDF que alimentan directamente una canalización de marching cubes.

Arenite (Página del proyecto) es un simulador de arenisca basado en física que genera arcos, oquedades, chimeneas de hadas y cerros testigo a partir de condiciones iniciales sencillas. Los usuarios pintan mapas de erosionabilidad (capas de roca blanda frente a roca dura) y vegetación, y después el sistema simula:

• Distribución de tensiones a través de la columna de roca
• Erosión eólica que elimina preferentemente el material blando expuesto
• Erosión fluvial causada por el flujo de agua
• Deposición de partículas que crea nuevas formaciones

La implementación en GPU tarda menos de 5 minutos en generar formaciones complejas en una GPU de escritorio. Aunque esto es demasiado lento para usarlo en tiempo real en el navegador, es lo bastante rápido para la generación en el servidor. Un creador podría definir una pared de acantilado con capas de roca blanda y dura y obtener una formación de arco realista en cuestión de minutos.

El resultado es un campo de vóxeles 3D que encaja directamente en nuestra canalización de SDF/marching cubes.

Erosión flexible entre distintas representaciones

Un artículo de 2024 de IRIT-STORM («Flexible Terrain Erosion», Springer) resuelve un problema práctico: la mayoría de los métodos de erosión solo funcionan con campos de alturas. Si el terreno utiliza vóxeles, SDF o materiales por capas, se necesita código de erosión independiente para cada uno.

El método de erosión flexible descompone la erosión en dos procesos independientes: la alteración del terreno (eliminación de material de la superficie) y el transporte de material (desplazamiento de sedimentos mediante partículas regidas por principios físicos básicos). Cada partícula tiene un tamaño, una densidad, una restitución y una capacidad de sedimentos configurables. Un campo vectorial opcional controla el movimiento de las partículas para conseguir una dinámica de fluidos realista.

Como las partículas interactúan con el terreno mediante una interfaz unificada de alteración de materiales, la misma simulación funciona con campos de alturas, cuadrículas de vóxeles, superficies implícitas y pilas de materiales por capas. Para nuestro terreno híbrido (base de mapa de alturas + superposiciones SDF), esto significa que un solo sistema de erosión gestiona ambas representaciones. La simulación de partículas se ejecuta en paralelo en la GPU.

Redes fluviales y cuencas hidrográficas

La erosión excava ríos, pero generar redes fluviales convincentes requiere algo más que hacer correr el agua pendiente abajo. Dos enfoques producen mejores resultados:

La generación basada primero en el drenaje (Amit Patel, Red Blob Games, Proyecto) construye la red fluvial antes de asignar la elevación. Se comienza con un grafo (de Voronoi o una malla de triángulos). Sus aristas se clasifican como crestas (sin flujo), entradas (el agua entra) o salidas (el agua sale). Esto crea jerarquías de drenaje realistas en las que los ríos convergen desde pequeños afluentes hasta formar grandes cursos de agua, siguiendo el sistema de clasificación de Rosgen para distintos tipos de ríos (cauces trenzados en terrenos llanos, gargantas estrechas en las montañas).

La acumulación de flujo registra cuánta agua pasa por cada celda del terreno. Se deja caer lluvia simulada de manera uniforme, se hace fluir pendiente abajo y se cuentan las visitas por celda. Las celdas con una acumulación alta son cauces fluviales. Las que presentan una acumulación moderada son arroyos estacionales. El mapa de acumulación también determina la intensidad de la erosión (más agua = más erosión) y la distribución de la vegetación (las riberas son más húmedas y albergan especies vegetales distintas).

Para un mundo creado por usuarios, la red fluvial se genera en el servidor durante la creación del terreno y se almacena como un mapa 2D de dirección del flujo más un mapa de acumulación de agua por chunk. El cliente del navegador utiliza estos mapas para renderizar superficies de agua (planos horizontales a la altura correcta en los cauces) y determinar la distribución de la vegetación (más exuberante cerca del agua).

Generación de costas y líneas de litoral

Las costas son el lugar donde el terreno se encuentra con el agua y presentan rasgos distintivos que la erosión estándar no produce: acantilados marinos, depósitos de playa, llanuras mareales, farallones y plataformas de abrasión.

NEWTS1.0 (2024, MIT) modela la evolución de las costas rocosas mediante dos mecanismos de erosión: retroceso uniforme (tasa de erosión constante) y erosión provocada por las olas (tasa de erosión en función de la distancia de alcance y el ángulo de incidencia de las olas). El modelo abarca miles de años simulados y produce cabos, bahías, farallones y arcos que coinciden con la geomorfología costera real.

Para un mundo en el navegador, los accidentes costeros se generarían previamente durante la creación del mundo. Los parámetros (dirección dominante de las olas, variación de la dureza de la roca a lo largo de la costa) permiten que los creadores controlen el carácter de su litoral. Un ajuste de «fiordo noruego» produce entrantes de laderas escarpadas. Un ajuste de «atolón tropical» produce costas arenosas de poca altura con lagunas.

Generación de cuevas y espacios subterráneos

Las cuevas requieren terreno completamente volumétrico (SDF o vóxeles), ya que los mapas de alturas no pueden representar espacios cerrados. Los enfoques de generación son:

La aplicación de umbrales a ruido 3D es el método más sencillo. Se muestrea ruido Perlin o simplex 3D en cada vóxel. Los valores por debajo de un umbral son sólidos y los superiores están vacíos. El umbral y los parámetros de ruido se ajustan para controlar el diámetro de los túneles, la conectividad y el tamaño de las cámaras. Esto produce sistemas de cuevas orgánicos y sinuosos que recuerdan a Minecraft.

PLUME (Procedural Layer Underground Modeling Engine) (2024, arXiv:2508.20926) genera entornos realistas de cuevas y tubos de lava mediante reglas procedimentales por capas. Creado originalmente para la investigación de la exploración espacial (simulación de tubos de lava marcianos), produce estructuras subterráneas geológicamente plausibles con estalactitas, columnas y sistemas de cámaras.

Los túneles de sistemas L con tallado mediante metaballs utilizan una gramática de sistemas L para hacer crecer rutas de túneles ramificadas a través del terreno y después tallan la geometría real de los túneles mediante superficies implícitas de metaballs. Las metaballs producen paredes de cueva lisas y redondeadas. Varias pasadas con distintos parámetros crean galerías principales, cámaras laterales y túneles de conexión estrechos.

En un mundo creado por usuarios, la generación de cuevas se integra con el sistema de superposición SDF. El terreno base es un mapa de alturas (sin cuevas). Cuando un chunk necesita cuevas (ya sea por generación procedimental o por diseño del creador), se genera un volumen SDF que sustrae la geometría de las cuevas del terreno base. La canalización de marching cubes renderiza la superficie combinada.

La vegetación como proceso físico

En los juegos, la vegetación suele colocarse de forma procedimental mediante reglas como «hierba por debajo de 2000 m, árboles por debajo de 1500 m, nieve por encima de 3000 m». Este método es rápido, pero produce una distribución uniforme y poco realista.

La simulación de vegetación con fundamentos físicos modela cada planta como un organismo que compite por recursos (luz, agua y nutrientes del suelo). La simulación:

1. Dispersa semillas por el terreno
2. Hace crecer cada planta según los recursos disponibles (el agua fluye a partir de la simulación de erosión hidráulica, la luz solar depende de la pendiente y la orientación, y la profundidad del suelo depende del historial de erosión)
3. Hace que las plantas compitan: los árboles privan de luz a la hierba y un dosel denso impide que crezcan nuevas plántulas
4. Con el paso del tiempo simulado, los biomas surgen de forma natural: bosques en valles con agua, vegetación escasa en crestas azotadas por el viento y humedales donde se acumula el agua

La simulación de ecosistemas de Deussen et al. (Artículo) genera distribuciones forestales que coinciden con patrones ecológicos reales. La simulación se ejecuta sobre una cuadrícula 2D (una celda por chunk de terreno) y produce mapas de densidad y asignaciones de especies que el sistema de renderizado utiliza para colocar vegetación mediante instanciación en GPU.

Para un mundo en el navegador, la simulación de vegetación se ejecuta una vez durante la generación del mundo (en el servidor). El resultado es un conjunto de mapas de densidad por chunk: densidad de árboles, densidad de hierba, densidad de flores y densidad de derrubios rocosos. El cliente del navegador utiliza estos mapas con instanciación en GPU para dispersar la vegetación durante la ejecución.

Síntesis de terreno basada en difusión

Este es el ámbito que avanza con mayor rapidez. Los modelos de difusión (la misma tecnología en la que se basa Stable Diffusion para imágenes) se están aplicando a la generación de terreno, y los resultados son considerablemente más realistas que los de los métodos basados en ruido.

Terrain Diffusion: un sucesor del ruido Perlin

Terrain Diffusion ejecutándose dentro de Minecraft y transmitiendo en tiempo real terreno infinito coherente con la semilla. Entrenado con datos de elevación del mundo real, produce paisajes con una estructura geológica que las funciones de ruido no pueden igualar.

Terrain Diffusion (Goslin, 2025, arXiv:2512.08309, Página del proyecto) es el avance más significativo en la generación procedimental de terreno desde el ruido Perlin de 1985. Desde entonces, el trabajo ha sido aceptado en SIGGRAPH 2026 y el título canónico en arXiv es ahora «InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation». El algoritmo InfiniteDiffusion y el framework Terrain Diffusion son las dos mitades del mismo artículo.

La innovación clave es InfiniteDiffusion, un algoritmo que reformula el muestreo por difusión para dominios ilimitados. Los modelos de difusión tradicionales generan resultados de tamaño fijo (por ejemplo, un mapa de alturas de 512x512). InfiniteDiffusion genera terreno de extensión infinita con:

• Coherencia de semilla: La misma semilla siempre produce el mismo terreno, como el ruido Perlin
• Acceso aleatorio en tiempo constante: Se puede consultar la altura en cualquier punto sin generar primero las regiones vecinas
• Sin artefactos en los límites: Generación infinita sin uniones visibles ni repeticiones

El sistema utiliza una pila jerárquica de modelos de difusión. El nivel superior captura rasgos a escala planetaria (continentes, cordilleras). Cada nivel posterior añade detalles más finos (picos individuales, valles y rugosidad a pequeña escala). Una codificación laplaciana compacta estabiliza los resultados en el enorme rango dinámico que va desde el nivel del mar hasta las cumbres del Himalaya.

Rendimiento: La generación mantiene el ritmo de la exploración en tiempo real. El artículo indica que, incluso en el extremo teórico de la velocidad orbital (unos 7.700 m/s), la síntesis de terreno se ejecuta 9 veces más rápido que el desplazamiento en una GPU de consumo. El proyecto incluye una integración con Minecraft que demuestra la síntesis de terreno en tiempo real. Por qué esto nos importa: Terrain Diffusion produce paisajes a partir de un modelo entrenado con datos de elevación del mundo real (la topografía auténtica de la Tierra). El resultado contiene redes fluviales, cordilleras, accidentes costeros y estructuras de meseta que surgen de los datos de entrenamiento, no de parámetros de ruido ajustados manualmente. Un creador podría decir «genera un terreno como las Tierras Altas de Escocia» y el modelo de difusión produciría algo con el carácter geológico adecuado.

El modelo se ejecuta en el servidor durante la generación del mundo. El resultado es un mapa de alturas estándar que se transmite al navegador como cualquier otro dato de terreno. El método de generación es invisible para el cliente.

TerraFusion: geometría y textura conjuntas

TerraFusion genera juntos el mapa de alturas y la textura a partir de un boceto dibujado a mano. La correlación entre geometría y material viene integrada: los lechos de los ríos aparecen arenosos; las paredes de los acantilados, rocosas; y el terreno llano, cubierto de hierba, sin pintar manualmente ningún mapa de mezcla.

TerraFusion (2025, arXiv:2505.04050) va más allá al generar conjuntamente mapas de alturas y texturas del terreno. La idea clave: la geometría del terreno y el aspecto de la superficie están correlacionados (los lechos de los ríos son arenosos, las paredes de los acantilados son rocosas y las zonas llanas están cubiertas de hierba). Generarlos por separado produce discordancias.

TerraFusion utiliza un modelo de difusión latente con VAE independientes para los mapas de alturas y las texturas, entrenado para modelar su distribución conjunta. El sistema admite:

• Generación incondicional: Terreno plausible aleatorio con texturas correspondientes
• Generación condicionada por bocetos: Un creador dibuja un mapa aproximado (valles aquí, crestas allá, acantilados a lo largo de este borde) y el modelo genera geometría detallada y texturas que se ajustan al boceto

Esto ofrece muchas posibilidades para un mundo creado por usuarios. Un creador esboza la disposición general de su parcela y el sistema completa un terreno geológicamente plausible con los materiales de superficie apropiados. Sin pintar mapas de alturas, sin pintar mapas de mezcla de texturas y sin asignar materiales manualmente.

MESA: de texto a terreno

MESA genera pares de imágenes satelitales y modelos digitales de elevación a partir de indicaciones de texto. Entrenado con el conjunto de datos global de Copernicus, comprende el terreno real a cualquier escala y en cualquier zona climática: fiordos, estepas, tierras de cultivo y crestas alpinas.

MESA (2025, arXiv:2504.07210, taller de CVPR 2025) genera terreno a partir de descripciones de texto. Está entrenado con datos globales de teledetección del programa Copernicus, por lo que ha estado expuesto a todo tipo de paisajes terrestres.

Una indicación como «un fiordo con escarpadas paredes de granito que se abre a una costa rocosa» produce un mapa de alturas con la estructura geológica apropiada. «Tierras de cultivo onduladas con colinas suaves y un amplio valle fluvial» produce algo completamente distinto.

MESA presenta el conjunto de datos de extensión Major TOM Core-DEM, que empareja imágenes satelitales con modelos digitales de elevación de todo el planeta. Estos datos de entrenamiento permiten al modelo comprender qué aspecto tiene el terreno real a cualquier escala y en cualquier zona climática.

Geodiffussr: texturizado del terreno guiado por texto

Geodiffussr toma un mapa de alturas y una indicación de texto, y genera texturas de superficie que respetan la elevación. La nieve solo aparece por encima de altitudes plausibles; la vegetación se vuelve más escasa con la altura; y el agua se asienta en las depresiones. La geometría permanece inalterada.

Geodiffussr (2025, arXiv:2511.23029) toma un mapa de alturas existente y genera texturas guiadas por descripciones de texto, respetando los datos de elevación. «Bosque otoñal» produce follaje naranja y dorado en pendientes moderadas, con roca desnuda en las paredes escarpadas. «Costa tropical» produce palmeras en terrenos bajos y arena coralina al nivel del mar.

El sistema utiliza agregación de contenido multiescala para garantizar que la asignación de texturas respete la elevación: la nieve solo aparece por encima de una altitud físicamente plausible, las masas de agua se asientan en depresiones y la vegetación se vuelve más escasa con la altitud.

Para un mundo creado por usuarios, esto significa que las texturas del terreno pueden volver a generarse a partir de una indicación de texto sin cambiar la geometría. Un creador esculpe el terreno que desea, describe después el ambiente («páramo volcánico oscuro» o «frondoso bosque templado») y el sistema genera los materiales de superficie apropiados.

LOD dinámico para terrenos en el navegador

Renderizar un terreno grande con la máxima resolución en todas partes es imposible en un navegador. Un mundo de 4 km x 4 km con una resolución de 1 metro contiene 16 millones de vértices solo en el terreno. El LOD dinámico reduce esta cifra a una cantidad de vértices constante y manejable, independientemente del tamaño del mundo.

Clipmaps de geometría

La presentación original de los clipmaps de geometría en SIGGRAPH 2004. Los anillos concéntricos de terreno con resoluciones que se reducen a la mitad mantienen constante el número de vértices, independientemente del tamaño del mundo, y siguen siendo la base de la mayoría de los sistemas de LOD de terreno para navegadores actuales.

Los clipmaps de geometría (Losasso y Hoppe, SIGGRAPH 2004, artículo) siguen siendo el estándar de referencia para el LOD de terrenos basados en mapas de alturas. La idea consiste en renderizar el terreno como un conjunto de anillos cuadrados concéntricos centrados en la cámara. Cada anillo abarca el doble de superficie que el anterior, pero con la mitad de resolución.

Cerca de la cámara (anillo más interior): resolución completa, con una separación de cuadrícula de 1 metro. Un anillo más lejos: separación de 2 metros y una superficie 4 veces mayor. Siguiente anillo: separación de 4 metros y una superficie 16 veces mayor. Y así sucesivamente durante 6-8 niveles, hasta que el anillo más exterior cubre toda la distancia visible.

El número total de vértices es constante: aproximadamente N^2 * niveles, donde N es el ancho del anillo en vértices. Con N=256 y 8 niveles, son unos 500 000 vértices en total. El renderizado requiere lo mismo tanto si el mundo mide 1 km como si mide 100 km de ancho.

Implementación en el navegador: Los clipmaps de geometría funcionan en WebGL 2 porque solo requieren actualizaciones estándar del búfer de vértices (sin shaders de cómputo). A medida que se mueve la cámara, la CPU actualiza los datos del mapa de alturas de cada anillo muestreando el terreno con la resolución apropiada. El shader de vértices lee los valores de altura de una textura y desplaza la cuadrícula plana.

Transformación gradual: La transición entre niveles de LOD produce «saltos» visibles si se implementa de forma ingenua. El geomorphing (explicado en su propia sección más adelante) interpola las posiciones de los vértices entre niveles dentro de una zona de transición en el shader de vértices, lo que produce transiciones fluidas y sin saltos sin añadir llamadas de dibujado.

CDLOD: clipmaps adaptativos con quadtree

CDLOD (Strugar, 2014, artículo) mejora los clipmaps de geometría mediante un quadtree en lugar de anillos concéntricos fijos. El quadtree se adapta al terreno: las zonas planas utilizan nodos de baja resolución, mientras que las zonas con mucho detalle (acantilados y crestas) se subdividen más.

Esto es importante para un mundo creado por usuarios porque los distintos fragmentos tienen diferente complejidad. Una pradera llana necesita una resolución mínima. Una región montañosa con acantilados y cuevas necesita el máximo detalle. CDLOD asigna la resolución donde importa.

El recorrido del quadtree en la CPU es ligero (unos cientos de nodos) y determina qué parches de terreno se dibujan y con qué resolución. La GPU renderiza cada parche como una cuadrícula instanciada con valores uniformes de LOD específicos de cada parche.

Árboles binarios concurrentes: teselación a escala planetaria

Teselación adaptativa con CBT para terrenos a escala planetaria: los triángulos se subdividen cerca de la cámara y se fusionan a distancia, íntegramente en la GPU. Menos de 0,2 ms en hardware de consola.

Los árboles binarios concurrentes (CBT) son una estructura de datos apta para la GPU que permite la teselación adaptativa del terreno, presentada por Benyoub y Dupuy (Intel, HPG 2024, artículo, GitHub).

La idea central consiste en representar el terreno como un árbol binario donde cada nodo es un triángulo. La subdivisión adaptativa divide los triángulos cercanos a la cámara y fusiona los que están lejos. El árbol binario reside íntegramente en la memoria de la GPU como una matriz unidimensional (un montículo binario), y las operaciones de subdivisión y fusión se ejecutan como shaders de cómputo.

El artículo de 2024 amplía el CBT desde dominios cuadrados de mapas de alturas a mallas poligonales arbitrarias. Esto permite teselar una esfera (para el renderizado planetario) o una malla base arbitraria (para un mundo de juego con límites no rectangulares). La mejora clave consiste en utilizar el CBT como gestor de un pool de memoria en lugar de emplear una codificación implícita, lo que permite niveles de subdivisión mucho mayores.

Rendimiento: teselación de terreno a escala planetaria en menos de 0,2 ms sobre hardware de nivel de consola. El algoritmo escala linealmente con el número de procesadores. Para WebGPU, esto abre una vía hacia el renderizado de terrenos a escala planetaria en un navegador, aunque la implementación es compleja.

LOD controlado por la GPU con WebGPU

WebGPU permite crear un pipeline de terreno controlado íntegramente por la GPU que elimina la participación de la CPU en las decisiones de LOD:

1. Pasada de cómputo 1: descarte por frustum y oclusión. Un shader de cómputo comprueba el cuadro delimitador de cada parche de terreno con respecto al frustum de la vista y a un búfer de oclusión (el búfer de profundidad del fotograma anterior, reducido de resolución). Los parches invisibles se descartan por completo.

2. Pasada de cómputo 2: selección del LOD. Para los parches visibles, se calcula el tamaño en el espacio de pantalla y se selecciona el nivel de LOD apropiado. El nivel de LOD y el ID del parche se escriben en un búfer de dibujado indirecto.

3. Pasada de cómputo 3: generación de la malla (para terreno volumétrico). En los fragmentos con datos SDF, se ejecuta marching cubes para generar la malla con la resolución de LOD seleccionada.

4. Dibujado indirecto. Una sola llamada a drawIndexedIndirect() renderiza todos los parches del terreno. La GPU lo decide todo: qué dibujar, con qué resolución y en qué orden.

Este pipeline tiene un coste de CPU constante (lanzar los shaders de cómputo y la llamada de dibujado indirecto), independientemente del tamaño o la complejidad del mundo. La GPU se encarga de todas las decisiones de cada parche.

@compute @workgroup_size(64)
fn lodSelection(@builtin(global_invocation_id) id: vec3<u32>) {
    let patchIdx = id.x;
    let bounds = patchBounds[patchIdx];

    if (!frustumTest(bounds, viewProjection)) { return; }
    if (occlusionTest(bounds, depthPyramid) == OCCLUDED) { return; }

    let screenSize = projectedSize(bounds, viewProjection, screenDimensions);
    let lod = clamp(u32(log2(maxScreenSize / screenSize)), 0u, MAX_LOD);

    let drawIdx = atomicAdd(&drawCount, 1u);
    drawArgs[drawIdx] = DrawArgs(patchIdx, lod, indexCount[lod], indexOffset[lod]);
}

Geomorphing: transiciones de LOD sin saltos

El mayor artefacto visual del LOD del terreno son los saltos: los vértices cambian repentinamente de posición cuando un parche cambia de nivel de LOD. El geomorphing los elimina interpolando suavemente las posiciones de los vértices entre niveles de LOD dentro de una zona de transición.

La implementación reside íntegramente en el shader de vértices. Cada vértice almacena tanto su posición en el LOD actual como su posición en el siguiente LOD de menor resolución. Cuando la distancia a la cámara cruza el umbral de transición, un factor de transformación interpola ambas:

float morphFactor = smoothstep(lodNear, lodFar, distanceToCamera);
float morphedHeight = mix(fineLodHeight, coarseLodHeight, morphFactor);
gl_Position = viewProjection * vec4(worldPos.x, morphedHeight, worldPos.z, 1.0);

El artículo de Hoppe sobre clipmaps de geometría (GPU Gems 2, capítulo 2) describe la implementación completa para anillos de clipmap. La zona de transformación ocupa el 20 % exterior de cada anillo. Dentro de esta zona, los vértices convergen suavemente hacia la resolución del siguiente anillo. El efecto visual es que la geometría del terreno se «funde» entre niveles de detalle en lugar de cambiar bruscamente. A velocidades de cámara habituales, la transición es invisible.

La fusión en el espacio de imagen (Scherzer et al., artículo) es una alternativa que combina en el espacio de pantalla las imágenes renderizadas de dos niveles de LOD. Permite gestionar diferencias de LOD más extremas (por ejemplo, transiciones de malla a billboard), pero requiere una pasada de renderizado adicional para la zona de transición.

Descarte de vegetación controlado por la GPU

La vegetación (árboles, hierba y rocas) suele ser la mayor fuente de llamadas de dibujado en un mundo abierto. Un enfoque ingenuo dibuja cada instancia de vegetación en cada fotograma. El descarte controlado por la GPU, ahora disponible en Three.js mediante WebGPU, elimina las instancias invisibles antes de que lleguen al rasterizador.

ComputeInstanceCulling de Three.js (documentación) ofrece descarte por frustum y LOD para mallas instanciadas, con mejoras de rendimiento de entre 10 y 100 veces para grandes cantidades de instancias. El pipeline:

1. Un shader de cómputo lee todas las esferas delimitadoras de las instancias
2. Comprueba cada una con respecto al frustum de la cámara (prueba de 6 planos)
3. Aplica LOD basado en la distancia: las instancias que superan un umbral cambian a un nivel de detalle inferior o se descartan por completo
4. Las instancias supervivientes se compactan en un búfer y se dibujan mediante drawIndirect La CPU no realiza ningún trabajo por instancia. Tras la configuración inicial, el coste es un despacho de cómputo más una llamada de dibujado indirecta por tipo de vegetación, independientemente del número de instancias.

Para una vegetación más densa, IndirectBatchedMesh de Three.js (Documentación) empaqueta varios tipos de geometría (árboles, arbustos, rocas) en un único búfer y los dibuja mediante multidibujado indirecto. Una sola llamada de dibujado para toda la vegetación de un chunk.

Combinado con la dispersión basada en mapas de densidad de nuestro sistema de vegetación, esto significa lo siguiente: el mapa de densidad genera 50 000 posiciones de briznas de hierba en un shader de cómputo, el pase de descarte elimina el 70 % que está fuera de pantalla o demasiado lejos y una llamada de dibujado indirecta renderiza las 15 000 briznas restantes. Coste total de CPU: insignificante.

LOD para terreno volumétrico

El terreno volumétrico (SDF + marching cubes) necesita su propio sistema de LOD porque la malla se genera, no se crea de antemano. El enfoque es el siguiente:

Almacenamiento SDF multirresolución. Almacena el SDF con varias resoluciones en una jerarquía similar a la de un mipmap. El nivel 0 tiene la resolución completa (vóxeles de 1 metro). El nivel 1 usa vóxeles de 2 metros (8 veces menos datos). El nivel 2 usa vóxeles de 4 metros. En cada nivel, el SDF se reduce tomando la distancia absoluta mínima.

Marching cubes seleccionado por LOD. Ejecuta marching cubes en el nivel del SDF que coincida con el LOD deseado. Los chunks cercanos usan el nivel 0. Los chunks lejanos usan el nivel 2 o 3. El algoritmo Transvoxel gestiona el límite entre niveles diferentes.

Almacenamiento en caché. Las mallas generadas se almacenan en caché hasta que cambia el SDF (por una edición del creador) o cambia el nivel de LOD (porque la cámara se ha desplazado considerablemente). En terrenos estáticos, la malla se genera una sola vez y se reutiliza.

Arquitectura de streaming para el terreno

Formato de datos de los chunks

Cada chunk de terreno (64x64 metros) se transmite como un paquete binario compacto:

ChunkPacket {
  header: {
    chunkX: i16, chunkZ: i16,
    version: u32,
    flags: u8  // hasHeightmap | hasVolumetric | hasVegetation
  }
  heightmap: {
    resolution: u8,      // 65x65 for full, 33x33 for half, 17x17 for quarter
    quantizedHeights: u16[resolution * resolution],  // delta-encoded, zlib compressed
    splatMap: u8[4 * resolution * resolution]         // RGBA blend weights, LZ4 compressed
  }
  volumetric?: {         // only present if flags.hasVolumetric
    sdfResolution: u8,   // typically 32 or 64
    sparseOctree: bytes  // run-length encoded sparse SDF
  }
  vegetation?: {         // only present if flags.hasVegetation
    treeDensityMap: u8[16 * 16],    // 4m resolution density grid
    grassDensityMap: u8[32 * 32],   // 2m resolution density grid
    rockDensityMap: u8[16 * 16]
  }
  creatorObjects: {
    count: u16,
    objects: PlacedObject[]   // assetId + transform + properties, ~40 bytes each
  }
}

Tamaños habituales:

• Chunk solo con mapa de alturas (terreno llano): 2-4 KB comprimidos
• Mapa de alturas + vegetación: 4-8 KB
• Mapa de alturas + datos volumétricos + vegetación (chunk complejo): 20-100 KB
• Vecindario de 5x5 con todo el detalle: 50-500 KB en total

Carga progresiva de chunks

Los chunks se cargan por orden de prioridad según la distancia, la dirección del movimiento y el tipo de datos:

Prioridad 1 (inmediata, <100 ms): Geometría del mapa de alturas para los chunks en los que el jugador está a punto de entrar. La superficie del terreno aparece primero. Incluso con la resolución más baja (17x17 por chunk), el suelo ya está presente.

Prioridad 2 (rápida, <300 ms): Mapas de mezcla y texturas del terreno. El suelo adquiere color.

Prioridad 3 (streaming, <1 s): Actualización al mapa de alturas de resolución completa. Mapas de densidad de vegetación. La instanciación en la GPU genera árboles y hierba.

Prioridad 4 (en segundo plano, ❤️ s): Datos SDF volumétricos para chunks con cuevas o salientes. Marching cubes genera la malla en un Web Worker y transfiere el búfer al hilo principal.

Prioridad 5 (diferida, <10 s): Objetos colocados por los creadores. Texturas de alta resolución para estructuras. Objetos de detalle como flores, rocas pequeñas y escombros.

Precarga predictiva

No esperes a que el jugador entre en un chunk para cargarlo. Predice hacia dónde se dirige a partir de su velocidad y carga por adelantado:

• Velocidad al caminar (5 km/h): Precarga 2 chunks por delante (128 m). Con la latencia habitual de una conexión de banda ancha, esto proporciona 200-400 ms de margen.
• Corriendo o cabalgando (15 km/h): Precarga 4 chunks por delante. El anillo de carga se desplaza según la dirección de la velocidad.
• Vuelo o viaje rápido: Pausa el renderizado durante la transición. Transmite los chunks de destino con la máxima prioridad. Reanuda el renderizado cuando haya datos suficientes para un primer fotograma.

El sistema de precarga registra qué chunks están en la caché, cuáles están en curso (solicitados, pero aún no recibidos) y cuáles se necesitan. Una cola de prioridad ordena las solicitudes pendientes por urgencia. Cancela las solicitudes de chunks de los que el jugador se haya alejado.

Presupuesto de memoria y expulsión

Una pestaña del navegador dispone de 2-4 GB en un equipo de escritorio. El sistema de terreno debe usar solo una parte de esa cantidad (el resto se destina al renderizado, la física, la red y el heap de JavaScript).

Presupuesto objetivo: 256 MB para todos los datos del terreno.

Con nuestros tamaños habituales de chunk:

• Chunks con todo el detalle en caché: ~100 (vecindario de 10x10) con 5-100 KB cada uno = 5-10 MB de datos sin procesar
• Geometría del terreno en la GPU: ~50 MB (búferes de vértices y de índices para el terreno visible)
• Texturas del terreno: ~100 MB (comprimidas con KTX2 y empaquetadas en atlas)
• Búferes de instancias de vegetación: ~50 MB (posiciones, rotaciones y escalas para la instanciación en la GPU)
• Volúmenes SDF y mallas de marching cubes almacenadas en caché: ~50 MB

Los chunks situados más allá del rango visible se expulsan primero de la memoria de la GPU (texturas y búferes de vértices) y después de la caché de la CPU. Los datos sin procesar del mapa de alturas son los últimos en eliminarse porque son los más baratos de conservar y los más importantes cuando el jugador se da la vuelta.

Transiciones entre biomas y eliminación de patrones repetitivos

Límites suaves entre biomas

Los paisajes reales no tienen bordes abruptos entre biomas. Un bosque no termina en una línea para convertirse en desierto. Hay un gradiente: el bosque denso se vuelve menos espeso y da paso a árboles dispersos, después a matorrales y, por último, a la escasa vegetación del desierto. Conseguir este efecto hace que el mundo parezca continuo en lugar de dividido en cuadrículas.

AutoBiomes (Kötter et al., Artículo) combina la generación procedural de terreno con una simulación climática simplificada. La temperatura, la humedad y la elevación determinan el tipo de bioma en cada punto. Entre biomas, los pesos de los materiales y la densidad de la vegetación se interpolan a lo largo de una zona de transición (normalmente de 50 a 100 metros de ancho). La anchura de la transición varía según la pareja de biomas: del bosque a la pradera es amplia y gradual; del acantilado al agua es estrecha y abrupta.

En un mundo de creadores, la asignación de biomas se ejecuta sobre una cuadrícula de baja resolución (una muestra de bioma por cada área de 16x16 metros). El shader del terreno lee los valores del bioma para el fragmento actual y sus vecinos, interpola los pesos de los materiales en la zona de transición y mezcla las texturas en consecuencia. La dispersión de vegetación utiliza los mismos valores de densidad interpolados, por lo que la densidad de árboles disminuye gradualmente en el borde del bosque.

Control para creadores: permite que los creadores pinten modificaciones de bioma en sus parcelas. El sistema genera biomas predeterminados a partir de las propiedades del terreno, pero los creadores pueden sustituirlos. Al pintar un «pantano» en una zona baja, el material cambia a agua turbia, musgo y árboles muertos. El mapa pintado de biomas es una cuadrícula por chunk de 16x16 identificadores de bioma (256 bytes) que sustituye la asignación procedural.

Teselado hexagonal: eliminación de la repetición de texturas

El artefacto visual más común en el renderizado de terrenos es la repetición de texturas. Una textura de hierba de 1 metro repetida por una pradera de 100 metros produce patrones de cuadrícula visibles. Dos técnicas resuelven este problema:

Teselado hexagonal (Mikkelsen, Demostración) sustituye la cuadrícula de teselado cuadrada por una hexagonal. Cada tesela hexagonal muestrea la textura con un desplazamiento y una rotación aleatorios. Los límites hexagonales se mezclan para ocultar las uniones. El resultado es una superficie con un aspecto uniformemente aleatorio en lugar de repetitivo. Coste: unas 3 muestras de textura adicionales por fragmento. Esta técnica se utiliza ampliamente en juegos comerciales y funciona en cualquier shader de fragmentos.

Filtrado estocástico de texturas (Pharr et al., NVIDIA, 2024, Artículo) aplica el filtrado después del sombreado en lugar de antes, mediante muestreo estocástico. El error del muestreo estocástico es mínimo y la eliminación de ruido espaciotemporal lo gestiona bien. Esto produce resultados de filtrado más precisos y funciona con texturas comprimidas o dispersas. En terrenos, elimina tanto los patrones repetitivos como los artefactos de filtrado que el teselado hexagonal puede introducir a veces en las transiciones.

Para un mundo de navegador, el teselado hexagonal es la opción práctica (funciona en cualquier shader). El filtrado estocástico requiere más infraestructura, pero ofrece mejores resultados si se dispone de eliminación de ruido temporal (como ocurriría en una ruta WebGPU con TAA).

Sistema de materiales del terreno

Mapeado triplanar

Las texturas con mapeado UV estándar se estiran de forma extrema en pendientes pronunciadas porque las coordenadas UV se comprimen. El mapeado triplanar proyecta texturas a lo largo de los tres ejes (X, Y, Z) y las mezcla en función de la normal de la superficie:

vec3 blending = abs(normal);
blending = normalize(max(blending, 0.00001));
blending /= (blending.x + blending.y + blending.z);

vec4 xaxis = texture(material, worldPos.yz * scale);
vec4 yaxis = texture(material, worldPos.xz * scale);
vec4 zaxis = texture(material, worldPos.xy * scale);

vec4 color = xaxis * blending.x + yaxis * blending.y + zaxis * blending.z;

Las paredes de los acantilados reciben la proyección X o Z (sin estiramiento). El terreno llano recibe la proyección Y. La mezcla es suave y automática. No hace falta desplegar las UV.

Babylon.js incluye un material triplanar. Three.js requiere un shader personalizado, pero la implementación ocupa unas 30 líneas de GLSL.

Para terrenos PBR, aplica el mapeado triplanar a todos los canales: albedo, normales, rugosidad y oclusión ambiental. Se aplican los mismos pesos de mezcla a cada canal.

Asignación de materiales basada en la pendiente y la altitud

En lugar de pintar a mano los mapas de mezcla, asigna materiales proceduralmente según las propiedades del terreno:

float slope = acos(dot(normal, vec3(0, 1, 0)));
float altitude = worldPos.y;

float grassWeight = smoothstep(0.3, 0.0, slope) * smoothstep(2000.0, 1500.0, altitude);
float rockWeight = smoothstep(0.2, 0.5, slope);
float snowWeight = smoothstep(2500.0, 3000.0, altitude) * smoothstep(0.4, 0.1, slope);
float sandWeight = smoothstep(5.0, 0.0, altitude) * smoothstep(0.15, 0.0, slope);

El terreno llano a baja altitud recibe hierba. Las pendientes pronunciadas reciben roca. Las zonas de gran altitud reciben nieve (pero solo en superficies lo bastante llanas como para que se acumule). Las zonas cercanas al nivel del mar reciben arena. Las transiciones son suaves y tienen una justificación física.

En un mundo de creadores, muestra los umbrales de altitud y las zonas de mezcla como parámetros que se puedan pintar por chunk. Los creadores pueden subir o bajar la línea de árboles, ampliar la cobertura de nieve o convertir una colina cubierta de hierba en un desierto arenoso ajustando las reglas de materiales de su parcela.

Mezcla laplaciana de texturas optimizada para la GPU

La mezcla estándar de texturas (interpolación lineal entre capas) produce uniones visibles o resultados desvaídos y con poco contraste. La mezcla mediante pirámides laplacianas resuelve este problema, pero tradicionalmente requiere un preprocesamiento costoso.

Wronski (NVIDIA, 2025, JCGT) presenta una variante optimizada para la GPU que funciona en shaders en tiempo real sin preprocesamiento ni memoria adicional. La técnica utiliza la cadena estándar de mipmaps como aproximación de la pirámide laplaciana: muestrea la textura tanto en el nivel de mipmap actual como en uno más grueso, calcula la diferencia (el laplaciano) y mezcla las contribuciones laplacianas de cada capa.

El resultado conserva los detalles locales nítidos (briznas de hierba individuales y grietas de las rocas), mientras mezcla suavemente a escalas mayores. El coste es de unas pocas lecturas de textura adicionales por fragmento. En terrenos donde se mezclan 4 o más capas de materiales por píxel, esto produce resultados notablemente mejores que la mezcla lineal, especialmente en las transiciones entre hierba, roca y arena.

Ruido de fasores para detalles de erosión

El terreno estándar suele verse plano de cerca porque la simulación de erosión funciona con la resolución del mapa de alturas (una cuadrícula de 1 metro). El terreno real presenta patrones de erosión a pequeña escala (regueros, barrancos y grietas causadas por la meteorización) a escala de centímetros.

Grenier et al. (2024, CGF) utilizan ruido de fasores para añadir microdetalles al terreno en tiempo real. El ruido de fasores sintetiza patrones estructurados mediante la definición de un campo de fase estocástico que alimenta funciones periódicas. Aplicado al terreno, crea patrones de erosión variables en el espacio que:

• Conectan regueros estrechos con barrancos más grandes a distintas escalas
• Se alinean automáticamente con la pendiente del terreno (los patrones de erosión siguen la línea de máxima pendiente)
• Logran una amplificación de hasta 32x (añadiendo detalles a una resolución 32 veces superior a la del mapa de alturas)
• Se ejecutan por completo en un shader de fragmentos con velocidades de fotogramas interactivas

En un mundo de navegador, el ruido de fasores se ejecuta en el shader del terreno como una capa de detalle. El mapa de alturas proporciona la forma a gran escala. El ruido de fasores añade una microerosión convincente en el shader de fragmentos sin aumentar la complejidad geométrica. Los parámetros (frecuencia, amplitud y orientación del patrón) pueden variar según el bioma: regueros profundos en roca desnuda, ondulaciones suaves en dunas de arena y una textura rugosa similar a la corteza en barro seco.

Texturizado virtual para terrenos

A gran escala, el atlas de texturas del terreno se vuelve difícil de manejar. Un mundo de 4 km x 4 km con 1 téxel por centímetro necesita una textura de 400 000 x 400 000 píxeles. Evidentemente, es imposible.

El texturizado virtual (también llamado megatextura, procedente de Rage de id Software) resuelve este problema tratando la textura del terreno como una estructura paginada. La textura completa existe de forma conceptual, pero solo se cargan en la memoria de la GPU las teselas visibles en pantalla. El proceso:

1. Pasada de retroalimentación: Renderiza el terreno con un shader que indique qué tesela de textura necesita cada píxel (ID de tesela y nivel mip). Lee esta información en la CPU (o procésala con un shader de cómputo).
2. Carga de teselas: Carga las teselas solicitadas desde la CDN o genéralas de forma procedural a partir de los datos del mapa de mezcla.
3. Textura de indirección: Una textura pequeña asigna las coordenadas de las teselas virtuales a las coordenadas de las teselas físicas en un atlas de texturas.
4. Pasada de renderizado: El shader del terreno consulta la textura de indirección para encontrar la tesela física correcta y después muestrea la textura del material desde el atlas.

Los shaders de cómputo de WebGPU pueden gestionar íntegramente en la GPU el análisis de retroalimentación y la tabla de páginas. La CPU solo administra la E/S de las teselas.

El resultado: un terreno con texturizado único a cualquier resolución sin una explosión del uso de memoria de texturas. Las teselas alejadas de la cámara se cargan a baja resolución. Las teselas cercanas se cargan a alta resolución. El uso total de memoria se mantiene dentro de un presupuesto fijo (normalmente, un atlas de texturas de 128-256 MB).

Efectos dinámicos del terreno

Charcos y humedad

La lluvia no solo cae. También se acumula. Forma charcos en las depresiones. Crea un brillo húmedo sobre las superficies. En las pendientes pronunciadas, escurre. Simular todo esto hace que el clima parezca conectado al terreno en lugar de ser una simple capa visual superpuesta.

El enfoque basado en shaders no simula la dinámica de fluidos. Utiliza el mapa de alturas del terreno para determinar dónde se acumula el agua:

float concavity = heightCenter * 4.0 - heightLeft - heightRight - heightUp - heightDown;
float puddleDepth = max(0.0, concavity * rainIntensity - evaporationRate * timeSinceRain);
float wetness = smoothstep(0.0, 0.02, puddleDepth);

vec3 wetColor = baseColor * 0.7;
float wetRoughness = baseRoughness * 0.3;
vec3 finalColor = mix(baseColor, wetColor, wetness);
float finalRoughness = mix(baseRoughness, wetRoughness, wetness);

Las zonas cóncavas (laplaciano negativo del mapa de alturas) acumulan agua. Cuanto mayor es la concavidad, más grande es el charco. Las superficies húmedas se oscurecen y se vuelven más reflectantes (menor rugosidad). El efecto se desvanece con el tiempo después de que deje de llover.

Para obtener reflejos completos en los charcos, añade una pasada de reflexión plana en la superficie del charco. También puedes utilizar reflejos en espacio de pantalla (SSR), que son más económicos y ya están disponibles en las pilas de posprocesamiento tanto de Three.js como de Babylon.js.

Las gotas de lluvia sobre las superficies de los charcos utilizan una sencilla ecuación de ondas 2D en una textura de retroalimentación (Saurel, 2026, Blog). Cada gota crea una onda que se propaga hacia fuera y se atenúa. La textura de ondas modula el mapa de normales del charco, creando patrones de ondas convincentes a 60 fps.

Huellas y deformación del terreno

Cuando un jugador camina sobre terreno blando (arena, nieve o barro), las huellas refuerzan la sensación de presencia física. La técnica consiste en mantener una pequeña textura de deformación por chunk (64x64 píxeles = 4 KB) que almacena desplazamientos de altura. Cuando un personaje pisa terreno blando, se estampa la forma de una huella en la textura de deformación.

El shader de vértices del terreno lee la textura de deformación y resta el desplazamiento de la altura. El shader de fragmentos del terreno oscurece la zona de la huella (el suelo compactado es más oscuro) y aumenta la rugosidad (superficie alterada).

Las huellas se desvanecen con el tiempo (la nieve vuelve a cubrirlas y la lluvia borra las marcas de barro) reduciendo gradualmente a cero la textura de deformación. La velocidad de desvanecimiento depende del clima: rápida con lluvia y lenta en condiciones secas.

En un mundo multijugador, los datos de las huellas son efímeros y locales. Cada cliente genera huellas para los jugadores visibles. No es necesario sincronizar la textura de deformación entre clientes (cada uno ve su propia versión de las huellas transitorias). Esto evita el coste de red que supondría transmitir cada paso.

Cielo procedural y ciclo de día y noche

El cielo es la superficie visible más grande de cualquier mundo abierto. Determina la atmósfera de todo el terreno.

Three.js cuenta con un sistema de cielo completo que incluye sol y luna procedurales, ciclo de día y noche, nubes, estrellas y destellos de lente. El ejemplo Sky integrado en Three.js (también disponible en WebGPU) implementa el modelo analítico del cielo de Preetham.

Para obtener resultados con mayor precisión física, webgpu-sky-atmosphere implementa el modelo atmosférico de Hillaire como posproceso de WebGPU. Admite múltiples funciones de fase de dispersión y produce, a partir de principios físicos, una perspectiva aérea correcta (el terreno lejano aparece más brumoso), colores del sol y del atardecer, y gradientes del cielo.

TerrainView7 muestra el renderizado de un planeta a escala completa en WebGPU con dispersión atmosférica precalculada, lo que demuestra que el renderizado atmosférico con precisión física funciona en un navegador.

En un mundo de creación, los parámetros del cielo (posición del sol, cobertura de nubes y densidad de bruma) se sincronizan entre todos los clientes mediante el reloj del mundo del servidor. El shader del cielo se ejecuta localmente en cada cliente, lo que produce una iluminación coherente para todos los jugadores.

Iluminación del terreno: iluminación indirecta

La luz solar directa se gestiona mediante mapas de sombras. Sin embargo, el color y el brillo del terreno en sombra (luz ambiental o indirecta) son igual de importantes para la calidad visual. Las sombras completamente negras resultan poco naturales. Deberían teñirse con el color del cielo (azul en un día despejado y gris en un día nublado).

Para un mundo en el navegador, el enfoque práctico es:

La iluminación indirecta en espacio de pantalla con máscara de bits de visibilidad (Jimenez et al., 2023, Artículo) mejora el SSAO estándar mediante el seguimiento de 32 sectores de visibilidad direccional por píxel. Esto no solo captura cuánto está ocluido un punto, sino también la direccionalidad de la oclusión. Las superficies delgadas permiten correctamente que la luz pase desde el otro lado. El resultado es una iluminación indirecta que reacciona a la geometría cercana sin necesitar una infraestructura de iluminación global.

El coste es comparable al de SSAO (1-2 ms). La mejora visual es considerable: el terreno de los cañones recibe la luz rebotada de sus paredes. La parte inferior de los salientes queda iluminada por el reflejo del suelo. El efecto se combina con la dispersión atmosférica del shader del cielo para producir una iluminación ambiental basada en principios físicos.

Integración de la física del terreno

Colisionadores de campos de alturas de Rapier

El motor de física WASM de Rapier proporciona colisionadores nativos de campos de alturas optimizados para terrenos. Crear un colisionador de terreno es sencillo:

const heights = new Float32Array(65 * 65);
// Fill with heightmap data...
const groundCollider = RAPIER.ColliderDesc.heightfield(
  64, 64, heights, new RAPIER.Vector3(64.0, 100.0, 64.0)
);
world.createCollider(groundCollider);

El colisionador de campo de alturas utiliza la cuadrícula estructurada para realizar consultas de fase amplia de forma eficiente. El trazado de rayos contra un campo de alturas es O(log n), en lugar de O(n) como en una malla de triángulos. En un chunk de 65x65, las consultas de colisión se resuelven en microsegundos.

Para los chunks con terreno volumétrico (capas SDF superpuestas), genera una malla de triángulos a partir de la salida de marching cubes y utiliza un colisionador de malla triangular. Esto es más costoso que un colisionador de campo de alturas, pero admite geometría arbitraria. Genera colisionadores de malla triangular únicamente para los 3-5 chunks más cercanos al jugador. Los chunks lejanos no necesitan física.

Rendimiento: El colisionador de campo de alturas de Rapier para un chunk de 65x65 añade aproximadamente 0,1 ms por paso de física en las consultas del controlador de personaje. Cinco chunks activos con colisionadores de campos de alturas: 0,5 ms. Un colisionador de malla triangular para un chunk volumétrico: 0,2-0,5 ms. Presupuesto total para la física del terreno: menos de 1 ms, holgadamente dentro del presupuesto de 2-3 ms para la física de todo el mundo.

Controlador de personaje adaptado al terreno

El controlador de personaje debe responder a las propiedades del terreno:

• Limitación de pendiente: El personaje puede caminar por pendientes de hasta 45 grados. Las pendientes más pronunciadas provocan que se deslice. Para ello se utiliza la normal del terreno en la posición del personaje (calculada de forma eficiente a partir del gradiente del mapa de alturas).
• Respuesta al material de la superficie: Caminar sobre roca produce sonidos de pasos y una velocidad de movimiento distintos a los de caminar sobre arena o barro. El mapa de mezcla del terreno proporciona el material de la superficie en cualquier punto.
• Subida de escalones: El personaje puede subir salientes de hasta 0,5 metros. El KinematicCharacterController de Rapier lo gestiona automáticamente mediante una altura de escalón configurable.

Edición interactiva del terreno en el navegador

En un mundo de creación, el terreno no solo se genera. Los jugadores lo esculpen, modifican y remodelan. Las herramientas de edición deben responder con rapidez (respuesta visual instantánea) y funcionar en red (los demás jugadores ven los cambios en cuestión de segundos).

Editor SDF con WebGPU

El Editor SDF con WebGPU de Reinder Nijhoff demuestra que el modelado SDF completo ya funciona hoy en el navegador. El editor admite:

• Seis formas primitivas (esfera, caja, cono, cilindro, cápsula y toroide) con posición, rotación y escala
• Operaciones booleanas (unión, sustracción e intersección) con mezcla suave y radios de mezcla configurables
• Grafos de escena jerárquicos con grupos y operaciones anidadas
• Renderizado en tiempo real mediante varias etapas de shaders de cómputo en la GPU, particionamiento espacial basado en octrees sobre 16.384 celdas de cuadrícula y extracción de superficies mediante marching cubes o redes de superficies
• Antialiasing temporal y oclusión ambiental mediante mapas de sombras

Cada primitiva se almacena como 28 valores de coma flotante (112 bytes) en un único búfer de la GPU. Esta representación compacta permite que una edición compleja del terreno (decenas de primitivas SDF que definen la entrada de una cueva, un arco o la cara tallada de un acantilado) ocupe menos de 5 KB y se sincronice al instante con los demás jugadores.

En un mundo de creación, el flujo de edición SDF es el siguiente:

1. El creador selecciona una herramienta de esculpido (añadir esfera, sustraer caja o aplicar mezcla suave)
2. Hace clic o arrastra en el mundo para colocar la primitiva SDF y definir su tamaño
3. El cliente ejecuta inmediatamente marching cubes sobre el SDF modificado para actualizar la malla local (respuesta en <16 ms)
4. La edición SDF (tipo de primitiva + transformación + modo de mezcla, ~100 bytes) se envía al servidor
5. El servidor valida la edición (se encuentra dentro de la parcela del creador y no intersecta zonas protegidas) y la transmite a los jugadores cercanos
6. Los clientes de los demás jugadores aplican la edición SDF y regeneran su malla local

El tiempo total de ida y vuelta para que los demás vean una edición es de 100-300 ms, según la latencia de la red. El creador ve su edición al instante porque se aplica localmente antes de que el servidor la confirme.

Edición de mapas de alturas mediante pinceles

Para la capa del mapa de alturas (el 90 % del terreno que no necesita características volumétricas), basta con un modelo de edición más sencillo. El creador pinta modificaciones de altura con un pincel:

• Elevar/bajar: Añade o resta altura dentro de un radio con atenuación
• Suavizar: Promedia las alturas dentro de un radio para eliminar los rasgos abruptos
• Aplanar: Establece todas las alturas dentro de un radio en un valor objetivo
• Pincel de erosión: Aplica localmente varios pasos de erosión hidráulica dentro del radio del pincel

La edición del mapa de alturas es un delta: un pequeño parche de cambios de altura que se superpone al terreno base. El parche delta es diminuto (una cuadrícula de 32x32 con desplazamientos de altura de 16 bits = 2 KB) y se sincroniza con los demás jugadores en un único mensaje. Se acumulan varios parches delta por chunk y el servidor los fusiona periódicamente con el mapa de alturas persistente del chunk.

Restricciones de la edición colaborativa

Cuando varios creadores editan simultáneamente el mismo chunk, el sistema necesita reglas:

• Bloqueo espacial: Solo un creador puede editar una subregión determinada de 8x8 metros a la vez. El bloqueo se adquiere cuando el creador inicia un trazo de edición y se libera cuando levanta el pincel. Los bloqueos caducan después de 10 segundos de inactividad.
• Ediciones no superpuestas: Si dos creadores editan partes diferentes del mismo chunk, ambas ediciones se aplican sin conflictos (modifican distintas celdas del mapa de alturas o regiones SDF).
• Ediciones superpuestas: Si dos creadores editan la misma ubicación, el servidor serializa las ediciones según el orden de llegada. Ambos clientes ven el mismo resultado final tras la reconciliación.

Esto es más sencillo que el enfoque CRDT completo utilizado para los objetos colocados, porque las ediciones del terreno son operaciones aditivas sobre un campo continuo (alturas o distancias SDF), no estados de objetos discretos.

Geometría virtual al estilo Nanite en WebGPU

Nanite de Unreal Engine 5 renderiza miles de millones de triángulos mediante la creación de un DAG de clústeres (grafo acíclico dirigido) durante la compilación y la selección en tiempo de ejecución del LOD adecuado para cada clúster en función del error en espacio de pantalla. Todo el proceso se ejecuta en la GPU. Este enfoque se ha adaptado a WebGPU.

Nanite WebGPU

Nanite WebGPU renderizando una escena completa en Chrome mediante LOD de meshlets, rasterización por software con shaders de cómputo WGSL y descarte de frustum y oclusión por meshlet. Sin plugins nativos: WebGPU puro.

Nanite WebGPU de Scthe (más de 1.100 estrellas en GitHub) es una implementación completa para navegadores de la arquitectura central de Nanite:

• Jerarquía LOD de meshlets creada sin conexión mediante la generación de clústeres de meshoptimizer
• Rasterizador por software implementado mediante shaders de cómputo WGSL (adaptado a las limitaciones de WebGPU, donde la rasterización por hardware no puede ejecutar llamadas de dibujo por clúster de forma eficiente)
• Descarte por instancia y por meshlet mediante pruebas de frustum y oclusión
• Impostores billboard para objetos extremadamente lejanos
• Compatibilidad con texturas y normales por vértice La canalización funciona así: las mallas se dividen en clústeres de unos 128 triángulos. Los clústeres vecinos se agrupan y cada grupo se simplifica (mediante meshoptimizer), preservando los límites compartidos. Este proceso se repite recursivamente hasta que toda la malla se reduce a un solo clúster. Durante la ejecución, un shader de cómputo recorre el DAG y selecciona, para cada grupo, el clúster menos detallado que produzca menos de 1 píxel de error con la resolución de pantalla actual.

THREE-Nanite es una implementación emergente para Three.js que alcanza entre 20 y 40 fps en hardware gráfico integrado mientras procesa cientos de miles de triángulos. Demuestra que el renderizado al estilo Nanite es viable incluso en hardware de gama baja para navegadores.

meshoptimizer: la base de la canalización de LOD

meshoptimizer (de Arseny Kapoulkine) es la biblioteca en la que se basan la mayoría de las canalizaciones de LOD compatibles con navegadores. La versión 1.0 (2025) ofrece:

• Simplificación de mallas con métricas de error (cuánto ha cambiado la forma, utilizado para seleccionar el LOD)
• Generación de clústeres para jerarquías de meshlets al estilo Nanite
• Optimización de la caché de vértices para ordenar los triángulos de forma eficiente para la GPU
• Optimización del sobredibujado para reducir el coste del shader de píxeles
• Cuantización y compresión de vértices para reducir el tamaño de las descargas

meshoptimizer 1.0 (publicado en diciembre de 2025) incluye un nuevo archivo de cabecera único, clusterlod.h, que implementa directamente un LOD continuo al estilo Nanite. Construye una jerarquía de clústeres que se agrupan y simplifican progresivamente, lista para usarse tal cual o como referencia para una canalización personalizada. Esta es exactamente la primitiva de DAG de clústeres que necesita la canalización de terreno para el LOD de mallas generadas mediante SDF y marching cubes.

En nuestra canalización de terreno, meshoptimizer procesa el resultado de marching cubes del terreno SDF para convertirlo en mallas optimizadas y agrupadas en clústeres con jerarquías de LOD. El procesamiento sin conexión se ejecuta en el servidor. El navegador recibe mallas ya agrupadas en clústeres y realiza durante la ejecución una selección de LOD controlada por la GPU.

La combinación de meshoptimizer para generar los LOD y el cómputo con WebGPU para seleccionarlos durante la ejecución proporciona al terreno en el navegador el mismo patrón arquitectónico que Nanite, adaptado a las limitaciones de la web.

Diseño de niveles adaptado al terreno

El terreno no es solo una superficie sobre la que caminar. Su forma guía el movimiento de los jugadores, dirige su atención y crea el ritmo emocional de la exploración. Los mejores mundos abiertos utilizan el terreno como herramienta de diseño.

Líneas de visión y puntos de referencia

El capítulo sobre orientación de The Level Design Book documenta cómo la elevación del terreno controla lo que ven los jugadores y hacia dónde se dirigen. Una cresta oculta lo que hay al otro lado y despierta curiosidad. Un valle canaliza el movimiento hacia su punto más bajo. Un punto de referencia alto (una torre, la cima de una montaña o un árbol inusual) visible desde lejos ofrece a los jugadores un objetivo hacia el que caminar.

En un mundo creado por usuarios, esto significa que la generación del terreno debe producir elementos naturales que faciliten la orientación. Las líneas de cresta deben interrumpir la visibilidad y crear «momentos de revelación» cuando el jugador alcanza la cima de una colina y descubre una zona nueva. Los valles deben converger en lugares interesantes. Debe haber puntos elevados donde los creadores puedan colocar referencias visibles desde lejos.

Exploración impulsada por la curiosidad

Una investigación de la Universidad Purdue (artículo) identifica cuatro desencadenantes de la exploración espacial:

1. Alcanzar puntos extremos (la cima más alta, el borde más lejano o la cueva más profunda). El terreno debe tener extremos claros que recompensen a quienes llegan hasta ellos.
2. Superar obstáculos visuales (¿qué hay detrás de ese acantilado? ¿Qué hay dentro de esa cueva?). Un terreno que bloquea la vista motiva el movimiento para descubrir qué se oculta.
3. Objetos fuera de lugar (una estructura en plena naturaleza, una luz en la oscuridad). Los objetos colocados por los creadores sobre un terreno natural generan un contraste que atrae la atención.
4. Comprender las conexiones espaciales (¿cómo conecta este valle con aquella costa?). Un terreno que crea una geografía legible fomenta la lectura de mapas y la planificación de rutas.

PlotMap: colocación de puntos de interés asistida por IA

PlotMap (arXiv:2309.15242) automatiza la distribución de puntos de interés a partir de requisitos narrativos (esta misión necesita una aldea cerca de un río; aquella necesita unas ruinas en lo alto de una colina) y busca ubicaciones del terreno que satisfagan las restricciones espaciales. Para un mundo creado por usuarios, un sistema similar podría sugerir dónde colocar estructuras según las propiedades del terreno: «esta cima ofrece buenas líneas de visión para una atalaya», «este valle protegido sería adecuado para una aldea».

Agua corriente y cascadas

Los ríos y las cascadas son elementos del terreno que combinan atractivo visual con sonido ambiental y posibilidades jugables (el agua como barrera, recurso o camino).

Renderizado de ríos

En los mundos abiertos, los ríos suelen renderizarse como franjas texturizadas que siguen la superficie del terreno. La malla de la franja se genera a partir de la spline del río (almacenada como puntos de control) y se proyecta sobre el mapa de alturas del terreno. El shader del río aplica:

• UV alineadas con el flujo que se desplazan en la dirección del río para crear la apariencia de agua corriente
• Espuma en los bordes donde el río se une a la orilla (basada en la profundidad, de forma similar a la espuma de la costa)
• Variación de velocidad según la anchura del cauce (las secciones estrechas fluyen más rápido y las anchas más despacio)
• Transparencia con color basado en la profundidad (las zonas poco profundas son claras y las profundas, oscuras)

En un mundo para navegador, los datos fluviales son compactos: una spline (entre 20 y 50 puntos de control por segmento de río, unos 400 bytes), además de parámetros de anchura y velocidad del flujo. El cliente genera localmente la malla del río proyectando la spline sobre la superficie de su terreno.

Renderizado de cascadas

Cuando un río cae por un acantilado, un sistema de partículas para cascadas sustituye la superficie plana del río. El enfoque híbrido de la investigación sobre simulación de agua en tiempo real (EG) convierte las regiones que no pueden representarse mediante un campo de alturas (cascadas y salpicaduras) en partículas de rocío, salpicadura y espuma que intercambian masa y momento con la simulación de fluidos.

Para un mundo en el navegador, las cascadas son más sencillas: se detecta dónde cruza la spline del río una discontinuidad de altura del terreno, se genera en ese punto un sistema de partículas con velocidad descendente y se añade espuma de salpicadura en la base. Las partículas son cuadriláteros instanciados en la GPU con texturas alfa en desplazamiento. Son 500 partículas por cascada y una llamada de dibujo. El sonido del agua al caer utiliza la API Web Audio con atenuación por distancia.

Impostores para elementos lejanos del terreno

Los árboles, las rocas, los edificios y otros elementos del terreno se vuelven diminutos a gran distancia. Renderizarlos como mallas 3D completas desperdicia ciclos de GPU. Los impostores sustituyen los objetos lejanos por imágenes planas prerenderizadas orientadas hacia la cámara.

Atlas de impostores octaédricos

Un impostor octaédrico captura la apariencia de un objeto 3D desde varios ángulos de visión y almacena las capturas en un atlas de texturas. Durante la ejecución, el shader toma muestras del atlas según la dirección de visión actual e interpola entre los dos ángulos capturados más cercanos.

Un atlas hemioctaédrico (con vistas solo desde el hemisferio superior, ya que rara vez se observan los árboles desde abajo) proporciona el doble de resolución angular que un atlas octaédrico completo con el mismo tamaño de textura. El sistema de impostores de Unity registra una reducción del tiempo por fotograma de 111 ms a 5,78 ms al cambiar 1600 instancias de árboles de mallas reales (140 000 triángulos cada una) a impostores.

Para un mundo en el navegador, la canalización de impostores funciona así:

1. En el servidor: renderizar cada recurso desde entre 16 y 32 ángulos de visión, capturando color, normales y profundidad
2. Empaquetar las capturas en una textura de atlas (un atlas por recurso, de unos 256 × 256 píxeles y menos de 100 KB en formato KTX2)
3. Durante la ejecución: las instancias situadas más allá de la distancia de impostor (normalmente entre 100 y 200 m) se renderizan como billboards que toman muestras del atlas
4. Realizar una transición gradual entre la malla y el impostor a lo largo de una zona de 20 m para ocultar el cambio

Billboard Splatting (BBSplat)

Billboard Splatting (2024, arXiv:2411.08508) lleva este concepto más lejos mediante primitivas planas texturizadas entrenables. En lugar de utilizar vistas prerenderizadas, BBSplat optimiza las posiciones y texturas de los billboards para representar el objeto 3D de la mejor manera desde cualquier ángulo. Esto consigue una compresión hasta 17 veces mayor que 3D Gaussian Splatting, al tiempo que mantiene una apariencia dependiente del punto de vista. Para los elementos lejanos del terreno en un mundo para navegador, BBSplat podría reducir el almacenamiento de impostores por recurso y, al mismo tiempo, mejorar la cobertura angular.

Herramientas profesionales de terreno y lo que nos enseñan

Antes de crear desde cero una canalización de terreno, conviene comprender qué hacen las herramientas profesionales sin conexión. Estas herramientas representan décadas de investigación sobre generación de terrenos condensadas en flujos de trabajo de producción.

Gaea (QuadSpinner) está acelerada por GPU y ofrece una respuesta casi instantánea a los cambios. Admite compilaciones por teselas de hasta 2 millones de píxeles por lado, exportación automática de mallas LOD y un grafo basado en nodos en el que cada nodo representa un proceso físico (erosión, sedimentación, levantamiento y meteorización térmica). Los nodos de erosión de Gaea producen terrenos que parecen esculpidos a mano porque modelan procesos físicos específicos en lugar de ruido genérico. La idea clave es que Gaea no utiliza un único algoritmo de erosión. Ofrece nodos separados para la erosión fluvial (excavación de ríos), la erosión térmica (desmoronamiento de acantilados), la erosión costera (acción de las olas) y la erosión eólica (formación de dunas de arena). Combinarlos en un grafo produce terrenos con el carácter geológico propio de un clima específico.

World Machine adopta un enfoque de grafos similar, centrado en la macroestructura del terreno. Su «generador de distribución» permite a los artistas esbozar la forma general de los elementos del terreno (una montaña aquí, un valle allá, una costa a lo largo de este borde), y el sistema completa el conjunto con detalles físicamente plausibles. Este es exactamente el flujo de trabajo que queremos para los creadores: esbozar la intención y obtener la geología.

World Creator se distingue por ofrecer una vista previa en tiempo real durante la edición y una función integrada de generación de ríos que analiza el terreno y calcula automáticamente las rutas del flujo mediante análisis de drenaje.

Lo que tomamos de estas herramientas: el enfoque basado en un grafo de nodos para combinar procesos físicos es más potente que cualquier algoritmo individual. Nuestra canalización de generación en el servidor debe permitir encadenar: base de ruido > levantamiento tectónico > erosión hidráulica > meteorización térmica > erosión costera > vegetación. Los creadores controlan los parámetros en cada etapa. La canalización se ejecuta en el servidor en cuestión de segundos y produce mapas de alturas, mapas de salpicado y mapas de densidad de vegetación.

SoilMachine: geomorfología de código abierto

SoilMachine acopla la erosión hidráulica, térmica y eólica en un único modelo de terreno por capas. La estructura de datos multicapa admite elementos que los mapas de alturas no pueden representar: cuevas, voladizos, cerros testigo y distribuciones de aguas subterráneas.

SoilMachine es un simulador modular de geomorfología de código abierto que acopla varios sistemas de erosión (hidráulica, térmica y eólica) con el transporte y la deposición de sedimentos. Desarrollado en C++ con cómputo por GPU, ofrece una implementación de referencia del enfoque de erosión multiproceso utilizado por las herramientas profesionales.

La biblioteca relacionada soillib (C++20, licencia MIT) proporciona las primitivas subyacentes de simulación geomorfológica como biblioteca reutilizable. Por su parte, hydro-gen implementa erosión hidráulica basada tanto en cuadrícula (aguas poco profundas) como en partículas (gotas de lluvia) mediante shaders de cómputo de OpenGL con ajuste de parámetros en tiempo real.

Estas herramientas de código abierto podrían adaptarse a nuestra canalización de generación en el servidor. Las implementaciones de shaders de cómputo pueden trasladarse directamente a WebGPU si en algún momento queremos ejecutar la erosión en el navegador para proporcionar información en tiempo real a los creadores.

Materiales de terreno multicapa

El terreno real no es una única superficie, sino un conjunto de capas: roca madre en el fondo, suelo encima y nieve o arena acumulándose sobre las superficies. Las capas dinámicas cambian el carácter visual del terreno con las estaciones, el clima y las acciones de los creadores.

Representación mediante campos de alturas por capas

En lugar de un único mapa de alturas, se utilizan varias capas de altura por cada celda de la cuadrícula:

Cell {
  bedrock_height: f16,    // permanent rock surface
  soil_height: f16,       // accumulated soil/sediment above bedrock
  snow_height: f16,       // dynamic snow accumulation
  water_height: f16       // standing water depth
}

Total: 8 bytes por celda (frente a 2 bytes para un único mapa de alturas). Para un chunk de 65 × 65, son 34 KB antes de la compresión. Sigue siendo compacto.

La superficie visual es bedrock + soil + snow. El shader del terreno lee todas las capas y mezcla los materiales en consecuencia: donde el suelo es fino, la roca queda al descubierto. Donde se ha acumulado nieve, la superficie es blanca. Donde se estanca el agua, aparecen charcos o lagos.

Acumulación dinámica

La nieve se acumula durante las nevadas sobre superficies planas orientadas hacia arriba. La velocidad de acumulación depende de la normal de la superficie (las pendientes pronunciadas no retienen nieve), la temperatura (que depende de la altitud) y el resguardo (las zonas situadas bajo voladizos permanecen despejadas). Una pasada de shader de cómputo actualiza la capa de nieve una vez por cada ciclo meteorológico, cada pocos segundos.

La acumulación de arena funciona de forma similar, mediante deposición impulsada por el viento. El viento transporta partículas desde superficies expuestas y las deposita detrás de obstáculos y en zonas protegidas.

En un mundo creado por usuarios, la acumulación dinámica hace que el terreno tenga un aspecto distinto según el tiempo atmosférico. La nieve cubre el mundo durante una ventisca y se derrite cuando vuelve a despejarse. La lluvia llena de agua las depresiones. Esto hace que el mundo parezca reactivo sin que los creadores tengan que hacer nada.

Erosión multicapa

El artículo de 2024 «3D Real-Time Hydraulic Erosion Simulation using Multi-Layered Heightmaps» (EG) amplía la erosión para que opere entre capas. El agua erosiona el suelo más rápido que la roca madre. Los sedimentos se depositan como una nueva capa de suelo. La simulación mantiene la integridad de las capas (la roca madre permanece debajo del suelo) y, al mismo tiempo, permite crear elementos complejos como voladizos, donde la roca madre sobresale por encima del suelo erosionado. Rendimiento: aproximadamente 6 ms por paso de simulación en una RTX 3070 con una resolución de 2048x2048. Es lo bastante rápido para la generación en el servidor, pero demasiado lento para una simulación por fotograma en el navegador. La representación por capas funciona para generar terreno estático, mientras que la acumulación dinámica de nieve y agua se ejecuta mediante un shader por fotograma más económico.

Renderizado de hierba, rocas y detalles

El paisaje necesita algo más que geometría y texturas de terreno. Necesita briznas de hierba que se mezan con el viento, rocas dispersas por las laderas y pequeños detalles como flores, guijarros y ramas caídas que den un aspecto natural a las vistas cercanas.

Hierba instanciada en la GPU

Un millón de briznas de hierba renderizadas mediante instanciación en la GPU en una sola llamada de dibujo. La misma técnica funciona en Three.js y WebGPU: transformaciones por instancia, animación del viento en el shader de vértices y un mapa de densidad para distribuir las briznas a partir de los datos del terreno.

El renderizado de hierba en el navegador está más que probado en Three.js y funciona mediante instanciación en la GPU. El enfoque de la demostración de hierba de al-ro renderiza 100 000 briznas de hierba con una sola llamada de dibujo mediante InstancedBufferGeometry.

Cada brizna de hierba es un cuadrilátero sencillo (4-8 triángulos). Los atributos por instancia definen la posición, la altura, la dirección de curvatura, la variación de color y la fase del viento. El shader de vértices:

1. Lee la transformación de cada instancia
2. Aplica una animación de viento mediante ondas sinusoidales vinculadas a la posición en el mundo y al tiempo
3. Curva la brizna en función de la fuerza del viento (más curvatura en la punta y ninguna en la base)
4. Aplica un gradiente de color (más oscuro en la base y más claro en la punta para simular la dispersión subsuperficial)

El tutorial de Codrops sobre hierba mullida (2025, Tutorial) muestra un enfoque de texturizado por capas: renderiza el plano del suelo varias veces con desplazamientos crecientes, haciendo que cada capa muestree una textura de ruido para crear la apariencia de un volumen de hierba denso. Es más económico que instanciar briznas individuales para coberturas muy densas, aunque resulta menos realista a corta distancia.

En un mundo creado por usuarios, la densidad de la hierba procede del mapa de densidad de vegetación de cada chunk. La GPU distribuye las posiciones de las briznas a partir del mapa de densidad durante el renderizado. No se almacenan ni transmiten datos de cada brizna. El mapa de densidad es una cuadrícula de 32x32 por chunk (1 KB), y la GPU genera a partir de ella miles de instancias de briznas.

Detalles procedurales en rocas y acantilados

Las paredes de los acantilados y el terreno rocoso necesitan un detalle geométrico que el mapa de alturas base o el SDF no pueden ofrecer con una resolución razonable. Dos enfoques se complementan:

Reconstrucción de superficies mediante shaders de malla en la GPU (Raad et al., Eurographics 2025, Artículo) genera geometría procedural durante el renderizado a partir de una malla de control de baja resolución. El shader de malla lee una superficie de terreno base y añade desplazamientos, grietas y protuberancias sin almacenar en memoria la geometría detallada. Esto reduce el uso de VRAM y permite un LOD dinámico.

Distribución de rocas instanciadas coloca mallas de roca prefabricadas sobre pendientes pronunciadas y bordes de acantilados mediante instanciación en la GPU. Un shader de cómputo lee la normal y la pendiente del terreno, y distribuye instancias de rocas allí donde la pendiente supera un umbral. Cada instancia es una malla pequeña (200-500 triángulos) con rotación y escala aleatorias. Con instanciación, 10 000 rocas dispersas añaden un coste de renderizado insignificante.

Carreteras y caminos

Las carreteras, senderos y caminos colocados por los creadores deben adaptarse al terreno y modificar el material de la superficie, sustituyendo la hierba por tierra o piedra.

El enfoque utilizado por todos los principales motores de juegos consiste en definir el camino como una spline, es decir, una serie de puntos de control. La spline se proyecta sobre la superficie del terreno. Después se genera una malla en forma de franja que sigue la spline y queda ligeramente por encima del terreno. Se aplica una textura de carretera a la franja. En el shader del terreno, el material del terreno se mezcla gradualmente con el de la carretera dentro del ancho de la spline mediante una textura proyectada o un decal.

En un mundo para navegador, el creador dibuja un camino sobre el terreno. El cliente genera puntos de control y los envía al servidor (unas pocas decenas de valores vec3). El servidor almacena la spline. Todos los clientes renderizan localmente la franja de la carretera proyectando la spline sobre su malla de terreno. Los datos de la carretera ocupan muy poco (los puntos de la spline del camino, quizá 200 bytes), pero su impacto visual es considerable: los caminos que conectan las construcciones de los creadores hacen que el mundo parezca habitado.

Sombras del terreno

Las sombras del terreno son fundamentales para la legibilidad (comprender la forma del terreno) y la atmósfera (el ambiente según la hora del día). En un mundo abierto, el sol proyecta sombras sobre todo el terreno visible.

Mapas de sombras en cascada (CSM)

CSM divide el frustum de visión en 3-4 intervalos de distancia (cascadas). Cada cascada renderiza un mapa de sombras desde la perspectiva del sol con una resolución apropiada para su distancia. Cascada cercana: alta resolución (sombras detalladas bajo árboles y edificios). Cascada lejana: baja resolución (amplias sombras de montañas).

Tanto Three.js como Babylon.js admiten CSM. La optimización clave para el terreno consiste en renderizar únicamente el terreno en el mapa de sombras, no las briznas de hierba individuales ni los pequeños detalles. La hierba simula sus propias sombras usando el mapa de sombras del terreno, no uno propio.

Presupuesto de rendimiento: 3-4 cascadas de sombras de 1024x1024 cada una. Renderizar el terreno en los mapas de sombras cuesta 0,5-1 ms (la geometría del terreno ya está en la memoria de la GPU). Muestrear 4 cascadas en el shader del terreno añade 0,2-0,3 ms.

Autosombreado del terreno a partir del mapa de alturas

Para terrenos muy extensos donde CSM resulta costoso, se puede precalcular un mapa del horizonte: para cada celda del terreno, se almacena el ángulo máximo de elevación en las 8 direcciones de la brújula. Durante el renderizado, el ángulo del sol se compara con el mapa del horizonte para determinar si un punto está en sombra. Así gestiona Skyrim el autosombreado del terreno lejano, más allá del alcance de CSM.

El mapa del horizonte se calcula en el servidor a partir del mapa de alturas (unos pocos segundos de procesamiento) y se transmite como una textura de 128x128 por chunk (16 KB comprimida). El impacto visual es considerable: los valles entre montañas se oscurecen de forma realista incluso a distancias de visión extremas.

Compresión de datos del terreno para streaming

La red es el cuello de botella de un mundo para navegador. Cada byte ahorrado en los datos del terreno reduce el tiempo de carga.

Compresión del mapa de alturas

Los mapas de alturas sin procesar de 16 bits se comprimen bien porque las celdas adyacentes tienen valores similares. El proceso:

1. Codificación delta: se almacena la diferencia entre cada celda y su valor previsto (el promedio de sus vecinas). Los valores delta son pequeños y se concentran cerca de cero.
2. Cuantización: en los chunks lejanos, se reduce la precisión de 16 bits a 12 u 8 bits. A 500 metros de distancia, una precisión de altura de 8 bits (resolución de 0,4 m en un intervalo de alturas de 100 m) es indistinguible de 16 bits.
3. Codificación entrópica: se aplica compresión zlib o brotli al flujo codificado mediante deltas. Relación de compresión habitual: 4-8x.

Resultado: un chunk de 65x65 a 16 bits pasa de 8,4 KB sin comprimir a 1-2 KB comprimido. Con precisión reducida a 8 bits: 0,5-1 KB.

Streaming progresivo del mapa de alturas

Primero se envía el terreno a baja resolución y después se refina. Un mapa de alturas de 17x17 (el mínimo para un chunk de 64 m con una separación entre celdas de 4 m) ocupa 578 bytes sin comprimir y menos de 200 bytes comprimido. El terreno aparece al instante. Después se transmite el refinamiento de 33x33, que añade muestras en las filas y columnas impares. Por último, se envía la resolución completa de 65x65. Cada nivel añade detalle sin sustituir los datos anteriores.

Esto se corresponde con los anillos de LOD del clipmap geométrico: el terreno lejano usa la versión de baja resolución (17x17), el de media distancia usa la intermedia (33x33) y el cercano usa la completa (65x65). La prioridad de streaming coincide con el LOD de renderizado.

Compresión de volúmenes SDF

Los volúmenes SDF dispersos se comprimen drásticamente porque la mayoría de los vóxeles están lejos de la superficie, en el espacio vacío. Opciones:

Codificación por longitud de secuencia: codifica secuencias de valores idénticos (vóxeles vacíos). Los volúmenes SDF habituales están vacíos en más de un 95 %, por lo que RLE consigue una compresión de 10-50x.

Octree disperso: solo almacena los nodos del octree que contienen vóxeles atravesados por la superficie. El espacio vacío no tiene nodos. Un volumen SDF de 64^3 con un único túnel de cueva podría tener solo entre 2000 y 5000 nodos ocupados (frente a 262 144 vóxeles totales), cada uno almacenado en 1-2 bytes.

Compresión progresiva guiada por entropía (2024, HAL) se aplica a datos espaciales 3D dividiendo recursivamente el espacio mediante planos optimizados por entropía y cuantización adaptativa. Esto produce un flujo de refinamientos optimizado para equilibrar la tasa y la distorsión, algo especialmente beneficioso con las bajas tasas de bits del streaming por red.

Integración completa: el pipeline de terreno para navegador

El resumen estratégico al principio de este artículo ofrece un marco rápido para tomar decisiones y un plan de desarrollo por fases. Esta sección proporciona todos los detalles técnicos tanto del pipeline de generación en el servidor como del pipeline de renderizado en el navegador.

Pipeline de generación (servidor)

El pipeline de generación se ejecuta como un grafo dirigido de procesos físicos, inspirado en el enfoque de grafos de nodos de Gaea y World Machine. Cada etapa toma el resultado de la anterior y lo refina. Los creadores controlan los parámetros de cada etapa.

Etapa	Entrada	Proceso	Salida	Tiempo
1. Terreno base	Semilla o instrucción de texto	Terrain Diffusion / MESA / ruido + fBm	Mapa de alturas de 16 bits	1-5 s
2. Erosión	Mapa de alturas	Potencia analítica de corrientes + erosión térmica	Mapa de alturas erosionado, mapa de acumulación de flujo, mapa de sedimentos	0,5-2 s
3. Ríos	Mapa de alturas erosionado, mapa de flujo	Extracción de la red de drenaje, excavación de cauces	Splines de ríos, mapa del nivel del agua	0,5 s
4. Costa	Mapa de alturas cerca del nivel del mar	Erosión de oleaje al estilo NEWTS	Accidentes costeros (acantilados, playas, farallones)	1-3 s
5. Volumetría	Mapa de alturas + intención del creador	Erosión Arenite / generación de cuevas / esculpido SDF	Volúmenes SDF dispersos para los chunks afectados	1-60 s
6. Materiales	Mapa de alturas + mapas de erosión	TerraFusion / Geodiffussr / reglas procedurales	Mapas de mezcla, texturas del terreno	1-5 s
7. Vegetación	Mapa de alturas + mapa de flujo + materiales	Simulación de competencia del ecosistema	Mapas de densidad por bioma y chunk	1-3 s
8. Mapas del horizonte	Mapa de alturas final	Ángulo máximo de elevación en 8 direcciones	Textura de autosombreado por chunk	2-5 s
9. División en chunks	Todas las salidas	Dividir, codificar mediante deltas, comprimir, generar hash	Paquetes de chunks en la CDN	5-10 s
Total				15-90 s

Un nuevo mundo de 4x4 km se genera en 15-90 segundos. Las ediciones del creador (esculpido, cambios de parámetros) vuelven a ejecutar únicamente las etapas correspondientes para los chunks afectados y suelen completarse en menos de 5 segundos.

Pipeline de renderizado (navegador)

Paso	Ruta WebGPU	Alternativa WebGL 2	Presupuesto por fotograma
1. Streaming	Cola de prioridades, precarga predictiva	Igual	N/A (asíncrono)
2. Terreno por mapa de alturas	Quadtree CDLOD gestionado por la GPU, descarte mediante cómputo, dibujo indirecto	Clipmaps geométricos, actualización de anillos en la CPU	0,5-1 ms
3. Malla volumétrica	Marching cubes mediante cómputo + Transvoxel	Mallas pregeneradas en un Web Worker, 2-3 LOD almacenados en caché	0,5-2 ms
4. Transiciones de LOD	Geomorfismo en el shader de vértices	Igual	Incluido arriba
5. Materiales	PBR triplanar + mezcla laplaciana + detalle mediante ruido fasorial + texturizado virtual	PBR triplanar + mezcla lineal + mapas de mezcla precalculados	1-1,5 ms
6. Vegetación	ComputeInstanceCulling + IndirectBatchedMesh, cubierta del suelo con teselado hexagonal	Descarte de frustum en la CPU + InstancedMesh	1-1,5 ms
7. Agua	Franjas fluviales alineadas con el flujo, espuma costera basada en la profundidad	Igual (reflejos más sencillos)	0,5 ms
8. Sombras	CSM de 3-4 cascadas + autosombreado mediante mapa del horizonte	CSM de 2 cascadas	0,5-1 ms
9. Atmósfera	Modelo de cielo de Hillaire + niebla volumétrica + partículas meteorológicas	Cielo de Preetham + niebla de distancia	0,5 ms
10. Efectos dinámicos	Acumulación de charcos, deformación por huellas, nieve/lluvia	Acumulación de charcos, partículas de lluvia	0,3 ms
Terreno total			3,5-6,5 ms

A 60 fps (16,6 ms por fotograma), el sistema de terreno utiliza el 21 % del presupuesto por fotograma en WebGPU y el 39 % en WebGL 2. El resto queda disponible para los avatares de los jugadores, los objetos de los creadores, la interfaz, la red y el posprocesamiento.

Por qué funciona en un navegador

Todo el pipeline está diseñado en torno a tres limitaciones de los navegadores:

Memoria (2-4 GB como máximo): el presupuesto de 256 MB para el terreno es suficiente porque los chunks del mapa de alturas ocupan entre 2 y 8 KB cada uno (codificados mediante deltas), los volúmenes SDF son dispersos (100-500 KB por chunk volumétrico), la vegetación se genera en tiempo de ejecución a partir de mapas de densidad de 1 KB y las texturas utilizan compresión KTX2 (150 KB por cada 1024x1024). En cualquier momento, el mundo visible en el navegador ocupa entre 50 y 200 MB en total.

Sin acceso al disco: todo se transmite por la red. La carga progresiva permite al jugador ver el terreno en <100 ms (mapa de alturas de baja resolución), el terreno texturizado en <300 ms y todo el detalle en ❤️ s. La precarga basada en la velocidad oculta los tiempos de carga durante la exploración normal.

La GPU varía enormemente: la ruta WebGPU se ocupa de los equipos de escritorio de gama alta. La alternativa WebGL 2 funciona en todo lo demás, incluidos los dispositivos móviles. Los mismos datos de chunks alimentan ambas rutas. La diferencia está en la técnica de renderizado, no en el formato de los datos. Un Chromebook con WebGL 2 muestra el mismo mundo que una RTX 4090 con WebGPU, aunque con menos detalle y una distancia de visión más corta.

Artículos de investigación

Representación del terreno y generación de mallas

"Marching Cubes: un algoritmo de construcción de superficies 3D de alta resolución" -- Lorensen y Cline (SIGGRAPH 1987). DOI. El algoritmo fundamental para extraer mallas de triángulos a partir de datos volumétricos. Sigue siendo el método de extracción de isosuperficies más utilizado 38 años después. Las implementaciones paralelas en la GPU se ejecutan en tiempo real mediante shaders de cómputo de WebGPU. "Dual Contouring of Hermite Data" -- Ju, Losasso, Schaefer, Warren (SIGGRAPH 2002). DOI. Genera mallas que conservan los rasgos definidos (bordes de acantilados y esquinas de rocas) que marching cubes redondea. Requiere normales de superficie además de valores de distancia.

"Neural Dual Contouring" -- Chen et al. (2022). arXiv:2202.01999. Sustituye el posicionamiento de vértices por mínimos cuadrados del contorneado dual por un predictor aprendido. Ofrece una mayor calidad de superficie para elementos naturales complejos.

"The Transvoxel Algorithm" -- Lengyel (2009, actualizado en 2024). transvoxel.org. Transiciones de LOD fluidas para terrenos de vóxeles. Elimina las grietas en los límites de resolución mediante 73 tipos de celdas de transición. Sin patentes y diseñado para aplicaciones en tiempo real.

LOD y renderizado de terrenos

"Geometry Clipmaps: Terrain Rendering Using Nested Regular Grids" -- Losasso y Hoppe (SIGGRAPH 2004). Artículo. Renderizado de terrenos con coste constante mediante anillos concéntricos de LOD. Procesa terrenos de 40 GB a velocidades interactivas. Es la base de la mayoría de los renderizadores de terrenos para navegadores.

"CDLOD: Hybrid LOD for Terrain Rendering" -- Strugar (2014). Artículo. Mejora adaptativa mediante quadtree de los geometry clipmaps. Asigna la resolución según la complejidad del terreno, no solo en función de la distancia.

"GPU-Driven Rendering Pipelines" -- Ubisoft (SIGGRAPH 2015), Wihlidal y Hoppe. Formalizó el enfoque dirigido por GPU, en el que los compute shaders gestionan el descarte, la selección de LOD y la generación de llamadas de dibujado. Es el patrón arquitectónico de nuestro pipeline de terrenos con WebGPU.

Generación física de terrenos

"Physically-Based Analytical Erosion for Fast Terrain Generation" -- Cordonnier et al. (2024). HAL. Erosión analítica basada en la ley de potencia de los cauces que evita la simulación iterativa. Genera terrenos físicamente plausibles en milisegundos.

"Fast Hydraulic Erosion Simulation and Visualization on GPU" -- Mei, Decaudin, Hu (2007). HAL. Erosión hidráulica paralelizada en la GPU mediante simulación de aguas someras. Es la base de la mayoría de las implementaciones de erosión en motores de juegos.

"Arenite: A Physics-Based Sandstone Simulator" -- SIGGRAPH 2025. Proyecto. Erosión multifísica que genera arcos, chimeneas de hadas y oquedades mediante la simulación de tensiones y erosión. Se ejecuta en menos de 5 minutos en GPU de escritorio.

"Efficient Debris-flow Simulation for Steep Terrain Erosion" -- Purdue CGVLAB (2024). Artículo. Simulación acelerada por GPU de flujos de derrubios y erosión de pendientes pronunciadas que produce elementos realistas de terrenos montañosos.

"Flexible Terrain Erosion" -- IRIT-STORM (2024). Springer. Erosión basada en partículas que funciona con mapas de altura, cuadrículas de vóxeles, superficies implícitas y materiales estratificados mediante una interfaz unificada. Permite utilizar un único sistema de erosión con representaciones híbridas del terreno.

Detalle y texturizado de terrenos

"GPU-Friendly Laplacian Texture Blending" -- Wronski (NVIDIA, 2025). JCGT. Mezcla en tiempo real mediante pirámides laplacianas para materiales de terreno, sin precomputación. Conserva los rasgos definidos y elimina los artefactos de unión. Solo requiere unas pocas lecturas de textura adicionales por fragmento.

"Real-time Terrain Enhancement with Controlled Procedural Patterns" -- Grenier et al. (2024). CGF. Detalle de microerosión basado en ruido fasorial con una resolución hasta 32 veces superior a la del mapa de alturas. Los patrones alineados con las pendientes se ejecutan íntegramente en un fragment shader.

Teselación adaptativa

"Concurrent Binary Trees for Large-Scale Game Components" -- Benyoub y Dupuy (Intel, HPG 2024). Artículo. Estructura de datos de árbol binario optimizada para GPU y destinada a la teselación adaptativa de terrenos. Renderiza geometría a escala planetaria en menos de 0,2 ms. Se ha ampliado desde dominios cuadrados hasta mallas poligonales arbitrarias.

Generación de cuevas y espacios subterráneos

"PLUME: Procedural Layer Underground Modeling Engine" -- 2024. arXiv:2508.20926. Framework de código abierto para generar entornos realistas de cuevas y tubos de lava mediante reglas procedurales por capas. Creado originalmente para la robótica de exploración espacial.

Síntesis neuronal de terrenos

"InfiniteDiffusion: Bridging Learned Fidelity and Procedural Utility for Open-World Terrain Generation" -- Goslin (2025, SIGGRAPH 2026). arXiv:2512.08309. Generación de terrenos infinitos y coherentes con la semilla mediante modelos jerárquicos de difusión con codificación laplaciana. Es 9 veces más rápido que el método de referencia en GPU de consumo.

"TerraFusion: Joint Generation of Terrain Geometry and Texture" -- 2025. arXiv:2505.04050. Difusión latente para sintetizar simultáneamente mapas de altura y texturas, con condicionamiento mediante bocetos.

"MESA: Text-Driven Terrain Generation" -- Taller de CVPR 2025. arXiv:2504.07210. Generación de terrenos a partir de texto mediante datos de teledetección de Copernicus para el entrenamiento.

"Geodiffussr: Generative Terrain Texturing with Elevation Fidelity" -- 2025. arXiv:2511.23029. Generación de texturas de terreno guiada por texto que respeta los datos de elevación mediante flow matching.

"Sketch2Terrain: AI-Driven Real-Time Terrain Sketch Mapping" -- 2025. Proyecto. Conversión de bocetos en terrenos mediante realidad aumentada. Mejora la eficiencia en un 38 % frente al modelado manual.

Simulación de vegetación y ecosistemas

"GPU-Based Real-Time Procedural Distribution of Vegetation on Large-Scale Virtual Terrains" -- SBGames 2018. Artículo. Distribución de vegetación basada en quadtree mediante factores bióticos y abióticos en la GPU.

"Procedural Generation and Rendering of Forests" -- 2022. Artículo. Generación de árboles mediante sistemas-L combinada con la simulación de competencia en el ecosistema para lograr una distribución forestal realista.

"Real-Time Procedural Generation with GPU Work Graphs" -- AMD GPUOpen 2024. Artículo. Grafos de trabajo de GPU que generan más de 79 000 instancias de vegetación en menos de 4 ms.

Tecnología de GPU para navegadores

"GSWT Renderer" -- SIGGRAPH Asia 2025. GitHub. Renderizador WebGPU + Rust/Wasm que utiliza Gaussian Splatting Wang Tiles para crear terrenos 3D infinitos con LOD dinámico y streaming.

"GPU Compute in the Browser at the Speed of Native: WebGPU Marching Cubes" -- Usher (2024). Blog. Demuestra que el cómputo de WebGPU alcanza un rendimiento comparable al nativo en algoritmos paralelos de generación de mallas.

Renderizado de vóxeles y escenas a gran escala

"Aokana: A GPU-Driven Voxel Rendering Framework for Open World Games" -- 2025. arXiv:2505.02017. DAG de vóxeles dispersos con LOD y streaming para escenas con decenas de miles de millones de vóxeles. Reduce 9 veces el uso de memoria y renderiza 4,8 veces más rápido que las técnicas anteriores más avanzadas. Diseñado para integrarse con motores de juegos.

Geometría procedural y reconstrucción de superficies

"Real-time Procedural Resurfacing using GPU Mesh Shaders" -- Raad et al. (Eurographics 2025). Artículo. Genera superficies geométricas detalladas a partir de mallas de control de baja resolución durante el renderizado mediante mesh shaders. Permite un LOD dinámico sin almacenar geometría de alta resolución en la memoria.

Sombras del terreno

"Optimizing Terrain Shadows" -- AMD GPUOpen. Blog. Optimización práctica de CSM para terrenos a gran escala. Abarca la división de cascadas, el renderizado de mapas de sombras eficiente para la GPU y optimizaciones específicas para terrenos.

Geometría virtual y optimización de mallas

"Nanite WebGPU" -- Scthe (2024). GitHub, Demo. Implementación completa para navegadores de la arquitectura Nanite de UE5: jerarquía de LOD de meshlets, rasterizador por software en WGSL, descarte por meshlet e impostores billboard.

"Billions of Triangles in Minutes" -- Kapoulkine (2025). Blog. Meshoptimizer v1.0 para la generación jerárquica de LOD por clústeres. Procesa eficientemente mallas enormes y las convierte en DAG de clústeres al estilo de Nanite.

"Billboard Splatting (BBSplat)" -- 2024. arXiv:2411.08508. Primitivas planas texturizadas y entrenables para sintetizar vistas nuevas, con una compresión 17 veces mayor que 3D Gaussian Splatting.

Iluminación de terrenos e iluminación global

"Global Illumination in Once Human" -- GDC 2025. Sesión. GI híbrida para un mundo abierto de 16 km: sondas comprimidas mediante redes neuronales (relación 69:1), resolución mediante aprendizaje automático de fugas entre interiores y exteriores, y respuesta dinámica de las sondas.

"GI with AMD FidelityFX Brixelizer" -- GDC 2024. Artículo. Cascadas de campos de distancia dispersos basadas en cómputo con sondas en espacio de pantalla. No requiere ray tracing por hardware.

"Radiance Cascades" -- 2024. Blog. Iluminación global en tiempo real sin ruido mediante estructuras de radiancia en cascada y sin acumulación temporal.

Diseño de niveles y exploración

"PlotMap: Automated Layout Design for Building Game Worlds" -- 2023. arXiv:2309.15242. Colocación de puntos de interés asistida por IA que satisface restricciones espaciales narrativas sobre el terreno.

"Spatial Exploration Triggers" -- Universidad Purdue (FDG 2022). Artículo. Cuatro patrones de diseño que impulsan la exploración de los jugadores: puntos extremos, obstrucciones visuales, objetos fuera de lugar y conexiones espaciales.

Compresión y streaming de datos

"Entropy-driven Progressive Compression of 3D Point Clouds" -- SGP 2024. Artículo. Compresión progresiva optimizada según la relación tasa-distorsión mediante particionamiento recursivo del espacio con cuantización adaptativa. Produce flujos de refinamiento adecuados para el streaming en redes con ancho de banda variable.

Edición interactiva

"WebGPU SDF Editor" -- Nijhoff (2026). Proyecto. Modelado SDF completo en el navegador con marching cubes en tiempo real, operaciones booleanas, mezcla suave y particionamiento espacial mediante octree. 112 bytes por primitiva.

Generación de ríos y costas

"Procedural River Drainage Basins" -- Patel (Red Blob Games). Proyecto. Generación de ríos empezando por el drenaje mediante la clasificación de aristas de mallas de Voronoi/triángulos. Construye las jerarquías fluviales antes de asignar la elevación del terreno.

"NEWTS1.0: Numerical Model of Coastal Erosion by Waves and Transgressive Scarps" -- MIT (2024). Artículo. Modelo simplificado de erosión costera basado en un retroceso uniforme y en la erosión producida por el oleaje. Genera cabos, bahías, farallones y arcos que reproducen la geomorfología real.

Lecturas adicionales

• Tecnología para mundos abiertos 3D en el navegador explica la arquitectura completa de un mundo multijugador para creadores en el navegador
• Stack tecnológico para juegos web en 2026 explica los fundamentos de WebGL, WebGPU y WebAssembly
• Informe técnico sobre Three.js + USDC acerca de cómo cargar recursos 3D en el navegador
• Modelos abiertos de IA generativa de vanguardia para el pipeline de generación con IA
• Introducción a WebGPU — compute shaders para terrenos dirigidos por GPU
• Web Workers para la lógica del juego — delegación de la generación de terrenos a Workers
• Bibliotecas de físicas para juegos — físicas para interactuar con el terreno y colliders de mapas de altura
• Dónde encontrar recursos gratuitos para juegos — fuentes de texturas y materiales para renderizar terrenos

Pruébalo ahora mismoIntegra un paisaje generado en un juego

El terreno es mejor cuando puedes caminar sobre él.

Créalo gratis →Es gratis, funciona en tu navegador, nada que instalar.