Para: Oleg Sidorkin
Asunto: app.cinevva.com/blog/2026-03-04-sketch-to-animated-3d-character
Verificado con: repositorio cinevva-site (sitio de marketing + worker)

Verificado ✓

• Los nombres de las herramientas (Image Generator, Video Generator, 3D Model Generator) y el enlace /es/tools/hunyuan3d coinciden con el código.
• El autor (Oleg Sidorkin, CTO) es correcto.
• Flujo de trabajo de vídeo: se admiten la interpolación entre el fotograma inicial y el final, el formato 9:16, una duración de 3 a 15 s y el modo storyboard.
• Proceso 3D: Hunyuan3D y «3D Model Generator» son correctos; el rigging automático (Tripo) y «subir GLB → modelo con rig + biblioteca de animaciones» coinciden con la implementación.
• Cinevva Engine y «Refleja el estado a principios de 2026» son precisos.

Corrección necesaria

«Seedance 1.5 Pro» — En este repositorio, el vídeo se implementa con Kling 3.0 Pro (fal.ai), no con Seedance 1.5 Pro:

• worker/src/genai/fal-video.ts usa fal-ai/kling-video/v3/pro/...
• worker/src/index.ts registra el coste como model: 'kling-3.0-pro'
• tools/video.md dice: «Genera vídeos cortos con IA a partir de texto o imágenes usando Kling 3.0 Pro»

El nombre de la API o del producto es «seedance» (por ejemplo, /genai/seedance/generate), pero el modelo subyacente es Kling 3.0 Pro. Seedance 1.5 Pro es un modelo diferente (ByteDance). Las fuentes públicas suelen limitar Seedance 1.5 Pro a unos 10 s; aquí Kling admite 15 s.

Recomendación: En el artículo, denomina al modelo de vídeo «Kling 3.0 Pro» (o, por ejemplo, «Video Generator (Kling 3.0 Pro)») para que coincida con el sitio de marketing y la documentación. Si el backend de la aplicación realmente usa Seedance 1.5 Pro, alinea los textos de la aplicación y tools/video.md para que describan el mismo modelo.

No verificable en el repositorio

Cubcoats, Kali the Kitty, Mimi Chao y las afirmaciones comerciales relacionadas son externos; no se han verificado.

Te estamos llevando al prototipo {{ spikeId }} en el Creador de Juegos. Si no se te redirige, ábrelo aquí.

Abrir el Creador de Juegos.

← Volver a la guía de la serie

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Hace poco lanzamos un modo de minijuegos de WeChat en nuestro Creador de Juegos: un perfil de compilación que mantiene los juegos generados por IA dentro del subconjunto de la plataforma web capaz de sobrevivir a una adaptación al entorno de ejecución de WeChat. El perfil es un conjunto de reglas de generación. Nada de interfaces DOM, Pointer Lock, audio que no sea MP3 ni código dinámico. El modelo las sigue como los modelos suelen seguir las reglas; es decir, casi siempre.

«Casi siempre» no basta cuando todas las infracciones son invisibles en el navegador y fatales tras exportar. Un juego con una barra de salud en HTML funciona perfectamente en nuestra vista previa y muestra una pantalla en blanco en WeChat, porque los minijuegos de WeChat no tienen DOM. Así que construimos lo que convierte esas reglas de sugerencias en leyes físicas: un sandbox de modo estricto que hace que el propio navegador se niegue a hacer lo que WeChat no puede hacer. Este artículo explica cómo funciona.

La decisión fundamental: simular la ausencia, no la presencia

El enfoque obvio sería emular WeChat: implementar wx.createCanvas, wx.onTouchStart, wx.setStorageSync y ejecutar los juegos contra la superficie emulada de wx.*. Nosotros tomamos el camino contrario, y la razón está en la estructura de nuestro proceso de exportación.

Los juegos del modo WeChat siguen escribiéndose contra las API del navegador. Durante el empaquetado, un adaptador —siguiendo el enfoque estándar de la comunidad de weapp-adapter— asigna esas API del navegador a wx.*. Eso significa que nuestros juegos nunca llaman directamente a wx.*, por lo que un emulador de wx probaría rutas de código que no existen. Lo que realmente rompe una adaptación no es la ausencia de wx.* en el navegador. Es la presencia de API del navegador sin equivalente en WeChat, utilizadas inadvertidamente durante la generación. document.createElement('div'). requestPointerLock(). IndexedDB. Un archivo .ogg que Chrome decodifica sin problemas y que nunca funcionará en WeChat para iOS.

Por eso el sandbox simula la ausencia. Todo lo que WeChat no tiene se elimina, se bloquea o se señala en la vista previa, y el juego se desarrolla desde su primer fotograma dentro de la intersección entre ambas plataformas.

Dónde reside: en un service worker que ya existía

La vista previa de nuestro editor sigue una ruta de servicio poco habitual que hizo que esto resultara casi gratuito. Los juegos del editor no se sirven desde la red. Un service worker intercepta las solicitudes a /game/* y sirve los archivos desde IndexedDB; así, el iframe de vista previa se recarga al instante sin un viaje de ida y vuelta al servidor. Ese worker ya inyectaba dos archivos virtuales en cada página del juego: un script de captura de errores que reenvía al editor la salida de la consola y los fallos, y un inspector de escenas en vivo.

El sandbox es el tercer archivo virtual, _wechat-strict.js, que se inyecta en el <head> de la página inmediatamente después del script de captura y antes de ejecutar cualquier código del juego. El orden es crítico por partida doble. Debe ejecutarse después de la captura para que sus llamadas a console.error ya estén interceptadas y lleguen al editor, y antes de los módulos del juego para que los bloqueos estén preparados cuando se ejecute la primera línea de código.

La activación usa un truco de una sola línea. El interruptor de WeChat del creador se conserva en localStorage, y el iframe de vista previa comparte origen con el editor, así que el entorno de pruebas se limita a leer directamente la opción:

try {
  if (localStorage.getItem('cinevva-gc-profile') !== 'wechat-minigame') return;
} catch (e) { return; }

Para cualquier juego que no sea de WeChat, el script consiste en una única comparación de cadenas y un retorno anticipado. Sin indicador de compilación, sin viajes de ida y vuelta al servidor y sin estado que sincronizar con el service worker.

La lista de bloqueos y la taxonomía de dos niveles

No todas las infracciones merecen la misma respuesta, así que el entorno de pruebas distingue dos niveles. Las API que no existen en WeChat lanzan una excepción, porque eso es lo que sucede después de exportar y un fallo durante la generación es la representación más honesta de un fallo durante la revisión. Las cosas que existen pero fallan más adelante se señalan mediante errores claros en la consola sin modificar su comportamiento, porque bloquearlas ocultaría el estado real del juego a la persona que está iterando sobre él.

El nivel que lanza excepciones: la creación de cualquier elemento de interfaz HTML, tanto mediante createElement como mediante createElementNS —Three.js crea su canvas con la variante NS, así que ambas rutas necesitan el mismo control—, eval, new Function, requestPointerLock y el registro de service workers. Cada excepción incluye la solución en su mensaje:

throw violate("document.createElement('" + tag + "') — Los minijuegos de WeChat no tienen DOM. " +
  "Dibuja la interfaz en un canvas (canvas 2D fuera de pantalla -> THREE.CanvasTexture sobre un quad en espacio de pantalla) " +
  "y realiza tú mismo la detección de toques.");

El nivel de avisos: leer indexedDB —devuelve undefined, exactamente igual que WeChat, además de un error que señala a localStorage—, audio en cualquier formato que WeChat para iOS no pueda decodificar —comprobado en tres lugares: el constructor Audio, el setter src del prototipo del elemento multimedia y las URL obtenidas—, solicitudes de red a cualquier origen que no sea el del propio juego o nuestra CDN de recursos —en WeChat requieren un dominio incluido en la lista blanca y registrado mediante ICP— y la aparición de Tone.js en cualquier lugar.

También hay una auditoría posterior a la carga que se ejecuta un momento después de que la página se estabilice: recorre <body> e informa de cualquier elemento HTML introducido mediante el propio marcado del juego en lugar de crearse dinámicamente. Los HUD estáticos eluden fácilmente un control sobre createElement, así que ese control por sí solo no basta.

Todos los informes se deduplican por mensaje y se limitan a cincuenta por sesión. Un error de bucle invertido que crea un div por fotograma produce un solo error, no una avalancha que ahogue la señal.

Las cuatro excepciones que más nos enseñaron

Construir un sandbox consiste principalmente en decidir qué no bloquear, y cada excepción surgió cuando nuestras propias herramientas dejaron de funcionar durante el desarrollo.

Nuestro depurador funciona con eval. La herramienta execute_js del creador, que la IA utiliza para inspeccionar el juego en ejecución, evalúa código mediante el gestor de mensajes del script de captura, que llama a eval. Bloquear eval sin más habría cegado a la propia IA. La solución: antes de bloquearlo, el entorno guarda la función real en una propiedad no enumerable, y el gestor del script de captura recurre a ella:

Object.defineProperty(window, '__cinevvaRealEval', { value: window.eval, enumerable: false });
window.eval = function () { throw violate('eval() está prohibido en los minijuegos de WeChat.'); };
// script de captura, al recibir el mensaje:
returnValue = (window.__cinevvaRealEval || eval)(e.data.code);

El código del juego que intente utilizar eval sigue fallando. El depurador no.

El grabador también crea elementos. Nuestro grabador de vídeos cortos se inyecta en el iframe del juego como un <script> creado mediante el propio document.createElement del iframe, y descarga los vídeos terminados mediante un clic sintético en un elemento <a>. Bloquear esas etiquetas habría roto la grabación únicamente en el modo WeChat. Por eso script sigue estando permitido y a genera un aviso sin lanzar una excepción. Un juego que incluya un enlace real sigue siendo señalado, y las herramientas continúan funcionando.

Los eventos de teclado se mantienen. La IA verifica los controles mediante una herramienta que simula pulsaciones de teclas y después comprueba cómo ha cambiado el estado del juego. Suprimir la entrada de teclado para simular un teléfono habría destruido el ciclo de verificación de controles que detecta errores de cámara invertida. La prioridad de los controles táctiles se aplica mediante las reglas de generación y el esquema de controles del perfil, no mediante el sandbox.

WebGL2 se mantiene, y el motivo merece su propia sección más abajo. La lista inicial de bloqueos impedía usar getContext('webgl2') para forzar el renderizado «compatible con WebGL1» que exigía el perfil. El problema es que Three.js eliminó por completo la compatibilidad con WebGL1 en r163, y nosotros fijamos la versión r181: bloquear WebGL2 habría dejado en blanco todos los juegos 3D del modo. La regla de renderizado del perfil era incoherente y se había escrito desde una concepción desactualizada de la plataforma. La auditoría del sandbox terminó auditando la propia especificación del sandbox, y seguir ese hilo nos llevó a un hallazgo importante.

La cuestión de WebGL2, respondida como es debido

No interferir con la creación del contexto planteó la siguiente pregunta obvia: si nuestro motor requiere WebGL2, ¿dejan de funcionar los juegos en dispositivos WeChat que solo tienen WebGL1? Investigarla nos dio la imagen más clara que tenemos del mínimo de renderizado de la plataforma, así que aquí está, acompañada de fuentes.

En Android, el entorno de ejecución de minijuegos de WeChat ofrece WebGL2 con cualquier biblioteca base moderna, y el hardware GLES3 subyacente es prácticamente universal. iOS es donde está la verdadera historia. La documentación técnica de WeChat sobre la compatibilidad con WebGL2 y el modo high-performance+ explica que, en iPhone, WebGL2 solo está disponible correctamente en el entorno high-performance+, que requiere un cliente reciente de WeChat —8.0.45 o posterior, y una versión superior en iOS 14— y, en la práctica, iOS 15.5 o posterior. Según la propia descripción de Tencent, el modo high-performance normal ejecuta WebGL2 «con más problemas», y el entorno normal de iOS no lo ofrece en absoluto.

La forma del fallo es lo realmente peligroso. En entornos incompatibles, getContext('webgl2') puede devolver un contexto válido en apariencia pero roto en lugar de null, un comportamiento que los desarrolladores han pedido directamente a Tencent que corrija. Un juego que confíe en el valor devuelto no falla de forma limpia. Muestra gráficos corruptos o una pantalla negra sin ningún aviso.

Así lo abordamos, en tres capas. El sandbox no modifica la creación de contextos WebGL2, porque bloquearla supondría luchar contra nuestro propio motor. Ahora, el perfil de generación exige una comprobación de arranque en todos los juegos: la creación del renderizador debe estar envuelta en try/catch y seguida de una prueba funcional (typeof gl.createVertexArray === 'function', una capacidad exclusiva de WebGL2 que un contexto falso no tendrá), con un mensaje cordial dibujado en el canvas que diga «actualiza WeChat» si falla, en lugar de mostrar una pantalla en blanco. Es el mismo patrón que emplean los minijuegos convertidos desde Unity, razón por la cual normalmente se ven avisos de actualización y no pantallas negras. Y, cuando esté listo, el exportador fijará el modo high-performance+ en game.json para que la ruta compatible sea la predeterminada.

¿Cuál es el coste de exigir WebGL2 para la audiencia? Los usuarios con versiones anteriores a iOS 15.5 o clientes de WeChat anteriores a la 8.0.45: un porcentaje bajo de un solo dígito en 2026, pero concentrado en dispositivos antiguos, lo que importa más en algunos géneros que en otros. Si los datos reales de distribución llegan a indicar que merece la pena perseguir esa cola, tenemos reservada una vía de escape barata: fijar el perfil de WeChat en Three r162, la última versión compatible con WebGL1. Los juegos del perfil solo utilizan API básicas y estables, por lo que bajar de versión supone cambiar una sola línea del mapa de importaciones; una opción que mantendremos deliberadamente sin usar hasta que los datos la justifiquen.

Cerrar el ciclo con el modelo

Esta es la parte que hace que todo esto merezca la pena para un producto centrado en la IA. Después de cada compilación, el agente del creador llama a una herramienta que lee la consola del juego y espera a que termine el arranque. El script de captura reenvía console.error a ese flujo. Por eso, una infracción [wechat-strict] no es un aviso que una persona pueda pasar por alto al desplazarse. Llega al canal exacto que el modelo ya comprueba antes de declarar terminada una compilación, en el mismo turno y con la solución explicada en el mensaje.

El perfil de generación cierra la última brecha con una instrucción: tratar cada mensaje [wechat-strict] como un error que impide completar la compilación, corregir la causa y no intentar nunca detectar ni eludir el entorno de pruebas. Un juego que solo funciona con el sandbox desactivado es un juego que fallará después de exportarlo, y eso es exactamente lo que se le dice al modelo.

En la práctica, el sandbox convierte un problema difuso de cumplimiento —«¿ha seguido el modelo las catorce reglas?»— en el ciclo de depuración que el sistema ya sabe resolver bien —«la consola muestra un error; corrígelo»—.

Lo que un navegador no puede simular

La sección de honestidad. Este sandbox detecta infracciones relacionadas con la superficie de las API, que, según nuestras estimaciones, representan la gran mayoría de los problemas capaces de arruinar una adaptación. No puede detectar el rendimiento en un teléfono real, la ejecución de JavaScript sin JIT en iOS, las peculiaridades de la implementación WebGL de WeChat ni las diferencias de comportamiento de los códecs más allá de las extensiones de archivo. Para eso hace falta el entorno real.

Por eso el sandbox es el primero de tres niveles. El segundo, una vez que nuestro exportador genere proyectos para las herramientas de desarrollo de WeChat, será el simulador oficial controlado sin interfaz mediante la CLI de DevTools y miniprogram-automator: arrancar el paquete exportado, comprobar que se renderiza el primer fotograma y automatizar un toque. El tercero es la ruta oficial en dispositivos: códigos QR de vista previa y depuración remota en teléfonos físicos, donde residen las verdades que ningún otro entorno puede revelar. Cada nivel es más lento y más fiel que el anterior, y la función de cada uno es hacer que resulte poco frecuente tener que pasar al siguiente.

Si quieres probar el modo, activa el interruptor «Modo de minijuegos de WeChat» en el Creador de Juegos. Para conocer el contexto comercial y normativo, consulta nuestra guía práctica para llegar a los quinientos millones de jugadores de WeChat.

Referencias

• Documentación oficial de WeChat: compatibilidad con JavaScript en minijuegos
• Documentación oficial de WeChat: la capa de adaptación
• Documentación oficial de WeChat: modo de alto rendimiento+
• Documentación de ingeniería de WeChat: compatibilidad con renderizado WebGL2 en minijuegos
• Documentación de ingeniería de WeChat: modos de alto rendimiento y alto rendimiento+ en iOS
• Comunidad de desarrolladores de WeChat: los contextos WebGL2 no funcionales deben devolver null
• Documentación oficial de WeChat: miniprogram-automator
• Notas de la versión r163 de Three.js (se eliminó la compatibilidad con WebGL1)

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Si creas juegos web, hay un mercado de 500 millones de jugadores mensuales al que tus juegos no pueden llegar, por muy buena que sea su compatibilidad con dispositivos móviles. Está dentro de WeChat, sus ingresos casi se duplicaron el año pasado y entrar en él exige tanto una adaptación técnica como un proceso regulatorio del que la mayoría de los desarrolladores occidentales nunca han oído hablar.

Acabamos de lanzar la primera parte de nuestra respuesta: un modo experimental para minijuegos de WeChat en Cinevva Game Creator. Este artículo cuenta la historia completa: qué es realmente la plataforma, cuáles son sus reglas y cómo sería una vía realista para un desarrollador de fuera de China.

El mercado, en cifras fáciles de subestimar

WeChat es la aplicación de comunicación de referencia en China, con una base total de más de 1.400 millones de usuarios activos mensuales. Los minijuegos funcionan dentro de ella como experiencias de juego instantáneas: no requieren instalación ni tienda de aplicaciones y pueden iniciarse desde un mensaje de chat, una búsqueda o un contenido compartido. En 2025, Tencent anunció que la plataforma de minijuegos había superado los 500 millones de usuarios activos mensuales, con más de 1.000 millones de jugadores registrados y unos 500.000 desarrolladores.

El dinero también es real. El mercado chino de minijuegos generó 39.800 millones de yuanes en 2024, unos 5.600 millones de dólares, lo que supone un crecimiento interanual del 99 %. Aproximadamente el 69 % procedió de compras dentro de la aplicación y el 31 %, de la publicidad. Conviene recordar ese reparto, porque la parte publicitaria resulta ser muy importante para los desarrolladores extranjeros.

Para ponerlo en perspectiva: los ingresos de los minijuegos durante ese único año son comparables a los de todo el mercado mundial de juegos web sobre el que se asientan plataformas como Poki, CrazyGames e itch.io. No es un nicho. Es un universo paralelo con sus propias reglas.

Por qué no puedes adaptar tu juego web sin más

Un minijuego de WeChat parece un juego web y está escrito en JavaScript, así que es natural asumir que adaptarlo solo requiere un fin de semana de trabajo. No es así, y los motivos son estructurales.

Los minijuegos no se ejecutan en un navegador. Se ejecutan en el entorno de ejecución propio de WeChat, que proporciona un lienzo, WebGL y un conjunto de API wx.*. No hay DOM ni CSS. Todos los botones, barras de salud, menús y cuadros de diálogo de tu juego deben dibujarse en el lienzo, y tu propio código debe detectar las interacciones con ellos. Si la interfaz de tu juego está hecha con HTML, esa interfaz no existe en WeChat.

El modelo de entrada también es distinto. No hay Pointer Lock ni ratón, por lo que una cámara de FPS pensada para ordenadores debe convertirse en una cámara controlada arrastrando el dedo. Tampoco hay teclado en el dispositivo principal. Si tu juego no puede jugarse por completo usando únicamente controles táctiles, no puede jugarse.

Los paquetes están limitados a 4 MB para el paquete principal y a 20 MB en total mediante subpaquetes, y todo lo que ejecute el juego debe estar dentro de ese paquete revisado. Esto nos lleva a la regla que define toda la plataforma: WeChat prohíbe la ejecución dinámica de código. Nada de eval, new Function ni descarga de JavaScript en tiempo de ejecución; además, Tencent rechaza activamente las aplicaciones que incorporan intérpretes de JS para sortear esta restricción. Cada juego es un artefacto cerrado y revisado.

Esta última regla explica por qué nunca habrá una «aplicación portal» que transmita juegos web a WeChat, ni nuestra ni de nadie. Cada juego pasa por el proceso de revisión como un minijuego independiente. Cualquier herramienta que quiera ayudarte en este ámbito debe permitirte producir paquetes limpios, autónomos y basados exclusivamente en lienzo. Esa es la restricción de diseño en torno a la cual desarrollamos nuestro nuevo modo.

La realidad regulatoria

Ahora viene la parte que no tiene nada que ver con el código. China regula los juegos como medios publicados y los requisitos se acumulan en varias capas. Ninguno de ellos es secreto, pero casi nadie fuera de China los explica con claridad, así que aquí los tienes.

Registro ICP. Desde finales de 2023, todos los miniprogramas y minijuegos deben completar un registro ICP —un trámite ante las autoridades chinas realizado a través de la plataforma de WeChat—. Suele tardar entre una y tres semanas.

Prueba de derechos de autor para cada título. Cada juego necesita un registro de derechos de autor de software o la certificación electrónica de derechos de autor, que es más rápida. El proceso electrónico tarda aproximadamente entre diez y quince días por juego. Es un coste por título, algo importante si tienes previsto publicar muchos juegos pequeños.

El banhao, si cobras dinero. Todo juego con compras dentro de la aplicación necesita una licencia de publicación de juegos de la Administración Nacional de Prensa y Publicaciones, conocida universalmente como banhao. Hay dos hechos que determinan lo que esto implica para ti como desarrollador extranjero. Primero, solo una empresa china puede solicitarla. Segundo, los títulos importados pasan por un proceso de aprobación independiente y más lento, que históricamente tarda entre seis y ocho meses cuando avanza. En la práctica, un desarrollador de fuera de China solo puede publicar un juego monetizado a través de una editora nacional con licencia que presente el juego, sea titular de la licencia y se encargue de su explotación.

La excepción para juegos gratuitos con publicidad. Un juego gratuito sin pagos de ningún tipo no necesita un banhao. Aun así, puede generar ingresos mediante los componentes publicitarios propios de WeChat y, recuerda, la publicidad representó el 31 % de los ingresos de los minijuegos en 2024: más de 1.700 millones de dólares. Esta es la única vía que un pequeño desarrollador puede recorrer sin un socio empresarial chino, y así es como opera buena parte de la larga cola del mercado.

El resumen honesto: publicar un minijuego gratuito financiado con publicidad implica trámites que se miden en semanas. Publicar uno monetizado es un proyecto de desarrollo empresarial que se mide en meses y requiere un socio que deberás elegir con cuidado.

Qué hace al respecto el modo de minijuegos de Cinevva

No podemos presentar los trámites por ti. Lo que sí podemos hacer es garantizar que el juego en sí nunca sea el obstáculo, desde el primer prompt.

Con el modo para minijuegos de WeChat activado, Game Creator crea dentro del subconjunto portable: una interfaz dibujada en lienzo en lugar de HTML; controles táctiles como prioridad, con control de cámara mediante arrastre en lugar de Pointer Lock; renderizado ajustado al rendimiento de un teléfono de gama media, con una pantalla alternativa elegante cuando no esté disponible WebGL2 real; un presupuesto estricto para recursos y audio exclusivamente en MP3; sin importaciones dinámicas ni carga de código en tiempo de ejecución; y partidas guardadas que se asignan a la API de almacenamiento de WeChat. El juego sigue ejecutándose en el navegador como cualquier juego de Cinevva, por lo que puedes crearlo, probarlo y compartirlo con normalidad. Simplemente se mantiene dentro del subconjunto que sobrevive a la adaptación.

El exportador que generará un proyecto de WeChat DevTools listo para abrir a partir de uno de estos juegos está en desarrollo. Elegimos este orden deliberadamente. Un exportador puede empaquetar tu código, pero no puede deshacer un HUD en HTML ni rediseñar controles que solo funcionan con ratón. La portabilidad depende de cómo se construye el juego, por eso el modo llegó primero.

Si has leído nuestra guía de motores para minijuegos o el tutorial de publicación para WeChat y Douyin, se trata de aplicar el mismo planteamiento a la generación: la adaptación más barata es la que nunca tienes que hacer.

Una estrategia realista para un desarrollador de fuera de China

Esto es lo que haríamos realmente con un primer título. Crearíamos algo pequeño y pensado para sesiones cortas, porque eso es lo que premia la plataforma: los éxitos son juegos que invitan a intentar una partida más, no aventuras épicas. Diseñaríamos primero para orientación vertical y exclusivamente para controles táctiles. Lo publicaríamos gratis con publicidad, lo que permite mantenerse al margen del banhao mientras averiguas si los jugadores chinos quieren tu juego. Nos encargaríamos directamente del registro ICP y de la certificación electrónica de derechos de autor; son procesos tediosos, pero asumibles. Y solo cuando el juego haya demostrado una buena retención y exista un potencial real de compras dentro de la aplicación, iniciaríamos las conversaciones con una editora llevando las cifras en la mano, porque una negociación cambia por completo cuando el juego ya tiene público.

Esa es la estrategia para la que se diseñó el nuevo modo: conseguir que producir juegos candidatos sea prácticamente gratuito, para que puedas permitirte descubrir qué funciona antes de empezar a gastar en el proceso regulatorio.

Si estás pensando en entrar en este mercado, nos gustaría sinceramente conocer tu opinión mientras el modo sigue tomando forma. Ponte en contacto o empieza a crear en Game Creator.

Referencias

• PocketGamer.biz: los minijuegos de WeChat superan los 500 millones de usuarios activos mensuales
• iChongqing: los minijuegos de WeChat alcanzan los 1.000 millones de usuarios
• Oreate: informe de 2025 sobre el desarrollo del ecosistema de minijuegos de WeChat (datos del mercado de 2024)
• Documentación oficial de WeChat: compatibilidad con JavaScript y prohibición del código dinámico
• Documentación oficial de WeChat: la capa de adaptación para código de estilo navegador
• Niko Partners: regulación de los juegos en China
• ClearLaunch: requisitos y aplicación de la aprobación de juegos en China (banhao)
• AppInChina: la guía completa de los minijuegos de WeChat

Por Mariana Muntean, CEO de Cinevva

La industria de los videojuegos generó unos 195.600 millones de dólares en 2025. Su mejor año hasta la fecha. Durante ese mismo periodo, aproximadamente uno de cada tres desarrolladores perdió su empleo.

Lee de nuevo esas dos frases. No deberían poder coexistir y, sin embargo, aquí estamos. Si te despidieron en los últimos dos años, ya sabes que las cifras no transmiten la sensación de una recesión. Es más bien como si te dijeran que el barco está bien mientras eres tú quien cae por la borda.

He sido desarrolladora independiente. He visto a amigos publicar el banner de «Open to Work» tres veces en dieciocho meses. Así que esto no es una opinión provocadora desde la barrera. Veamos qué ocurrió realmente y, después, la parte más importante si ahora mismo estás buscando trabajo: qué está consiguiendo de verdad que vuelvan a contratar a la gente.

Las cifras son peores de lo que parece

La ola de despidos comenzó en 2022 y nunca se detuvo realmente. No se trata de un mal trimestre. Es un reajuste estructural de cuatro años.

Eso supone aproximadamente entre 44.000 y 55.000 puestos de trabajo desaparecidos durante este periodo, dependiendo del registro en el que confíes (Wikipedia, GamesBeat). El informe State of the Game Industry 2026 de la GDC, basado en una encuesta a más de 2.300 profesionales, reveló que el 28 % de los desarrolladores de todo el mundo perdió su empleo en los últimos dos años, y la cifra asciende al 33 % en Estados Unidos (GamesIndustry.biz). La mitad afirmó que su empresa actual o más reciente había realizado despidos durante los últimos doce meses.

Norteamérica se llevó la peor parte. El seguimiento de la fuerza laboral realizado por Amir Satvat, lo más parecido que tiene esta industria a un censo continuo, muestra que el número de trabajadores de la región se redujo mientras que el total mundial apenas cambió. Cerca del 19 % de los trabajadores de la industria norteamericana del videojuego se vio afectado (GamesBeat).

Esta es la estadística que explica por qué buscar trabajo parece imposible incluso después de que la contratación se haya «recuperado». Satvat calcula que alrededor de 288.000 personas buscaban empleo en videojuegos durante este periodo. Recién graduados, veteranos despedidos y personas que estaban cambiando de carrera, todos solicitando el mismo conjunto limitado de vacantes. Cuando ahora envías tu currículum a una oferta de empleo, no compites con una docena de personas. Compites con un estadio entero.

Por qué un año récord también trajo cartas de despido

Los ingresos no desaparecieron. Se concentraron. Un número cada vez menor de gigantes de los juegos como servicio acapara una proporción desmesurada, lo que implica menos proyectos nuevos, menos equipos nuevos y menos proyectos medianos de los que antes absorbían talento. La inversión privada en videojuegos se redujo en más de la mitad en 2025 (Outlook Respawn). Los estudios respondieron como suelen hacerlo: cancelando proyectos, recortando presupuestos y trasladando trabajo a contratistas.

Así que los beneficios son reales y el sufrimiento también, y ambos apuntan a la misma causa. Es un pobre consuelo cuando eres tú quien actualiza constantemente la bandeja de entrada, pero revela algo útil. Este no es un mercado que esté esperando volver de golpe a 2021. Quienes consiguen que los vuelvan a contratar tampoco esperan que eso suceda. Se están adaptando al modo en que funciona realmente la contratación hoy.

El mercado laboral tiene un problema de autenticidad

Habla con cualquiera que evalúe candidatos hoy y escucharás la misma queja. Están desbordados. Las ofertas de empleo reciben cientos de solicitudes en cuestión de horas, y la mayoría parecen escritas por la misma persona porque, en cierto sentido, las ha escrito la misma herramienta.

Los responsables de selección dijeron a TechRound que lo difícil no es detectar el uso de IA, sino que la avalancha de «contenido bien optimizado y con poco contexto» hace casi imposible encontrar a la persona que realmente comprende el puesto (TechRound). La propia LinkedIn afirma ahora que detecta contenido genérico escrito por IA aproximadamente el 94 % de las veces y limita discretamente su alcance (TechRound).

Si le das la vuelta, se convierte en la mejor noticia de todo este artículo. Cuando todo suena igual, ser específico es un superpoder. En un flujo de contenido con un acabado idéntico, la persona que muestra trabajo y razonamiento reales no solo destaca. Es la única señal entre todo el ruido.

Las pruebas siempre vencen a la apariencia

En el caso concreto de los puestos relacionados con videojuegos, lo que marca la diferencia no es un PDF más bonito. Son pruebas que alguien puede experimentar. Un profesional de selección con doce años de experiencia lo expresó sin rodeos: una versión jugable o un reel de demostración te ayuda más que casi cualquier otra cosa de tu candidatura.

Ese es el cambio. Un currículum le dice a un responsable de selección que entiendes de diseño. Una muestra jugable le permite sentirlo en entre 30 y 90 segundos. No puedes fingir una mecánica funcional como puedes fingir un punto en una lista. No puedes fingir un nivel explorable, un shader en funcionamiento, un rig que se mueva de verdad ni una señal de audio interactiva vinculada a una escena real. La interactividad es una prueba que resiste el escrutinio, porque detrás de ella hay una persona capaz de defender cada decisión.

Y esto último es lo que realmente ponen a prueba los responsables de selección. El método que utilizan para detectar portafolios inflados con IA es sencillo: preguntar por el proceso, no por el resultado. Alguien que haya generado un caso de estudio puede describir lo que dice, pero no las decisiones que hay detrás. Por eso, los portafolios más sólidos de 2026 incluyen los mismos cuatro elementos:

Esa parte de «conservaste, cambiaste y rechazaste» es la que la mayoría omite, y es la que demuestra criterio. El criterio es lo más difícil de fingir y es exactamente lo que compra un estudio: alguien capaz de elegir la idea correcta entre diez opciones plausibles. Evita la conclusión del tipo «aprendí muchísimo». Muestra la decisión que tomaste y por qué beneficiaba al jugador.

Unas palabras sobre la IA, porque esta industria se ha ganado el derecho a estar enfadada

Dirijo una plataforma que utiliza herramientas de IA y no voy a fingir que esa tensión no existe. La misma encuesta de la GDC reveló que el 52 % de los desarrolladores cree ahora que la IA generativa está teniendo un impacto negativo en la industria, frente al 18 % de hace dos años, y que la oposición más fuerte proviene de artistas, guionistas y programadores (GamesIndustry.biz). Cuando acaban de despedirte y te dicen que un modelo podría hacer una parte de tu antiguo trabajo, «usa IA para tu portafolio» es una bofetada, no un consejo.

Así que lo diré con claridad. Nadie consigue que lo contraten entregando a un responsable de selección algo generado por una máquina que no puede explicar. El trabajo tiene que ser tuyo. Tus decisiones, tu oficio, tu responsabilidad. Si utilizaste una herramienta en alguna parte de un proyecto, dilo y demuestra tu criterio por encima de ella: qué conservaste, qué descartaste y por qué tu decisión era mejor para el jugador. Los responsables de contratación confían en quien trata una herramienta como a un becario que necesita orientación, no en quien se esconde detrás de ella. Ser sincero sobre tu proceso transmite profesionalidad, y la profesionalidad a menudo se reduce a «pensé en las consecuencias antes de publicar».

Dónde colocar las pruebas

Un consejo práctico, ya que muchas de estas conversaciones comienzan en LinkedIn. El feed penaliza mucho los enlaces externos, pero la sección Destacado de tu perfil no lo hace. Es el único lugar que convierte un enlace en una tarjeta de vista previa limpia sin penalización, y aparece en la parte superior del perfil, donde miran primero los responsables de selección. Fija entre tres y cinco elementos, colocando primero tu mejor trabajo, y recuerda que la mayoría lo verá desde un teléfono. Empieza por aquello que alguien pueda abrir y experimentar en cuestión de segundos.

Haz que sea rápido y honesto. Una demo que carga en menos de dos segundos y muestra una idea clara supera a un proyecto ambicioso que se entrecorta o devuelve un error 404. Los responsables de selección que revisan treinta portafolios en una tarde no esperan, y un enlace roto se interpreta como un mal hábito.

Por qué nos importa

En Cinevva creamos juegos para navegador que pueden jugarse al instante, lo que significa que gran parte de nuestro trabajo resulta ser exactamente lo que necesita un portafolio moderno: trabajo real que un responsable de selección puede abrir y jugar desde un único enlace, sin descargas ni instalaciones. Estamos prestando mucha atención a este problema porque quienes lo sufren son los nuestros. Si te despidieron, tus habilidades no se evaporaron. El mercado se volvió más ruidoso y cambió la forma de demostrar lo que sabes hacer.

La pregunta anterior era «¿dónde has trabajado?». La nueva es «enséñame algo que pueda jugar y dime por qué lo creaste así». Esa segunda pregunta es más difícil de manipular y mejor para quienes realmente saben hacer el trabajo. Si eres una de esas personas, este mercado es brutal, pero no está cerrado. Está esperando pruebas en las que pueda confiar.

Fuentes

• State of the Game Industry 2026 de la GDC: despidos, IA y sindicalización
• GamesBeat: la fuerza laboral mundial de los videojuegos creció un 0,6 % en cuatro años, mientras que la de Norteamérica se redujo
• Wikipedia: despidos en la industria de los videojuegos entre 2022 y 2026
• Outlook Respawn: beneficios récord, despidos récord
• Game Developer: los despidos se están ralentizando, pero el daño ya está hecho
• TechRound: LinkedIn afronta una oleada de contenido basura generado con IA

Relacionado:

• El mercado laboral se está transformando: de las credenciales a las habilidades
• La polémica de la IA, la confianza y la economía pos-IA de los videojuegos
• La mente intuitiva en la era de la IA

Por Mariana Muntean, CEO de Cinevva

Bueno, desde luego no teníamos pensado pasarnos una semana entera en itch.io. Lo que empezó como una búsqueda rápida se convirtió en... en fin, dejamos de contar más o menos al llegar a las doce horas. La idea era encontrar juegos a los que puedas jugar de inmediato: sin descargas ni instaladores trabajando en segundo plano. Haces clic y ya estás dentro. Así de fácil.

Estos son los que pasaron el corte.

Experiencias interactivas mejor valoradas

Adventures With Anxiety! — Historia interactiva Más de 6500 valoraciones con una media de 4,9. Es increíble que algo que te obliga a enfrentarte de lleno a la ansiedad tenga tantos seguidores, ¿verdad? Resulta incómodo de la mejor manera posible: de esa que se queda contigo. Juega aquí

We Become What We Behold — Crítica social 7600 valoraciones y una puntuación de 4,8/5. Diez minutos para terminarlo. Días para dejar de pensar en él. Juega aquí

Six Cats Under — Aventura de puzles Acogedor e ingenioso. El apartado visual hace gran parte del trabajo, y eso juega a su favor. Un 4,8/5 según más de 6400 personas. Juega aquí

Friday Night Funkin' — Juego de ritmo A estas alturas está por todas partes. Más de 11 700 valoraciones y un 4,7/5. Juega aquí

Sort the Court! — Simulador de reino Tu única tarea: decir sí o no. No parece gran cosa. Y entonces desaparecen dos horas mientras sigues gobernando un pequeño reino. Juega aquí

Dragonsweeper — Roguelike de puzles Toma el Buscaminas y mézclalo con sistemas de RPG. Un 4,9/5: puede que sea el mejor juego de toda la lista. Juega aquí

Roguelike y estrategia (jugables en el navegador)

Backpack Hero — Roguelike de gestión de inventario La versión para navegador es completamente gratis. La versión de pago añade más contenido, pero la versión web gratuita se sostiene por sí sola. Juega aquí

Vampire Survivors — Bullet heaven Solo es una demo: un escenario y siete personajes. Aun así, basta para entender por qué este juego devoró el tiempo libre de todo el mundo. Juega aquí

Dome Romantik — Defensa y minería Empezó como un proyecto para una game jam. Se convirtió en Dome Keeper. Y acabó siendo todo un éxito. El prototipo original sigue siendo muy bueno. Juega aquí

¿Por qué estos en concreto?

Probamos todos y cada uno de los enlaces. No fue un vistazo rápido: nos sentamos a jugar de verdad. Cargan sin complicaciones. Sin rarezas del navegador. Miles de valoraciones proceden de personas que nunca tocaron un botón de descarga; hicieron clic y empezaron a jugar directamente. ¿Ese camino sin fricciones entre «vaya, qué interesante» y jugar de verdad? La mayoría subestima hasta qué punto lo cambia todo.

Descubre más juegos web

¿Todavía quieres más?

• Juegos HTML5 mejor valorados en itch.io
• Mejores juegos de plataformas HTML5
• Juegos de 2024-2025

Juegos indie destacados (requieren descarga)

Hay juegos excelentes que no funcionan en el navegador. Estos merecen el paso adicional:

Slice & Dice — Roguelike de dados Funciona en Windows, Mac y Android. Consíguelo en itch.io

Stacklands — Construcción de aldeas con cartas Para Windows y Mac. Consíguelo en itch.io

Luck be a Landlord — Roguelike de máquina tragaperras Parece una ocurrencia pasajera. No lo es. Hay estrategia de verdad bajo esa apariencia de máquina tragaperras. itch.io

Patrick's Parabox — Puzles recursivos Prepárate para que te duela la cabeza. Y para disfrutarlo de todos modos. itch.io

Dome Keeper — Defensa y minería La versión completa de aquel prototipo de game jam que mencionamos. Encuéntralo en Steam

Brotato — Supervivencia en arena Disponible en Steam

Si creas juegos, hay algo sobre lo que vale la pena reflexionar: las versiones para navegador no interponen nada entre los jugadores y tu obra. No hay una descarga esperando en una cola que acabarán olvidando. No hay pantallas de instalación que superar. Con un clic ya están formándose una opinión sobre lo que has creado. No se habla lo suficiente de esa inmediatez, pero lo cambia todo.

¿Quieres lo mismo para tu propio juego? Puedes crear uno directamente en el navegador con el creador de juegos de Cinevva, y los que destacamos aparecen en nuestro Arcade de la comunidad.

• Para creadores de juegos
• Crea un juego web que cargue rápido

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Si quieres publicar un juego 3D que funcione en un navegador en 2026, tienes cuatro opciones consolidadas y algunas más recientes. Suelen agruparse bajo la etiqueta de «motores de juegos web», pero en realidad son herramientas muy distintas que resuelven problemas diferentes. Elegir la equivocada puede costarte meses. Esta es una comparación actual y verificada, escrita por personas que se dedican a desarrollar un motor 3D para la web y que evaluaron todas estas opciones antes de crear el suyo propio.

Repasaremos cada opción, qué es realmente, para quién está pensada y dónde se queda corta, y al final te ofreceremos una breve guía de decisión. Cuando mencionamos números de versión, son correctos a julio de 2026.

¿Buscas una visión completa del mercado? Este artículo se centra en las cuatro principales opciones 3D. Para ver los 11 motores web clasificados y comparados —incluidas opciones 2D como Phaser, Defold y Construct—, consulta nuestra guía de los mejores motores de juegos web para 2026.

Comparación rápida

El resto de este artículo explica la tabla.

PlayCanvas

PlayCanvas es lo más parecido que existe en la web a un flujo de trabajo al estilo Unity. El motor es de código abierto bajo la licencia MIT y se encuentra en la versión 2.20.6 a julio de 2026. Utiliza un sistema de entidad-componente, permite escribir la lógica del juego en TypeScript o JavaScript y procesa los recursos mediante una canalización del lado del servidor que genera archivos GLB. Hay juegos comerciales reales que funcionan con él y grandes empresas lo utilizan en producción; Snap es un ejemplo público.

Conviene aclarar dos aspectos de PlayCanvas que suelen malinterpretarse. En primer lugar, aunque el motor tiene licencia MIT, el editor visual alojado que realmente utilizan la mayoría de los equipos es un producto comercial, no de código abierto. Puedes usar el motor gratuitamente sin él, pero el flujo de trabajo de editor más nube es la parte de pago. En segundo lugar, PlayCanvas se centra ante todo en WebGL2. Tiene una ruta WebGPU, pero todavía está madurando y aún no es el renderizador predeterminado, así que no elijas PlayCanvas hoy esperando usar shaders de cómputo WebGPU en producción.

Donde PlayCanvas destaca de verdad es en el Gaussian splatting 3D. Su editor y visor SuperSplat, cuyo código abrió el equipo, se encuentran entre las mejores herramientas disponibles para capturar y publicar escenas de splats en la web, con streaming basado en WebGPU para capturas de gran tamaño. Si lo tuyo son los entornos escaneados fotorrealistas, esa es una razón de peso para empezar aquí.

Elige PlayCanvas si quieres un editor similar a Unity y una canalización de recursos gestionada para el navegador, y estás publicando el tipo de juego que desarrollaría un estudio. Busca otra opción si necesitas cómputo WebGPU hoy o quieres evitar un editor comercial alojado.

Three.js

Three.js no es un motor de juegos. Es una biblioteca de renderizado y, con mucha diferencia, la más utilizada de este ámbito. Te proporciona un grafo de escena, cámaras, luces, materiales, geometría, cargadores y un renderizador, y ahí se detiene. No incluye editor, física, sistema de entidades ni una forma impuesta de estructurar un juego. Todo eso debes añadirlo tú o tomarlo del ecosistema.

Ese intercambio lo define todo. Obtienes el máximo control y la comunidad más grande del 3D web, a cambio de tener que crear o integrar todo lo que se sitúa por encima del renderizador. Su renderizador WebGPU ha crecido de forma constante y ya puede utilizarse, aunque, como ocurre con los demás, la ruta WebGL2 sigue siendo la opción predeterminada más madura. Three.js tiene licencia MIT.

Elige Three.js si quieres control total, una base mínima y cuentas con la capacidad técnica necesaria para construir encima los sistemas de tu juego. Busca otra opción si quieres que te proporcionen un editor y sistemas de juego ya preparados.

Babylon.js

Babylon.js es un motor completo con licencia Apache 2.0 y respaldado por un equipo de Microsoft. A diferencia de Three.js, incluye las piezas que de otro modo tendrías que integrar: un modelo de componentes, el motor de física Havok integrado, un editor web gratuito y una canalización de recursos. Su trabajo con WebGPU ha avanzado rápidamente y se encuentra entre los más desarrollados de los motores de propósito general, aunque sigue manteniendo WebGL2 como ruta de amplia compatibilidad. Babylon.js 9.0 (marzo de 2026) amplió aún más esa ventaja con iluminación agrupada en ambos backends, iluminación volumétrica basada en shaders de cómputo WebGPU y compatibilidad con sombras para splats gaussianos 3D.

Si tu planteamiento es «quiero un motor completo, con física incluida, y me parece bien trabajar según sus convenciones», Babylon es una opción predeterminada sólida y posiblemente la alternativa gratuita con más funciones de este ámbito.

Elige Babylon.js si quieres todo incluido, física integrada y un editor gratuito. Busca otra opción si quieres una dependencia mínima o buscas específicamente un flujo de trabajo alojado al estilo Unity.

Unity WebGL

Unity WebGL no es un motor web, sino un destino de exportación. Desarrollas en el editor de escritorio de Unity, con C#, y compilas un paquete WebGL que funciona en el navegador mediante WebAssembly. Esto lo convierte en la respuesta evidente para un caso concreto: ya tienes un juego de Unity y quieres una versión para navegador.

Para un proyecto concebido primero para la web, conlleva costes importantes. El entorno de ejecución y el peso de la descarga son considerables, el inicio es más lento que con un motor web nativo y el rendimiento en navegadores móviles es un problema conocido. Unity es propietario y su salida WebGL está orientada a WebGL2. Unity 6 incluye un backend WebGPU experimental, pero está desactivado de forma predeterminada y aún no está listo para producción.

Elige Unity WebGL si tienes un proyecto de Unity existente que quieres llevar al navegador o tu equipo ya trabaja por completo con Unity. Busca otra opción si la carga instantánea en teléfonos de gama media es un requisito indispensable o si empiezas desde cero con un enfoque web-first.

Dónde encajan la IA nativa y la creación dentro del mundo

Todas las opciones anteriores comparten una premisa: un desarrollador crea el juego sentado ante un escritorio, dentro de un editor, y publica un entorno de ejecución. Esa premisa es correcta para la mayoría de los proyectos y, si describe el tuyo, elige una de las cuatro opciones anteriores.

Conviene saber que esa premisa ya no es la única opción, porque está surgiendo una categoría diferente. Nosotros desarrollamos Cinevva, una plataforma de mundos exclusiva para WebGPU en la que los juegos se crean desde dentro del propio mundo. En lugar de abrir un editor, eres un avatar situado en el espacio, describes lo que quieres y un constructor con IA lo convierte en terreno, objetos y comportamientos mientras permaneces allí. La creación y el juego forman parte de la misma sesión. A nivel interno, esto implicó apostar exclusivamente por WebGPU con terreno generado mediante shaders de cómputo, escribir un solucionador de personajes personalizado en lugar de usar un motor de física general y construir un sistema de animación y retargeting. Hablamos de ello en por qué creamos nuestro propio motor WebGPU.

Esto no sustituye a PlayCanvas ni a Babylon. Si eres un desarrollador que crea un juego específico, esas son las herramientas adecuadas. Cinevva persigue un objetivo distinto: permitir que personas que no desarrollan motores creen y compartan espacios jugables simplemente describiéndolos. Lo mencionamos aquí porque la pregunta «¿qué motor de juegos web debería utilizar?» tiene cada vez más una quinta respuesta que ni siquiera es un motor.

Matriz completa de características

La tabla rápida del principio contiene los puntos principales. Esta es la versión detallada, agrupada por subsistema. Antes, algunas observaciones sinceras sobre cómo interpretarla. «BYO» significa que debes aportar tu propia solución; es decir, el motor no la incluye, pero puedes añadirla mediante el ecosistema o tu propio código. Esto resulta especialmente importante en Three.js, que es una biblioteca de renderizado por diseño, por lo que «BYO» representa una característica de su filosofía, no una carencia. «Solo mediante exportación» en Unity significa que la capacidad existe en el editor de escritorio y se incorpora a la compilación WebGL, en lugar de ser nativa de la web. Las celdas de los competidores reflejan las funciones disponibles de serie y el comportamiento bien documentado a mediados de 2026. Las celdas de Cinevva reflejan lo que funciona en nuestra versión publicada; «previsto» indica aquello que está diseñado, pero aún no se ha desarrollado.

Renderizado

Mundo y terreno

Física y personajes

Animación

Multijugador y backend

Creación y herramientas de autoría

Recursos y distribución

El patrón de la matriz es la verdadera historia. Los motores de propósito general distribuyen sus fortalezas horizontalmente: cada uno hace la mayoría de las cosas de forma competente y te deja a ti el mundo, el backend y el flujo de creación. Cinevva se concentra verticalmente: hace menos cosas, pero controla todo el recorrido, desde el renderizador hasta un mundo compartido que creas desde dentro. Ninguno de los dos enfoques es mejor en términos absolutos. Responden a preguntas diferentes.

Cómo elegir

Adapta la herramienta a la situación en lugar de guiarte por una lista de características. Si ya tienes un juego hecho con Unity, expórtalo con Unity WebGL y acepta su peso. Si sois un estudio que busca un flujo de trabajo basado en un editor para juegos de navegador, usad PlayCanvas. Si quieres un motor gratuito y completo con físicas incluidas, usa Babylon.js. Si quieres control total y cuentas con un equipo capaz de desarrollar sobre un renderizador básico, usa Three.js. Y si tu objetivo no es crear un solo juego, sino permitir que la gente cree y juegue dentro de un mundo compartido describiendo cosas, esa es la categoría en la que trabajamos, y puedes probar Cinevva.

Elijas lo que elijas, evalúalo con prototipos reales antes de comprometerte. Cada una de estas opciones puede sustentar un juego de verdad, y el coste de cambiar a mitad del desarrollo se mide en los meses que no dedicaste a publicar.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Toda persona con perfil técnico que ve Cinevva World hace la misma pregunta en menos de cinco minutos. Sois un equipo pequeño. Ya existen motores 3D maduros para la web. ¿Por qué escribisteis vuestro propio renderizador, vuestro propio sistema de física de personajes y vuestro propio sistema de animación, en lugar de apoyaros en PlayCanvas o Babylon y lanzar el producto antes?

Es una pregunta razonable, y «no se inventó aquí» no es una respuesta válida. Hicimos los deberes. Probamos los motores existentes, leímos su código fuente y desarrollamos prototipos sobre dos de ellos antes de tomar una decisión. Esta publicación cuenta la versión sincera de esa decisión: en qué destacan realmente las opciones disponibles, los cuatro puntos en los que nuestras necesidades divergieron lo suficiente como para justificar una solución propia y las situaciones en las que deberías elegir una de esas opciones en vez de imitarnos. Documentamos el propio desarrollo en una extensa serie de ingeniería sobre cómo crear un mundo abierto en el navegador, así que, cuando alguna afirmación de este artículo tenga detrás un registro práctico, incluiré un enlace.

Las opciones que evaluamos de verdad

Hay cuatro cosas a las que se suele llamar «motores de juegos web», pero no son el mismo tipo de herramienta.

Three.js es una biblioteca de renderizado, no un motor de juegos. Te proporciona un grafo de escena, materiales, cargadores y un renderizador, y después se aparta de tu camino. No incluye editor, física ni sistema de entidades, y tampoco impone una estructura para tu juego. Eso es tanto su atractivo como su coste. Tienes que construir por tu cuenta todo lo que está por encima del renderizador, pero nada se interpone en tu camino. Tiene licencia MIT, cuenta con el ecosistema más grande del sector y, cuando te encuentras con un oscuro error de shaders a las dos de la mañana, suele haber una respuesta esperándote en algún foro.

Babylon.js es un motor completo con un grafo de escena, una integración de física (Havok), un pipeline de recursos y un editor web. Tiene licencia MIT, cuenta con el respaldo de un equipo de Microsoft y su trabajo con WebGPU ha avanzado rápidamente. Si quieres una solución con todo incluido y te sientes cómodo trabajando dentro de la estructura del motor, es una excelente opción predeterminada.

PlayCanvas es lo más parecido a un «Unity para la web». En el momento de escribir esto, el motor está en la versión 2.19.6, publicada el 5 de junio de 2026, y su código es abierto bajo licencia MIT. Sin embargo, lo que la mayoría utiliza realmente es el editor visual alojado, que es un producto comercial y no es de código abierto. PlayCanvas emplea un sistema de entidades y componentes; permite programar en TypeScript o JavaScript; procesa los recursos mediante un pipeline GLB del lado del servidor; y ya se han publicado con él juegos comerciales reales (Snap, por ejemplo, utiliza PlayCanvas en producción). Su renderizador funciona con WebGL2 y dispone de una ruta WebGPU que todavía está madurando, en lugar de ser la opción predeterminada. Este último detalle importa más de lo que parece, y volveré a él más adelante.

Unity WebGL no es en absoluto un motor web. Es un destino de exportación. Creas el juego en el editor de escritorio de Unity y lo compilas como un paquete WebGL. Es la herramienta adecuada cuando ya tienes un juego hecho con Unity y quieres llevarlo al navegador, y la herramienta equivocada cuando «cargar al instante en una pestaña de un teléfono de gama media» es un requisito innegociable, porque el tiempo de ejecución y el peso de la descarga vienen incluidos.

Cualquiera de estas opciones es una base razonable para un juego web normal. Nosotros no teníamos un juego web normal.

Primera decisión: WebGPU es nuestro punto de partida, no nuestra meta

La diferencia que nos aleja de todas las soluciones disponibles es esta: para nosotros, WebGPU es un requisito, no una función que incorporaremos con el tiempo.

Nuestro terreno no es un mapa de alturas estático. Es un sistema híbrido formado por un campo de mapas de alturas transmitido por streaming y chunks de marching cubes respaldados por un campo de distancias con signo. Gracias a ello, el mundo puede tener cuevas y salientes reales, y los creadores pueden esculpirlo en directo. Los pinceles de esculpido, la dispersión de vegetación y la generación de la malla del terreno se ejecutan como shaders de cómputo. Si eliminas el cómputo, el mundo no pierde calidad: sencillamente deja de funcionar.

Eso es justo lo contrario de la situación actual de los motores de propósito general. Su compatibilidad con WebGPU está diseñada como una mejora progresiva sobre un renderizador centrado en WebGL2, con una ruta alternativa para los navegadores que no lo admiten. PlayCanvas, en particular, prioriza WebGL2 y todavía mantiene WebGPU en fase beta. Es la decisión correcta para ellos, porque su cometido es ejecutar la mayor variedad posible de juegos en la mayor variedad posible de dispositivos. Nuestro cometido es más limitado y profundo, así que tomamos la decisión contraria: en el prototipo 13 pasamos a utilizar exclusivamente WebGPU y nunca miramos atrás. Los navegadores sin WebGPU no reciben una versión reducida, sino que no son compatibles, y medimos ese hecho como una cifra de alcance en vez de fingir que una alternativa basada en WebGL2 está a un único ajuste de configuración de distancia. No es así. Exigiría reescribir parcialmente nuestras etapas de terreno y vegetación.

Desarrollar sobre un motor centrado en WebGL2 habría implicado luchar contra sus supuestos de compatibilidad alternativa en cada función de cómputo o mantener para siempre dos rutas de renderizado. Controlar nuestro propio renderizador nos permitió tratar el cómputo como la base del sistema.

Segunda decisión: un solucionador para personajes, no un motor de física

La solución de manual consiste en incorporar un motor de física. Lo intentamos. Uno de los primeros prototipos validó Rapier ejecutándose en un worker, y funcionaba bien.

Aun así, escribimos nuestro propio sistema, y no hay rastro de Rapier, Cannon ni Ammo en la versión publicada. El motivo es el alcance. No necesitamos cuerpos rígidos, articulaciones, ragdolls ni un solucionador de restricciones. Necesitamos que una cápsula se mueva correctamente sobre el terreno, y necesitamos que caminar, deslizarse, planear, escalar y nadar compartan una única respuesta a «¿estoy tocando el suelo, sobre qué superficie y con qué ángulo?». Un motor de física general dificulta esa tarea en vez de facilitarla, porque esos modos terminan enfrentándose a sus resortes y amortiguadores internos.

Por eso, nuestro controlador de personajes es una máquina de estados multicanal conectable. Cada modo es una pequeña unidad que indica si quiere tomar el control durante este fotograma y, si gana, establece la velocidad y la orientación. Compiten por prioridad en tres canales —recurso, postura y locomoción— y todos consultan el mismo terreno. Las colisiones se resuelven mediante una sonda con forma de cápsula contra el mapa de alturas o el campo de distancias con signo, según el chunk.

El detalle del que más orgulloso estoy es poco llamativo. La detección del suelo examina todas las superficies de la columna vertical situada bajo tus pies y elige la más alta que esté a la altura de la cápsula o por debajo de ella, en vez de confiar en el gradiente del SDF. En el borde de un saliente, la superficie lateral más cercana es la pared del acantilado, por lo que una normal basada en el gradiente oscila entre «suelo» y «pared» y provoca deslizamientos fantasma. La consulta de la columna hace que estar de pie sobre un saliente resulte aburrido, que es exactamente lo que necesitas. Un collider de campos de altura listo para usar no nos habría proporcionado eso sin esfuerzo, porque, para empezar, no puede interpretar nuestro terreno. El terreno reside en la GPU y utiliza nuestro propio formato. Ningún motor externo puede detectar colisiones contra él sin que copiemos todo el campo a su formato de collider después de cada modificación.

Tercera decisión: animaciones que pueden trasladarse entre rigs

Los avatares utilizan el rig Synty POLYGON, y nuestros clips de movimiento proceden de una amplia biblioteca abierta de animaciones. Como el rig y los clips comparten nombres de huesos, el caso habitual no necesita retargeting durante la ejecución: las pistas simplemente se vinculan por nombre. Explicamos el pipeline completo de personajes en personajes universales.

El trabajo interesante aparece cuando no coinciden. Creamos una fase de retargeting que asigna un esqueleto a otro, y hacerla correctamente exigió resolver tres problemas concretos. Primero hay que alinear las poses de enlace, porque combinar una pose en A con una pose en T añade silenciosamente unos treinta grados por articulación. Hay que escalar el movimiento de la raíz y la zancada con dos proporciones distintas: de la cadera al suelo para el eje vertical y la proporción general para el horizontal. Y hay que probar los clips adaptados frente a sus originales con una frecuencia de muestreo fija, para que las regresiones aparezcan antes de que las vea un jugador. Ese pipeline es lo que nos permite añadir nuevas fuentes de animaciones y, con el tiempo, personajes aportados por los creadores, sin tener que corregir manualmente cada clip.

Por encima se encuentra una máquina de estados de animación que selecciona en cada fotograma la familia de clips adecuada a partir del estado de movimiento: la variante del salto según la velocidad, la intensidad del aterrizaje según el impacto, la dirección de la pendiente a partir del producto escalar entre la velocidad y el gradiente del terreno, las paradas ajustadas a la fase de los pies para evitar que el personaje parezca caminar sobre la luna al detenerse y un debounce de cien milisegundos para que un choque contra una pared no te haga alternar de forma intermitente entre caminar y caer. Nada de esto es exótico, pero es el tipo de resultado que solo consigues cuando controlas toda la capa.

Cuarta decisión: la parte que ningún motor incluye

Las otras tres decisiones tratan sobre cómo funciona el mundo. Esta trata sobre qué es el producto, y por eso compararlo con PlayCanvas es, en última instancia, un error de categoría.

PlayCanvas, Babylon, Unity y una aplicación de Three.js hecha a medida parten de la misma premisa: creas el juego sentado ante un escritorio, en un editor 2D, observando el mundo desde fuera; después pulsas el botón de reproducción y publicas un entorno de ejecución independiente. Incluso cuando permiten editar dentro del motor, sigues estando frente a una estación de trabajo, manipulando una escena que observas desde fuera.

Cinevva World invierte ese modelo. Creas desde dentro del mundo, como un avatar que ocupa el mismo espacio en el que estarán tus jugadores, describiendo lo que quieres y viendo cómo aparece. Crear y jugar forman una única sesión continua, no un paso de compilación conectado a un entorno de ejecución. Los referentes más cercanos son Roblox, Rec Room y Horizon Worlds, no los motores 3D web, e incluso aquellos conservan la mayor parte del proceso creativo en un escritorio. Lo que hace viable este enfoque sin un editor controlado con ratón es el constructor con IA, que convierte «coloca aquí un muelle iluminado con faroles» en geometría y posicionamiento.

No puedes añadir eso sin más a un motor de propósito general, porque no es una función de renderizado. Es la premisa de toda la arquitectura, desde la forma de editar el terreno durante la ejecución hasta el modo en que la red trata cada objeto como algo que una persona cercana acaba de crear.

Cuándo no deberías hacer lo mismo que nosotros

Esta es la parte que el género «creamos nuestro propio motor» suele omitir. Si quieres publicar un juego de navegador este trimestre, no nos imites. Usa PlayCanvas si quieres un editor al estilo Unity y un pipeline gestionado. Usa Babylon si quieres un motor completo con física incluida y te sientes cómodo dentro de su estructura. Usa Three.js si quieres el máximo control y el mínimo de decisiones impuestas, y cuentas con un equipo capaz de construir todo lo necesario sobre la biblioteca. Haz un port desde Unity si ya tienes un juego creado con Unity.

Escribir tu propio renderizador y tus propios sistemas de física y animación solo es la decisión correcta cuando la premisa de tu producto es incompatible con las soluciones disponibles, cuando lo que estás construyendo no es un juego ejecutado sobre un motor, sino un lugar que está hecho de uno. En nuestro caso era así. Probablemente no lo sea en el tuyo, y no pasa nada. El objetivo de evaluar las opciones con sinceridad es saber en qué caso te encuentras antes de escribir la primera línea.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Ahora podemos generar mundos, y no me refiero a una demo. La imagen de arriba muestra nuestro editor. Alguien escribió «construye una segunda planta» en un cuadro de chat y vio cómo la IA colocaba el forjado, levantaba las paredes frontal, laterales y trasera, y ofrecía continuar con unas escaleras y un tejado. No son objetos decorativos ni texturas, sino estructuras completas colocadas en un mundo al que otras personas pueden entrar. Nuestro sistema también crea los componentes: modelos 3D, música, sonido y materiales.

Así que estamos cerca de abrir Cinevva World al público. Y antes de hacerlo, me puse a leer las necrológicas.

Porque esta es la incómoda verdad sobre lo que estamos construyendo. Durante quince años, equipos muy inteligentes y con una financiación extraordinaria han intentado hacer funcionar mundos creativos compartidos. Unos pocos se convirtieron en algunas de las creaciones más grandes que la humanidad haya construido jamás. La mayoría están muertos. La diferencia entre ambos resultados no es el talento ni el dinero, porque algunos de los proyectos muertos tenían más de ambos de lo que nosotros tendremos nunca. La diferencia reside en un pequeño número de decisiones que casi nadie acierta a la primera. Esto es lo que descubrí.

El cementerio

Empecemos por los fracasos, porque son más sinceros que las historias de éxito. Los ganadores reescriben su historia para convertirla en un relato impecable. Los perdedores filtran memorandos.

Meta Horizon Worlds: la habitación vacía más cara jamás construida

Meta gastó decenas de miles de millones en su apuesta por el metaverso. Reality Labs registró una pérdida operativa de 6.020 millones de dólares en un solo trimestre, anunciada a principios de 2026, y llevaba años perdiendo varios miles de millones por trimestre. Su producto estrella era Horizon Worlds. Esto es lo que compró todo ese dinero.

Un memorando interno filtrado, del que informaron Fortune y Ryan Schultz, reveló que solo alrededor del 9 por ciento de los mundos creados llegaron a recibir 50 visitas o más. La inmensa mayoría no recibió ninguna visita aparte de la de su propio creador. Uno de los memorandos resumió el problema de la interacción en una frase que todo fundador de este sector debería llevar tatuada: «un mundo vacío es un mundo triste». Los investigadores que querían encuestar a usuarios activos solo pudieron encontrar a 514, porque la base de jugadores era así de pequeña.

Las cifras de retención eran aún peores. Los datos filtrados mostraban que solo alrededor de 1 de cada 10 usuarios regresaba después de su primer mes. Meta redujo discretamente su propio objetivo para 2022 de 500.000 usuarios mensuales a 200.000, y aun así la plataforma tenía menos usuarios simultáneos que VRChat y menos que Second Life, un juego de 2003. Los paneles internos de uso del producto mostraban que ni siquiera los propios empleados de Meta lo utilizaban, lo que llevó a la dirección a empezar a responsabilizar a los mánagers de que sus equipos iniciaran sesión cada semana. Un vicepresidente puso al equipo en un «confinamiento de calidad» durante el resto del año y admitió por escrito que estaban trabajando en un producto que no había encontrado su encaje en el mercado.

En marzo de 2026, Meta anunció que eliminaría por completo la compatibilidad con la realidad virtual y convertiría Horizon Worlds en una aplicación casi exclusivamente móvil, un punto de entrada para quienes no tuvieran visor que funcionaría, según su propio planteamiento, como Roblox. El metaverso más caro jamás construido terminó su vida intentando convertirse en lo que debería haber sido desde el primer día.

La lección no es que «la realidad virtual llegó demasiado pronto», aunque así fue. La lección es que ninguna cantidad de capital llena un mundo vacío. La densidad de contenido no es algo que pueda comprarse con un presupuesto de marketing. Si los mundos están vacíos, la gente se marcha, y cuando la gente se marcha, los mundos siguen vacíos. Ese círculo vicioso devoró a Meta.

Decentraland y The Sandbox: las ciudades fantasma de mil millones de dólares

En octubre de 2022, un único dato incendió el mundo de las criptomonedas. DappRadar informó de que Decentraland tenía 38 usuarios activos diarios. The Sandbox tenía 522. Cada uno de estos proyectos contaba entonces con una capitalización de mercado de alrededor de 1.300 millones de dólares.

Los proyectos rebatieron esas cifras, y el matiz importa más que la burla. La cifra de 38 solo contabilizaba las carteras únicas que realizaban transacciones en la cadena de bloques durante un día —lo que DappRadar denomina «pagadores»—, no a las personas que iniciaban sesión y recorrían el mundo sin interactuar con la cadena de bloques. Decentraland respondió que tenía 56.697 usuarios mensuales con sesión iniciada y, según otras estimaciones, unos 8.000 al día. The Sandbox afirmó tener 39.000 usuarios diarios durante una temporada alfa, con una retención del 40 por ciento en el día 14.

Pero detengámonos un momento en esa diferencia, porque es la cifra más importante de todo este ensayo. Incluso tomando las cifras más favorables, tenemos valoraciones de miles de millones de dólares sustentadas, en el mejor de los casos, por unos pocos miles de usuarios diarios. A modo de comparación, la investigación reveló que Roblox, sin cadena de bloques, tenía 52 millones de usuarios activos diarios, pero solo 11,3 millones de usuarios de pago mensuales durante el mismo periodo. La mayoría de las personas que habitan mundos virtuales gratuitos realizan transacciones rara vez o nunca. Esto funciona en ambos sentidos. Significa que la burla sobre los 38 usuarios activos diarios era injusta y que la valoración de mil millones de dólares era una fantasía. Ambas cosas medían la cifra equivocada. La valoración medía la especulación con los tokens. La burla medía las transacciones de las carteras. Ninguna medía si alguien se estaba divirtiendo.

Esa es la trampa de las métricas de vanidad en su forma más pura. Cuentas registradas, capitalización de mercado del token, mercado total disponible, repercusión en prensa: ninguna de ellas indica si tu mundo está vivo. Las únicas cifras que sí lo hacen son cuántas personas regresan y si quienes crean cosas siguen creándolas.

Dreams: la herramienta más hermosa en la que nadie podía quedarse

Media Molecule, el estudio responsable de LittleBigPlanet, dedicó casi una década a crear Dreams, una herramienta de creación tan completa que la gente hizo en ella juegos jugables, cortometrajes de animación y álbumes de música. La crítica la adoraba. Y en septiembre de 2023, el estudio puso fin al servicio en vivo, afirmando sin rodeos que no había podido encontrar un modelo de negocio sostenible.

El análisis posterior es una lista de errores autoinfligidos, y lo digo con enorme respeto, porque nosotros podríamos cometer cada uno de ellos. Dreams nunca permitió a los creadores monetizar su trabajo. La tienda interna prometida nunca llegó a publicarse. No había artículos cosméticos, ni pase de batalla, ni nada. Los creadores serios, los que convierten una herramienta en una plataforma, no tenían motivos para invertir años cuando no había ninguna recompensa posible. Se lanzó solo para PS4, sin versión para PC ni versión nativa para PS5 en el lanzamiento, lo que limitó drásticamente su audiencia potencial. Y el cofundador Mark Healey dijo más tarde que lo que más lamentaba era no haberse centrado en el multijugador, y que el equipo llegó a comprender que su creación funcionaba mejor como juego que como herramienta creativa.

Lee de nuevo esa última parte. El estudio de contenido generado por usuarios con más talento del mundo concluyó, a posteriori, que aquello debería haber sido primero un juego y después una herramienta. Esa es la frase más importante de todo este estudio, y volveremos a ella.

El resto del cementerio

El patrón se repite con una consistencia desoladora.

Crayta, una plataforma colaborativa para crear contenido generado por usuarios, cerró en marzo de 2023 y los usuarios perdieron todo lo que habían creado. Meta adquirió a su desarrollador en 2021 y, aun así, la plataforma acabó cerrando. La causa inmediata: se lanzó en Google Stadia y, cuando Stadia murió, Crayta murió con ella. Depender de una plataforma es como apuntarte a la cabeza con un arma cargada.

Project Spark, el creador de juegos con contenido generado por usuarios de Microsoft, cerró años antes siguiendo la misma trayectoria: una herramienta potente, pero sin suficientes personas que se quedaran. Sansar, el sucesor en realidad virtual de Second Life creado por Linden Lab, fue vendido tras no conseguir atraer a una audiencia. High Fidelity, la segunda empresa de metaversos de Philip Rosedale, el propio fundador de Second Life, abandonó por completo los mundos virtuales para dedicarse a otra cosa.

Y hay una señal que no puedes ignorar porque está ocurriendo ahora mismo: Rec Room anunció que cerrará con efecto a partir del 1 de junio de 2026, afirmando que nunca logró una rentabilidad sostenida.

Los fundadores de empresas de metaversos, dedicados a construir metaversos, no podían permanecer en sus propios metaversos. Eso debería aterrorizar a cualquiera que crea que la parte difícil es el renderizado.

Los supervivientes y lo que realmente los salvó

Ahora, los que siguen vivos. Lo instructivo es que ninguno triunfó como cabría esperar, y varios lo hicieron pese a romper las reglas que siguieron los fracasados.

Roblox: el éxito de la noche a la mañana que tardó doce años

Todo el mundo cita Roblox como modelo. Casi nadie copia lo que ocurrió de verdad, porque lo que ocurrió de verdad fueron doce años pareciendo un fracaso.

La beta de Roblox de 2006 atrajo a unos 100 entusiastas de la tecnología, con un pico de entre 30 y 40 usuarios simultáneos. Después avanzó trabajosamente durante más de una década. Pasó de 9 millones de usuarios a principios de 2016 a 90 millones en 2019 y 214 millones en 2023. Su fundador, David Baszucki, se negó a abandonar la visión del contenido generado por usuarios incluso cuando Minecraft lo adelantó de forma espectacular en 2009. Lo consideraba una apuesta deliberada a fuego lento, y la decisión que marcó la diferencia fue permitir que la comunidad creara todos los juegos en lugar de desarrollarlos internamente. Eso eliminó el coste del contenido y convirtió a cada creador en un motor de crecimiento.

Pero aquí está la parte que se les escapa a quienes lo imitan superficialmente, y por eso mantengo abierta una segunda fuente. El análisis de 2024 de Matthew Ball muestra que Roblox opera con pérdidas brutales incluso a gran escala: un margen operativo aproximado del 38 % negativo, con solo un 6 % de los usuarios comprando su moneda en un mes determinado y unos ingresos por usuario muy inferiores a los de las plataformas de consola. Roblox es el juego más grande del mundo y aun así le cuesta ganar dinero. El círculo virtuoso es real y la economía es difícil. Quien te diga que una plataforma para creadores es una máquina de imprimir dinero intenta venderte algo.

Sin embargo, la lección más profunda está a plena vista en esas cifras de usuarios. La inmensa mayoría de los cientos de millones de usuarios de Roblox nunca crea nada. Entran para jugar a un catálogo de decenas de millones de juegos creados por otras personas. Ese catálogo tardó una década en crecer y necesitó una economía de pagos a desarrolladores. Roblox no es una herramienta de creación a la que la gente juega por casualidad. Es un lugar donde jugar en el que una pequeña fracción de los usuarios también crea. Ese orden lo es todo.

Minecraft: el mundo que no podía estar vacío

Minecraft nunca tuvo el problema del mundo vacío, y entender por qué es la clave de todo.

Minecraft se lanzó como un juego de supervivencia con generación procedimental. El mundo se construye solo, de forma infinita, y desde el primer minuto no estás mirando un lienzo en blanco sin saber qué hacer. Está anocheciendo y algo va a matarte, así que cavas. El juego es divertido para una sola persona, sin otros usuarios ni contenido generado por usuarios, para siempre, porque el generador procedimental es una máquina inagotable de contenido. Los mods, los servidores, los mapas personalizados, todo el ecosistema creativo: todo eso creció sobre un juego que ya se vendía por sí solo. El modo creativo llegó cuando millones de personas ya estaban enganchadas a la supervivencia. El boca a boca y YouTube hicieron el resto.

Minecraft resolvió el arranque en frío evitando tenerlo. Ese es el truco, y vamos a apropiárnoslo.

Juegos de navegador: la distribución como única ventaja competitiva

Luego está el género más cercano a nuestro mecanismo real de distribución: el juego de navegador sin descargas.

Agar.io alcanzó aproximadamente 5 millones de jugadores diarios en cuestión de semanas tras su lanzamiento en 2015. Slither.io acumuló 68 millones de descargas móviles y 67 millones de partidas en el navegador. La investigación es tajante sobre el motivo: «la ventaja competitiva del género .io es la propia distribución, no la mecánica de juego». Haces clic en un enlace y ya estás jugando. Sin instalación, sin cuenta, sin tienda de aplicaciones. La incorporación de Agar.io requería un solo clic: escribe un nombre, pulsa jugar y ya estás dentro. Se propagó por las aplicaciones de chat como se propagan los vídeos en TikTok.

Pero este regalo esconde un filo que también nos afecta. Sin descarga no hay compromiso. La misma ausencia de fricción que facilita la entrada también facilita la salida, porque cerrar una pestaña no cuesta nada. La viralidad en el navegador es real, pero también es superficial por defecto. Los juegos .io sobrevivieron gracias a que eran divertidos de forma inmediata y evidente durante los primeros diez segundos. Los mundos de navegador que murieron eran fáciles de abrir, pero no te daban ningún motivo para quedarte una vez dentro.

Among Us, Figma, Townscaper, VRChat: cuatro formas más de triunfar

Cuatro ejemplos rápidos, porque cada uno aísla una palanca distinta.

Among Us salió en 2018 y durante dos años no tuvo ningún éxito comercial. Sus desarrolladores estuvieron a punto de abandonarlo. Entonces, en septiembre de 2020, lo descubrió una cadena de streamers cada vez más grandes, que culminó en una retransmisión de varias horas de Sodapoppin, y se convirtió en un fenómeno mundial. El impulso inicial llegó de una aparición en la portada de itch.io y de un público coreano que llegó a representar la mitad de sus ventas. Lección: el gran salto puede llegar años después del lanzamiento, desde un canal que no habías previsto, si sobrevives el tiempo suficiente para que te descubran.

Figma permaneció en modo secreto durante unos tres años, se lanzó gratis y esperó otros dos años antes de empezar a cobrar. Su momento de activación era el modo multijugador: el instante en que un diseñador veía a otra persona editando el mismo archivo. Y esta es la parte importante. Al principio, el plan gratuito de Figma te limitaba a 2 colaboradores, lo que estrangulaba precisamente el momento mágico que vendía el producto, y lo solucionaron permitiendo colaboradores ilimitados para que la gente pudiera experimentar aquello de verdad. Sembraron la comunidad contactando directamente con referentes del diseño en Twitter. Lección: encuentra tu momento revelador y elimina todos los obstáculos entre un usuario nuevo y ese momento.

Townscaper era un pequeño juguete creativo que se convirtió en un éxito gracias a sus capturas de pantalla. Su desarrollador vio cómo sus seguidores en Twitter pasaban de unos 20 000 a 90 000 con solo publicar clips durante el desarrollo, y lo interpretó como una señal temprana de que tendría éxito. Lección: si tu creación es hermosa y la gente la comparte por iniciativa propia antes incluso de que la hayas lanzado, esa es la validación más auténtica que existe.

Y VRChat, durante los mismos meses en que se vinieron abajo tanto los miles de millones de Meta como Rec Room, alcanzó un récord de casi 160 000 usuarios simultáneos. Está impulsado por la comunidad y por los creadores, y ni de lejos cuenta con tanta financiación como los proyectos que murieron a su alrededor. VRChat atribuye su supervivencia a la lealtad y la creatividad de la comunidad por encima del capital. Lección, en palabras del propio superviviente: la pasión de unos creadores comprometidos dura más que el dinero.

Lo que realmente separa a los vivos de los muertos

Pon las historias una al lado de otra y el patrón resulta evidente.

Lo que mata a los mundos creativos es la sala vacía. Horizon Worlds, Decentraland, Dreams, Crayta, Project Spark y Sansar murieron todos de la misma forma: no había suficiente gente, ni suficiente contenido, ni motivos suficientes para volver, dentro de un bucle que se retroalimenta. El problema del arranque en frío es el jefe final. Todo lo demás es un nivel de tutorial.

Lo que los salva es tener un motivo para existir antes de que llegue la multitud. Minecraft tenía la supervivencia procedimental. Roblox tenía una década de juegos cultivados con paciencia. Los juegos .io ofrecían diversión en diez segundos. Cada superviviente merecía tu tiempo incluso con un catálogo vacío. Cada víctima era un contenedor precioso que esperaba a que otras personas hicieran que mereciera la pena visitarlo. Esta es la confesión de Dreams convertida en principio general: crea primero un juego y después una plataforma. La plataforma es el segundo acto. Te la ganas siendo primero algo que la gente usa por su propio valor. Las métricas que realmente predicen la supervivencia no son las que aparecen en el comunicado de prensa. La investigación es consistente al respecto. La señal definitiva del encaje entre producto y mercado es que tu curva de retención se estabiliza: alguna cohorte de personas sigue regresando indefinidamente. Una curva que cae hasta cero significa que no hay encaje, por muy grande que sea la parte superior del embudo. Como referencias aproximadas del sector, se habla de una retención del 40 por ciento el día 1, el 20 por ciento el día 7 y el 10 por ciento el día 30, y el día 30 es el que predice la salud a largo plazo. Y en cualquier producto con una vertiente para creadores, es en el lado de la oferta donde mueres: alrededor del 67 por ciento de los marketplaces fallidos se hunden por la oferta, no por la demanda. La retención de creadores es la constante vital. Las cuentas registradas y las valoraciones son vanidad.

Hay algunas conclusiones más que se desprenden de estas historias. Monetiza a tus creadores o los perderás, porque Dreams demostró que la gente con talento no invertirá años sin nada que ganar. El multijugador suele ser el objetivo, no una funcionalidad, según el propio arrepentimiento de Media Molecule. Nunca construyas tu casa sobre una plataforma que pueda desahuciarte, como enseñó Crayta. Y no requerir descargas es un arma de doble filo: es el mejor canal de adquisición que existe y el mecanismo de compromiso más débil, así que toda la responsabilidad recae en que los primeros sesenta segundos sean buenos.

La trampa que subyace a todo esto

Hay una capa más, específica de nuestro momento, porque tenemos una herramienta que los desaparecidos nunca tuvieron. Podemos generar mundos con IA. Y eso plantea una paradoja sobre la que llevo semanas cambiando de opinión.

Si es IA, ¿no debería ser cada mundo único, generado de cero para cada persona y adaptado a ella? Pero si el mundo de cada persona es único, ¿cómo va a encontrarse alguien con los demás, si un momento compartido requiere un lugar compartido? Y si, de todos modos, el mundo tiene que ser compartido, ¿para qué usar IA en vez de crear artesanalmente un lugar precioso como lo haría un estudio de verdad?

Cada uno de esos impulsos, llevado hasta sus últimas consecuencias, desemboca en algo que no funciona. Un mundo generado solo para ti es un mundo sin nadie dentro. Genie de Google puede crear un entorno jugable a partir de una frase, pero desaparece un minuto después: un solo jugador, sin memoria, sin vecinos. Ese es el callejón sin salida de la soledad. Pero crear artesanalmente un único mundo fijo también es un callejón sin salida: llenar a mano dos kilómetros cuadrados requiere cien personas y varios años y, cuando terminas, queda congelado, idéntico en tu centésima visita que en la primera e incapaz de crecer a medida que llega la gente.

La salida consiste en dejar de tratar «el mundo» como si fuera una sola cosa. Tiene tres capas, y lo único y lo compartido pueden habitar en capas distintas sin entrar en conflicto. El terreno sobre el que todos se encuentran es un único mundo compartido, seleccionado con un alto nivel de exigencia: el lugar de encuentro. Lo que llevas hasta él —tus recursos generados con IA, el edificio que creaste— es totalmente único, y lo depositas dentro del mundo compartido para que tu singularidad se convierta en el descubrimiento de los demás. Y tu recorrido por él —las misiones que recibes, aquello hacia lo que te orienta— se personaliza sin coste, porque una ruta no es un lugar. La falsa elección era entre «un mundo personalizado», que acaba con el multijugador, y «una ruta personalizada a través de un mundo compartido», que lo enriquece. Queremos lo segundo.

Así que el trabajo de la IA nunca fue entregar a cada persona un mundo privado. Su trabajo consiste en hacer que un único mundo compartido parezca infinito, vivo y personal al recorrerlo. Su singularidad nace de todo lo que se acumula en él con el tiempo, de la contribución irrepetible de cada creador. Cada servidor de Minecraft es único. Todos los usuarios de un servidor determinado lo comparten. Eso no es una contradicción. Ese es todo el truco, y la captura de pantalla que aparece al principio de esta publicación —la IA construyendo una casa que permanece en un mundo al que otras personas pueden entrar— es la materialización de ese truco.

Cómo vamos a lanzar Cinevva World

Así es como todo esto se traduce para nosotros. No es un plan de marketing. Son cinco apuestas, planteadas deliberadamente contra las cinco cosas que acabaron con todos los proyectos de la primera mitad de este artículo. Y evaluaré cada una según el respaldo real de las pruebas, porque un plan que no puedes evaluar no es más que un deseo con buena iluminación.

Primera apuesta, aquella por la que me jugaría la empresa: lanzamos un juego, no una plataforma. Esto no es una preferencia, sino la conclusión más consistente de todo el estudio. Minecraft, Roblox y Fortnite empezaron ofreciendo algo divertido que hacer y desarrollaron encima la capa de creación. Media Molecule, el estudio de creación con más talento que existe, concluyó a posteriori que Dreams debería haber sido primero un juego. Por tanto, lo primero que hará una persona nueva en Cinevva World no será contemplar una parcela vacía. Será participar en un ciclo de juego con un objetivo, una razón para estar allí un martes cuando casi no haya nadie más conectado. La mayoría de quienes lleguen jugarán y nunca construirán, y eso forma parte del diseño, no es un fracaso. Es la forma real de Roblox: cientos de millones de personas que juegan, asentadas sobre una fina capa de personas que crean. El volante de crecimiento es el segundo acto, y tenemos que ganárnoslo. Estoy seguro de esta apuesta porque el cementerio ya realizó el experimento.

Segunda apuesta, la que sinceramente sí es una jugada arriesgada: la IA nos permite producir la oferta que todos los demás murieron esperando. Quiero ser preciso sobre por qué esto es una apuesta y no una garantía, porque ninguna plataforma de este estudio arrancó jamás con IA generativa. Tengo un mecanismo, no una prueba. El mecanismo es este: aproximadamente dos tercios de las plataformas de dos caras mueren por el lado de la oferta, no por el de la demanda. La solución clásica consiste en simular la oferta hasta que sea real, como cuando DoorDash entregaba la comida por su cuenta, el equipo de Reddit publicaba con identidades falsas y los fundadores de Roblox crearon a mano los primeros juegos durante años. Nosotros podemos hacerlo mediante generación, con un coste y una velocidad que ninguno de ellos tuvo. Pero esta es la parte que me mantiene con los pies en la tierra, y es la lápida de Decentraland: Decentraland estaba lleno de contenido generado y atraía a unas treinta personas al día, porque bonito no significa que merezca tu tiempo. Así que no apuesto a que la IA haga divertido el mundo. No puede. Apuesto a que la IA elimine el cuello de botella de los recursos para que cada hora de nuestro escaso esfuerzo humano se dedique a lo único que realmente retiene a las personas: el ciclo de juego. La IA construye la colina a bajo coste. Nosotros construimos a mano la razón para subirla. Y limitaremos la oferta sintética inicial a aproximadamente un 30 por ciento, convirtiéndola en contenido de creadores reales en unos 60 días, porque una oferta falsa que nunca se vuelve real destruye la confianza en cuanto alguien se da cuenta.

Tercera apuesta: publicamos nuestros propios criterios de cancelación. Esta es la diferencia entre un plan con los pies en la tierra y uno basado en la esperanza. La métrica que predijo la supervivencia en todos y cada uno de los casos fue si la curva de retención se estabiliza, si alguna cohorte sigue regresando en lugar de decaer hasta cero. Así que esa es la prueba a la que nos someteremos, públicamente. Si la retención del día 7 de la alfa no se estabiliza, si los jugadores que nunca construyen no regresan, si la gente pasa de largo ante el contenido inicial generado por IA y lo ignora, la tesis es errónea, y la cambiaremos o nos detendremos. Seguiremos a jugadores y creadores como dos embudos separados, con dos momentos de revelación distintos, porque los datos dejan claro que no son la misma persona. Y no fingiremos que el dinero hace el trabajo inicial. Con cincuenta usuarios, o incluso con mil, las propinas y los ingresos del marketplace se redondean a cero, así que todavía no retienen a nadie. La retención inicial procede del ciclo de juego o no se produce en absoluto. Dreams es la prueba de lo que ocurre al plantearlo al revés.

Cuarta apuesta: empezamos deliberadamente con un enfoque limitado. La investigación sobre productos conectados es unánime. No lanzas para un mercado, sino para una «red atómica», el grupo más pequeño con densidad suficiente para tener vida propia. Facebook comenzó en una sola universidad. La nuestra ya existe: los creadores de Cinevva que han generado recursos 3D, música y sonido, y que ya tienen un inventario que colocar. Cincuenta de ellos en un mismo mundo, a la misma hora, con un objetivo y una frontera, crean algo más denso y vivo de lo que jamás serán cincuenta mil registros dispersos. Las pruebas respaldan firmemente esta apuesta.

Quinta apuesta, la menos sólida, y lo admito: decimos la verdad sobre el vacío en lugar de ocultarlo. Un mundo pulido y silencioso parece muerto, y todos los proyectos fallidos intentaron disimularlo con efectos ambientales. Nosotros probaremos lo contrario. Esta es la decisión menos demostrada de las cinco, más cercana a una corazonada que a una conclusión. Las primeras personas que entren no estarán visitando un producto inacabado. Serán los ciudadanos fundadores de un lugar que está vacío porque han llegado pronto, y lo que construyan seguirá en pie cuando lleguen los siguientes mil.

Ese es el plan, evaluado con honestidad. Cuatro apuestas que el cementerio respalda con firmeza y una apuesta realmente arriesgada por una herramienta que ninguno de los desaparecidos tuvo, acotada por la disciplina exacta de la que carecieron. Podemos generar la colina. No podemos generar la sensación de ser los primeros en subirla, ni al desconocido que saluda desde la cima. Nuestro trabajo consiste en hacer posible ese saludo, demostrarlo en la curva de retención y dejar de engañarnos en cuanto la curva diga que no.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 29 nos dio un único controlador capaz de manejar cualquier cuerpo. Ahora el cuerpo se mueve correctamente. Camina, se desliza, nada, planea, trepa por cuevas y se agacha bajo salientes. El problema es lo que lo observa. Durante veintinueve partes, la cámara fue un sistema orbital estándar que seguía al jugador y hacía exactamente una cosa ingeniosa para evitar situaciones embarazosas: se negaba a inclinarse por debajo del horizonte para no deslizarse bajo un suelo plano. Esa limitación lo delata todo. Existe porque la cámara no tenía ni idea de dónde estaba realmente la geometría del mundo, así que la única defensa contra el atravesamiento era prohibir los ángulos en los que resultaba más probable. Al acercarte a una colina, la cámara se metía dentro de ella. Al entrar en una de las cuevas de marching cubes de la parte 7, acababas mirando el interior de una roca. Si construías una casa con las herramientas de creación de la parte 16 y te quedabas de pie en una habitación, la cámara flotaba fuera de la pared mirando el revestimiento exterior. Esta parte consigue que la cámara respete la geometría tanto como ya lo hace el cuerpo.

La forma del problema y la forma de la solución

Una cámara en tercera persona tiene una tarea difícil y una docena de tareas fáciles. Las fáciles son seguir al personaje, suavizar el movimiento y gestionar los controles orbitales, y eso ya lo teníamos. La difícil es lo que la literatura académica denomina una restricción de visibilidad, y el estudio que todo el mundo cita, Camera Control in Computer Graphics, de Christie y Olivier, plantea todo el campo en torno a ella: mantener al sujeto encuadrado y sin oclusiones mientras se respeta el mundo. En tiempo de ejecución, esto se reduce a una pregunta engañosamente sencilla que se plantea en cada fotograma. El jugador es el pivote. El usuario ha rotado y ajustado el zoom hasta una posición deseada de la cámara, situada a cierta distancia detrás de él. ¿Hasta dónde puede colocarse realmente la cámara a lo largo de esa línea antes de introducirse en algo sólido? Si respondes con precisión, la cámara se recoge delante de la colina, se desliza por el brazo al retroceder hacia una esquina y se detiene ante el techo de la cueva en lugar de atravesarlo.

El patrón que resuelve esto es antiguo y está más que probado. Unreal lo llama spring arm, Godot incluye un nodo SpringArm3D y Cinemachine de Unity lo divide entre un sistema de seguimiento en tercera persona y una extensión para evitar oclusiones. La idea siempre es la misma. La cámara cuelga del extremo de un brazo anclado al pivote. Se mantiene a la longitud deseada cuando el trayecto está despejado, se retrae hacia el pivote cuando hay algo en medio y vuelve a extenderse con un efecto de resorte cuando el camino queda libre. Real-Time Cameras, de Mark Haigh-Hutchinson, responsable de cámaras de Metroid Prime, dedica capítulos enteros a los modos de fallo que convierten una implementación ingenua en algo capaz de marear a los jugadores. Tomamos ese patrón y construimos el nuestro, lo bastante pequeño como para leerlo de una sentada, en public/world/src/camera-rig.mjs.

Un brazo que solo controla su longitud

La regla de diseño que mantuvo pequeño el sistema procede del trabajo sobre el controlador de la parte 29: controlar una sola cosa por completo y rechazar todo lo demás. El sistema controla la longitud del brazo y nada más. El ángulo horizontal, la inclinación, el amortiguamiento de la órbita y los gestos táctiles y con la rueda del ratón permanecen en OrbitControls, que ya los resuelve bien y que no tenemos ningún interés en reescribir. Por tanto, este sistema no es un controlador de cámara. Es un posprocesado que se ejecuta después de los cálculos orbitales y corrige exactamente un número: la distancia entre el pivote y la cámara.

Esa decisión parece impecable, pero estuvo a punto de fallar de inmediato debido a cómo piensa OrbitControls. Al principio de cada actualización, lee la posición actual de la cámara y deriva de ella el radio de la órbita. Normalmente eso resulta invisible. Pero en cuanto nuestro sistema acorta la distancia de la cámara para esquivar una pared, en el siguiente fotograma OrbitControls lee esa posición acortada, concluye que el usuario debe haber acercado el zoom e incorpora ese acortamiento al zoom deseado por el usuario. Después de unos cuantos fotogramas, la cámara se ha desplomado sobre la cabeza del jugador y ya no vuelve a alejarse. La solución consiste en dos llamadas que enmarcan la actualización de los controles orbitales y constituyen toda la integración. Antes de que se ejecute OrbitControls, beforeControls() restaura la cámara a la distancia completa y sin acortar del fotograma anterior, para que los cálculos orbitales siempre lean el zoom real del usuario. Después de que se ejecute OrbitControls, afterControls(dt) lee esa posición deseada recién orbitada, resuelve la colisión, amortigua la longitud y coloca la cámara donde realmente debe renderizarse. La intención del usuario y la corrección de colisiones nunca interfieren entre sí, y el desplazamiento del zoom conserva exactamente la misma capacidad de respuesta que tenía antes de que existiera el sistema. La prueba sin interfaz gráfica que escribimos para el sistema verifica precisamente esto: empuja el brazo contra una pared durante sesenta fotogramas, despeja la pared y comprueba que la longitud vuelve con efecto de resorte al zoom completo de diez metros del usuario, en lugar de quedarse atascada en la distancia de colisión.

Un contrato, cualquier colisionador

El sistema nunca pregunta de qué está hecho el mundo. Un colisionador es simplemente un objeto con un método probe: el sistema le entrega un rayo, una distancia máxima y el radio de sondeo de la cámara, y recibe un número, la distancia máxima que puede recorrer la cámara antes de que ese colisionador la bloquee. El sistema consulta todos los colisionadores registrados y se queda con el impacto más cercano. Ese es todo el contrato, y es el mismo enfoque que utilizó el controlador del personaje al convertir la locomoción en comportamientos intercambiables. El terreno se conecta, los objetos se conectan y las estructuras de los edificios se conectan, cada uno detrás del mismo probe, mientras que el sistema permanece ajeno a todos ellos. Añadir un nuevo tipo de obstáculo significa añadir un colisionador a una lista, no editar la cámara.

Hay un detalle del contrato que demuestra su valor: el radio de sondeo. No lanzamos un rayo fino desde el pivote hasta la cámara, sino una esfera lo bastante grande como para contener el plano cercano de la cámara. Un único rayo detiene el centro de la cámara en la pared, pero el plano cercano tiene anchura, por lo que sus esquinas ya estarían hundidas en la pared antes de que el rayo central informara de un impacto. Barrer una esfera pequeña en lugar de un rayo es lo que hacen todas las implementaciones publicadas; Unreal lo expone como el tamaño de la sonda, y eso marca la diferencia entre una cámara que descansa limpiamente contra una superficie y otra que permite ver a través de ella en los bordes de la pantalla.

No estimamos ese radio, sino que lo derivamos. El punto del plano cercano más alejado de la cámara es una de sus esquinas, y la distancia hasta él se obtiene directamente de la proyección. Con un plano cercano $n$ y un campo de visión vertical $\theta$, la semialtura es $h=n\tan (\theta /2)$, la semianchura es $w=h\cdot \text{aspect}$, y la esquina se encuentra a

El radio de sondeo es esa distancia a la esquina multiplicada por un pequeño margen de seguridad, con un mínimo fijo para que nunca caiga por debajo de un valor razonable en un frustum muy estrecho. Cada vez que cambian el campo de visión, la relación de aspecto o el plano cercano, el radio se vuelve a calcular, de modo que un cambio de tamaño de la ventana o un zoom que afecte a la proyección no pueda dejar discretamente la sonda demasiado pequeña para cubrir las esquinas que debe proteger.

El colisionador que sabe de cuevas

Aquí es donde el colisionador del terreno se vuelve interesante, porque el terreno de nuestro motor no es un mapa de alturas. Desde la parte 7 es un campo de distancia con signo, una función que indica a qué distancia está cualquier punto del espacio de la superficie sólida más cercana y si se encuentra dentro o fuera de la roca. Un valor positivo es aire; uno negativo, roca. Ese único hecho es la razón por la que nuestra cámara puede hacer algo que una cámara basada en mapas de alturas no puede hacer por su propia estructura. Un mapa de alturas conoce la altura del suelo en unas coordenadas x y z. No tiene concepto de techo, porque solo puede haber una superficie sobre cada punto. Por eso, una cámara basada en mapas de alturas puede impedir que entres en una colina, pero no tiene ni idea de que el borde de un saliente o el techo de una cueva cuelgan sobre el pivote, y atraviesa ambos sin más. Un campo de distancia conoce todas las superficies en tres dimensiones, así que la misma sonda que detiene la cámara contra una ladera también la detiene contra el techo de una cueva sin un solo caso especial.

Desplazar la sonda por el campo es una técnica con nombre propio y un artículo científico que la respalda. Sphere Tracing, de John Hart, publicado en 1996, es el método estándar para hacer avanzar un rayo por un campo de distancia. El truco consiste en que el campo no solo indica si has golpeado algo, sino también una distancia segura que puedes avanzar sin chocar con nada. Así que, en lugar de avanzar poco a poco con pasos fijos diminutos, se muestrea el campo, se avanza según el margen que indica y se repite el proceso, dando grandes pasos por el aire libre y pasos cortos y cuidadosos al acercarse a una superficie. Sin embargo, hay una salvedad que nos impone el terreno. Un campo de distancias verdadero indica la distancia euclídea real hasta la superficie más cercana, y avanzar de una vez todo ese margen siempre es seguro. Pero donde el terreno sigue siendo un mapa de alturas en lugar de vóxeles esculpidos, el campo que podemos muestrear de forma económica no representa una distancia real, sino la separación vertical, el hueco en línea recta hacia abajo hasta el suelo. En una pendiente, ese valor exagera cuánto puede moverse realmente la cámara, porque la roca más cercana está a un lado, no justo debajo. La distancia real es menor por un factor que crece con el gradiente, $\sqrt{1+\Vert \mathrm{\nabla }h{\Vert }^2}$, así que un paso dimensionado según el margen indicado se pasa de largo y puede saltar limpiamente por encima de una cresta. La solución es la subrelajación: avanzar solo una fracción del margen indicado en lugar de recorrerlo por completo. Esto sigue siendo seguro hasta pendientes de unos sesenta grados y, en las regiones de vóxeles con distancia verdadera, no cuesta nada salvo unas pocas muestras adicionales. Lo combinamos con un límite inferior para el paso, de modo que nunca se salte por completo una pared de cueva de una o dos celdas de grosor, y con un límite superior más estricto que mantiene barata la marcha. Cuando la esfera finalmente toca la superficie, una breve bisección afina el punto de contacto, y la cámara retrocede una distancia igual a su propio radio y se queda allí.

Expresado formalmente, el brazo es un rayo $\mathbf{r}(t)=\mathbf{p}+t\mathbf{d}$ que parte del pivote $\mathbf{p}$ en la dirección unitaria $\mathbf{d}$, y la marcha avanza una fracción subrelajada del margen hasta el contacto que indica el campo, limitada por ambos extremos:

Aquí, $\mathrm{\Phi }$ es la distancia con signo, positiva en el aire y negativa en la roca; $r$ es el radio de la sonda; $\lambda \in (0,1]$ es el factor de subrelajación que evita que el campo del mapa de alturas, al exagerar la distancia, salte una pendiente; y $s_{min},s_{max}$ son los límites del paso que evitan tanto saltarse una pared delgada como alargar demasiado la marcha. El contacto es el primer $t$ para el que $\mathrm{\Phi }(\mathbf{r}(t))\le r$, lo que significa que la superficie de la esfera ha alcanzado la roca, y la cámara se mantiene a esa longitud de arco menos su radio.

El colisionador incorpora un método adicional como red de seguridad: la despenetración. En principio, la colisión debería impedir que la cámara entre en un sólido, pero algunas situaciones se le escapan: un pivote que atraviesa una pared tan fina que el brazo comienza dentro de ella, una cueva recién esculpida con las herramientas de terreno mientras la cámara estaba en la roca que acaba de desaparecer, o una pieza de construcción colocada alrededor de la cámara. En esos casos, el colisionador comprueba si la cámara terminó el fotograma dentro de un sólido, donde $\mathrm{\Phi }(\mathbf{c})<r$; si es así, lee el gradiente del campo, que apunta directamente hacia el aire libre porque $\mathrm{\Phi }$ aumenta al salir de la roca, y desplaza la cámara hacia fuera siguiendo esa dirección:

Unas pocas iteraciones convergen en la isosuperficie de valor $r$, y eso es lo que permite que una herramienta de esculpido excave el suelo bajo la cámara y que la vista se recupere en el siguiente fotograma en lugar de quedarse negra.

Entrar de golpe, salir con suavidad y no sobresaltarse ante los postes de una valla

Un brazo que simplemente salta cada fotograma a la distancia de colisión es peor que no tener brazo, porque el mundo está lleno de objetos delgados tras los que la cámara pasa durante un solo fotograma —un poste de valla, una farola, el tronco de un árbol—, y una cámara que se abalanza para esquivar cada uno y vuelve a abalanzarse en sentido contrario provoca mareo. Tanto el libro de Haigh-Hutchinson como la muy apreciada charla de Itay Keren sobre el movimiento de cámara llegan a la misma intuición: la cámara debe reaccionar ante las amenazas y el peligro más rápido de lo que se relaja cuando desaparecen. Por eso la amortiguación es deliberadamente asimétrica. Cuando aparece un oclusor y el brazo tiene que acortarse, entra casi al instante, porque un fotograma de intersección queda feo y el jugador tolera un repliegue rápido. Cuando el oclusor desaparece y el brazo quiere alargarse, sale lentamente, y solo después de que transcurra un breve temporizador de espera con espacio libre continuo. Esa espera es la histéresis que elimina los sobresaltos. Si giras la cámara rápidamente junto a un poste delgado, el poste nunca permanece despejado el tiempo suficiente como para activar la extensión lenta, así que la cámara se desliza junto a él como si no estuviera ahí, que es exactamente lo que espera la vista. Cinemachine presenta la misma idea mediante valores separados de amortiguación al entrar y al salir de una colisión, y esa asimetría es lo que hace que parezca un operador de cámara en lugar de un muelle.

En código, es una sola línea de suavizado exponencial cuya velocidad cambia según el signo de la variación. Si $\ell$ es la longitud actual del brazo, $a$ la longitud que permite la colisión en este fotograma y $\mathrm{\Delta }t$ la duración del fotograma, entonces

y la rama de salida suave solo se ejecuta cuando el espacio libre se ha mantenido durante el tiempo de espera $\tau$. La forma $1-e^{-k\mathrm{\Delta }t}$ importa por algo más que su aspecto elegante. Fija la constante temporal de respuesta en $1/k$ con independencia de la frecuencia de fotogramas, de modo que la cámara se siente igual a 30 que a 144 fotogramas por segundo, mientras que la mezcla constante ingenua $\ell \leftarrow \ell +\alpha (a-\ell )$ se movería con brusquedad en una máquina rápida y con pesadez en una lenta.

El último comportamiento está pensado para los interiores estrechos que dieron origen a toda esta parte. Cuando el brazo se acorta tanto que la cámara queda justo encima del jugador, ocultamos su propio avatar y dejamos que la vista se sitúe cerca de la primera persona. Es lo que hace Breath of the Wild en un santuario estrecho y el recurso al que recurren la mayoría de los juegos en tercera persona al quedar arrinconados, porque la alternativa —una cámara encajada contra una pared y mirando la nuca de un personaje— no sirve de nada. El rig expone una sola bandera para ello, y el bucle del mundo la consulta y alterna la visibilidad del avatar local. Con menos de un metro de brazo estás, en la práctica, en primera persona, se respetan las paredes y, en cuanto retrocedes hasta una sala con espacio, el avatar reaparece gradualmente y el brazo se extiende.

Lo siguiente que se conecta

El colisionador del terreno se publica hoy y es la mitad difícil, porque el terreno está por todas partes y un campo de distancias es algo incómodo de sondear. Los objetos y las estructuras de edificios procedentes de los prototipos de creación son la mitad fácil, y el contrato ya está preparado para ellos. Un segundo colisionador, uno de trazado de rayos, lanza un rayo desde el pivote hacia la cámara contra una lista de mallas e informa del impacto más cercano del mismo modo que el colisionador del terreno. La versión económica lanza un solo rayo, lo cual basta hasta que aumenta la cantidad de objetos, y la mejora consiste en sustituir el rayo por una esfera barrida mediante three-mesh-bvh, la biblioteca de Garrett Johnson que envuelve una malla en una jerarquía de volúmenes delimitadores para que las consultas espaciales se ejecuten en tiempo logarítmico en lugar de recurrir a la fuerza bruta. En cualquier caso, el rig no cambia. Consulta una lista más larga de colisionadores y toma el impacto más cercano, que es precisamente la razón por la que construimos primero el contrato y después los colisionadores.

Tecnología mencionada en este capítulo

Un brazo que posee un único valor. El rig de cámara es un posprocesado sobre OrbitControls, no su sustituto. Es dueño de la longitud del brazo y deja el giro horizontal, la inclinación, el zoom y la gestión de gestos en manos del controlador orbital en el que ya confiábamos. La integración consta de dos llamadas que enmarcan la actualización: beforeControls() restaura la distancia completa del fotograma anterior para que los cálculos orbitales lean el zoom real del usuario en lugar de confundir el acortamiento causado por una colisión con un acercamiento de cámara, y afterControls(dt) resuelve la colisión y escribe la posición que se renderizará. Sin ese par, la cámara se desploma sobre el jugador en unos pocos fotogramas.

Un contrato de colisionadores conectables. Un colisionador es cualquier objeto con un probe que responde a la pregunta «¿qué distancia puede recorrer la cámara desde el pivote a lo largo de este rayo antes de que la bloquees?». El rig consulta todos los colisionadores y toma el impacto más cercano, sin saber si el obstáculo es terreno, un objeto o una pared, siguiendo la misma disciplina de poseer una sola cosa que el controlador de personaje conectable empleaba para la locomoción. La sonda es una esfera barrida dimensionada para contener el plano cercano, no un rayo fino, de modo que las esquinas del frustum nunca atraviesen una superficie que el rayo central no detectaría. Su radio se deriva de la proyección: la distancia hasta una esquina del plano cercano, $\sqrt{n^2+w^2+h^2}$, multiplicada por un margen de seguridad; además, se vuelve a calcular cada vez que cambian el campo de visión, la relación de aspecto o el plano cercano.

Una sonda de terreno basada en distancias con signo que respeta salientes y cuevas. Como el terreno es un campo de distancias con signo en lugar de un mapa de alturas, la misma sonda que detiene la cámara contra una ladera también la detiene ante el techo de una cueva, un caso que un trazado de rayos sobre un mapa de alturas no puede detectar por su propia estructura. La marcha es un trazado de esferas al estilo de Hart: avanza una fracción subrelajada del margen indicado por el campo y queda limitada por ambos extremos, porque las regiones de mapa de alturas indican separación vertical en lugar de distancia verdadera y exageran cuánto puede moverse la cámara por una pendiente, por lo que un paso completo saltaría una cresta. Una pasada de despenetración guiada por el gradiente actúa como red de seguridad y recupera la vista cuando se esculpe el suelo bajo la cámara.

Amortiguación asimétrica con temporizador de espera. El brazo entra rápidamente cuando aparece un oclusor y sale con suavidad cuando desaparece, y solo después de un breve periodo de espacio libre continuo, por lo que pasar rápidamente junto a un poste de valla nunca hace que la cámara se abalance. Por debajo de un umbral de contracción, el rig activa el estado de casi primera persona y el bucle del mundo oculta el avatar local, la solución habitual para interiores estrechos en lugar de dejar la cámara enterrada en una pared.

Referencias

El planteamiento del control de cámara como una restricción de visibilidad procede de Marc Christie y Patrick Olivier, Control de cámara en gráficos por computadora (Computer Graphics Forum, 2008). La marcha por campos de distancias procede de John C. Hart, Trazado de esferas: un método geométrico para el trazado de rayos con antialiasing de superficies implícitas (The Visual Computer, 1996). El patrón de brazo con muelle y su colisión mediante una esfera de sondeo están documentados en Componente Spring Arm de Epic y en Desoclusor de Cinemachine y Seguimiento en tercera persona de Unity. La intuición sobre el movimiento y la amortiguación procede de Mark Haigh-Hutchinson, Cámaras en tiempo real (Morgan Kaufmann, 2009), y de Itay Keren, Desplazarse hacia atrás: teoría y práctica de las cámaras en juegos de desplazamiento lateral (GDC 2015). La vía de mejora para el colisionador de mallas es three-mesh-bvh, de Garrett Johnson.

Parte 30 de 30. Anterior: Parte 29 - Un controlador, cualquier cuerpo Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

La parte 28 presentó el prototipo 57 y comparó sus cuatro rutas de descarte en un par de párrafos. Esta es la versión larga: por qué elegimos esas cuatro, cuáles eran las otras cuatro y el razonamiento detrás de la que vamos a lanzar.

Hay una colina entre la cámara y un prado. No necesitas renderizar el prado. Todos los motores AAA modernos lo saben. La mayoría de los motores 3D para navegadores no, incluido el nuestro hasta la semana pasada.

Esta publicación es el resultado de investigar el tema como es debido, contrastarlo con nuestra base de código real, crear un prototipo funcional y evaluar las técnicas según cuánto nos ayudan específicamente a nosotros, teniendo en cuenta que hoy publicamos para WebGL y mañana para WebGPU.

Puedes probar el prototipo interactivo de abajo antes de seguir leyendo. T/Y/U/I cambian entre las rutas de descarte, C recorre las cámaras predefinidas y B pinta en rojo y en modo alámbrico los chunks que se ocultan para que puedas ver qué elimina la prueba. El HUD indica cuántas instancias descarta cada etapa.

Abrir el prototipo 57 en una pestaña nueva ↗ · Ver el código fuente

Lo que hace hoy nuestro motor (y lo que no)

Nuestro gestor de chunks en streaming carga alrededor del jugador un anillo de chunks de 64 m con tres niveles de LOD. Cada chunk contiene árboles instanciados distribuidos sobre el mapa de alturas. La lógica de descarte, que reside en Chunk.updateObjectVisibility, es una simple comprobación de distancia: los árboles a menos de 60 m se renderizan con la malla completa, los que están entre 60 m y 140 m se renderizan como billboards y, más allá, no se renderiza nada.

Ese descarte pasa por alto dos enormes categorías de trabajo desperdiciado:

1. Todo lo que está dentro del disco de 60 m pero detrás de la cámara. Volvemos a ordenar el búfer de instancias cada vez que el jugador se mueve más de 4 m, pero no comprobamos el frustum de visión, así que, en promedio, enviamos la mitad del disco a la GPU solo para que se recorte después de la transformación de vértices.
2. Todo lo que está dentro del disco de 60 m pero detrás de una colina. Nuestro terreno tiene 80 m de rango vertical y muchos valles. Cuando la cámara está en un valle, la cresta más cercana oculta geométricamente la mayor parte de la vegetación situada dentro del radio de descarte. Aun así, la dibujamos.

La segunda categoría es el tema central de esta publicación. También es la que los motores AAA resuelven con una serie de técnicas ingeniosas que, a primera vista, no se trasladan fácilmente al navegador.

Gilbert Sanders, de Guerrilla, explica cómo Horizon Zero Dawn renderiza la vegetación de su mundo abierto. La cadena de descarte ocupa los últimos 20 minutos y es una clase magistral sobre por qué «dibujar menos» supera a «dibujar más rápido».

Ocho técnicas evaluadas para nuestro caso

Estudié la cadena moderna de descarte de oclusión y evalué cada componente según cuánto ayuda a un mundo abierto procedural, basado en un mapa de alturas y ejecutado en el navegador. Dos ejes: valor (cuánto trabajo innecesario elimina en nuestra escena) y coste (esfuerzo de ingeniería, además de cuánto nos obliga a cambiar de nuestra arquitectura). El razonamiento completo está en el archivo de investigación que respalda esta publicación; esta es la versión resumida.

1. Descarte por frustum para cada instancia. Valor alto, coste bajo. Ahora mismo no comprobamos en absoluto el frustum para nuestra vegetación instanciada. Añadirlo reduce aproximadamente a la mitad el trabajo en cualquier vista, cuesta unas treinta líneas de código y se puede lanzar hoy en WebGL. Es, con diferencia, la mayor mejora barata, y deberíamos haberla implementado hace meses.

2. Trazado de rayos del horizonte sobre el mapa de alturas. Valor alto, coste bajo-medio. Se hace avanzar un rayo desde la cámara hasta cada instancia candidata, muestreando la altura del terreno a lo largo del trayecto. Si en algún punto el terreno se eleva por encima del rayo, la instancia está ocluida. Funciona precisamente porque nuestro mundo es un mapa de alturas, lo que reduce la visibilidad a un problema 1D a lo largo de la dirección horizontal. La versión densa tiene una complejidad O(pasos) por instancia y por fotograma. La versión acelerada (el siguiente punto) la reduce a O(log pasos).

3. Aceleración mediante una pirámide de alturas máximas. Valor alto, coste medio. Un mipmap 2D del mapa de alturas donde cada texel almacena la altura máxima del terreno dentro de su área. Permite que el trazado de rayos del horizonte avance a grandes saltos cuando el entorno es llano y solo refine sobre las colinas. Esta es la estructura que hace que la técnica 2 sea barata en producción.

4. Oclusión mediante Z jerárquico (Hi-Z / HZB). Valor alto, coste alto. Se crea un mipmap del búfer de profundidad, se proyectan los límites de cada instancia al espacio de pantalla y se comparan con el nivel de mip adecuado. Es el estándar moderno en la GPU, utilizado por Nanite de Unreal, la geometría virtual de Bevy y la adaptación de VTK a WebGPU. Funciona para todo, no solo para el terreno, pero requiere WebGPU, llamadas de dibujo indirectas y un pase de cómputo. Compensa cuando renderizamos millones de briznas de hierba, no miles de árboles.

5. Hi-Z de dos pases (al estilo de Nanite). Mejora marginal respecto a la técnica 4, coste alto. Se vuelve a renderizar la profundidad del fotograma actual después del primer pase para evitar el artefacto de desoclusión de un fotograma. Solo merece la pena cuando hemos avanzado lo suficiente en la ruta controlada por la GPU como para que el coste sea incremental.

6. Rasterizador de oclusión por software (Frostbite/Intel MOC). Valor medio, coste alto. Rasteriza en la CPU un búfer de profundidad de baja resolución para los oclusores grandes. Latencia de lectura nula. Las implementaciones de referencia están escritas en C++ con AVX/SSE; adaptarlas a WASM es un proyecto de verdad, y nuestro trazado de rayos sobre el mapa de alturas consigue la mayoría de las mismas mejoras con una fracción del trabajo.

7. PVS precalculado. Valor bajo, coste alto. Es fantástico para los mapas estáticos de la era de Quake. Nuestro terreno es procedural e infinito, así que cualquier preprocesamiento tendría que hacerse durante el streaming de chunks, lo que cuesta aproximadamente lo mismo que calcular la visibilidad en tiempo de ejecución. Lo descartamos.

8. Descarte del horizonte al estilo de Cesium. Ningún valor para nosotros, coste medio. Está diseñado para elipsoides planetarios. Nuestro mundo es más o menos plano y está acotado; las matemáticas no son aplicables y la técnica no haría nada o produciría falsos descartes. Lo descartamos.

Así que: implementaremos ahora las técnicas 1 y 2+3 en la CPU y con WebGL. Planificaremos la técnica 4 para la migración a WebGPU. Omitiremos el resto.

Por qué gana el trazado de rayos sobre el mapa de alturas para terrenos en el navegador

El consejo habitual en cualquier charla moderna sobre renderizado es «crea un búfer Hi-Z». El análisis detallado de Nanite presentado por Brian Karis en SIGGRAPH 2021 es la referencia canónica y deberías verlo al menos una vez.

Es la respuesta correcta para un motor que ya ejecuta todo mediante llamadas de dibujo indirectas controladas por la GPU. La mayoría de los motores para navegadores, incluido el nuestro, no son ese tipo de motor. Tenemos búferes de instancias en la CPU, llamadas de dibujo de WebGL y ninguna etapa de cómputo. Incorporar Hi-Z a esa arquitectura implicaría migrar simultáneamente a WebGPU, reescribir el pipeline de vegetación para usar llamadas de dibujo indirectas y añadir un pase de creación de la pirámide de profundidad. Eso supone un trimestre de trabajo solo para obtener el primer fotograma que demuestre la idea.

El trazado de rayos sobre el mapa de alturas funciona en la CPU, con WebGL y con los datos que ya tenemos. Aprovecha un hecho sobre nuestro mundo que los motores AAA no pueden aprovechar: nuestros oclusores se describen mediante una función de altura 1D. Muestrear esa función a lo largo de un rayo requiere dos consultas a un array y una multiplicación. Un búfer Hi-Z tendría que descubrir el mismo hecho píxel a píxel.

La técnica se publicó por primera vez como «Horizon Occlusion Culling for Hierarchical Terrains» en IEEE Visualization 2002 (PDF). Se ha mantenido en el repertorio durante dos décadas porque tiene las características adecuadas: es barata cuando el terreno es llano, costosa solo donde hay colinas reales y trivialmente paralelizable.

La pirámide de alturas máximas, ilustrada

El trazado de rayos básico muestrea terrainHeight en unos 24 puntos a lo largo de cada rayo y se detiene en cuanto el terreno lo cruza. Eso funciona bien para miles de árboles. Se viene abajo con cientos de miles de briznas de hierba.

La solución es un mipmap del mapa de alturas en el que cada texel almacena la altura máxima dentro de su área:

nivel 0 (256×256, 2,25 m por texel): altura máx. de 4×4 muestras con desplazamiento aleatorio
nivel 1 (128×128, 4,5 m  por texel): máx.(0,0), máx.(1,0), máx.(0,1), máx.(1,1)
nivel 2 ( 64×64,  9,0 m por texel): la misma reducción un nivel por encima
...
nivel 8 (   1×1,  576 m por texel): máximo global

Cuando el segmento del rayo es largo y llano, se muestrea un nivel grueso: una sola consulta indica «ningún punto del terreno en este cuadrado de 9 m supera nunca los 12 m de altitud y el rayo está allí a 30 m, así que continúa». Solo cuando un texel grueso indica que «el terreno podría estar por encima del rayo» se desciende un nivel para refinar. Toda la estructura ocupa unos pocos cientos de KB y se construye en decenas de milisegundos.

En forma de diagrama:

                                        rayo desde el ojo
       ojo 1,7 m                      o────────────────────────►
              o─────────────────────·─·─·─·─·─·────────────────
              │                      \                         │
              │ nivel 3 (paso enorme) \ nivel 0 (refinamiento)│
              │ «nada supera los 8 m»  \ «¡colina de 9 m!»    │
              │                          \                     │
        ──────┴────────────/▔▔▔\─────────/▔▔▔▔▔\───────────────
                              colina A (8 m) colina B (12 m)
                                               ↑
                                         bloquea aquí

Para el segmento del rayo que pasa cerca de la colina A, la consulta del nivel 3 («la altura máxima en esta caja de 18 m de ancho es de 8 m») ya nos indica que el rayo, a una altitud de 1,7 m más unos metros de ascenso, está despejado. Saltamos 36 m de recorrido con una sola consulta. Sobre la colina B, el nivel 3 indica «el máximo aquí es de 12 m»; descendemos y el nivel 0 indica «sí, hay 12 m en este texel exacto», por lo que descartamos la instancia.

La construcción de la pirámide está en height-pyramid.mjs, y las rutas de descarte que la utilizan están en cull.mjs. Ambos archivos se pueden consultar en el navegador del código fuente del prototipo.

Lo que muestra realmente el prototipo

Abre arriba el prototipo 57 y recorre las cuatro rutas:

• T0 es lo que hace hoy la versión de producción. Solo distancia. Desde C1 (el fondo del valle), el HUD indica unas 12 000 briznas de hierba visibles.
• T1 añade descarte por frustum para cada instancia. El número de elementos visibles se reduce aproximadamente a la mitad porque todo lo que está detrás de la cámara o fuera de los laterales se descarta antes de llegar a la GPU.
• T2 añade el trazado de rayos por fuerza bruta sobre el mapa de alturas. En C1, el número se reduce otro 60-80 %, porque la mayor parte del campo está al otro lado de la cresta más cercana. La columna Cull-ms aumenta porque muestreamos terrainHeight unas 24 veces por instancia.
• T3 sustituye la fuerza bruta por la pirámide de alturas máximas. Cull-ms vuelve a valores cercanos a T1 sin perder la mejora de visibilidad. Esta es la ruta que realmente puedes lanzar.

El patrón coincide con lo observado en los motores de producción. La serie de Acerola en dos partes sobre el renderizado de hierba (¿Cómo renderizan los juegos tanta hierba?, Lo que hice para optimizar la hierba de mi juego) es la explicación más accesible de YouTube sobre por qué conviene invertir el trabajo de ingeniería en la etapa de descarte y no en la de sombreado.

La cámara C3 y el caso problemático de la «cima»

La tercera cámara predefinida del prototipo coloca la cámara en lo alto de una colina, mirando hacia el área de juego. En este caso, el descarte del horizonte apenas hace nada porque no hay terreno entre la cámara y la mayor parte del mundo. El HUD muestra que T2/T3 reducen el número de elementos visibles quizá entre un 5 % y un 10 % respecto a T1.

Eso es una característica, no un error. La técnica deja de funcionar exactamente donde debe hacerlo: cuando no hay nada que ocluya. El descarte por frustum sigue haciendo trabajo útil, el descarte por distancia sigue limitando el presupuesto y la prueba del horizonte pasa de forma natural a no hacer nada. Si implementas esto, debes comprobar que el caso en el que no se hace nada también sea barato; por eso la pirámide de alturas máximas importa incluso cuando no se va a descartar ningún rayo: a menudo, el nivel más grueso basta para confirmar que «nada está bloqueado».

Lo siguiente que vamos a lanzar

Hay tres cosas que hacer, en este orden.

Primero, trasladar T1 y T3 a Chunk.updateObjectVisibility en producción. La pirámide debe residir un nivel más arriba, en el gestor de chunks, porque abarca más de un chunk. El descarte permanece en Chunk para que el procesamiento por lotes existente para cada chunk siga funcionando. Esfuerzo estimado: un día, incluidas las pruebas. Segundo, haremos lo mismo con la hierba una vez que la tengamos. El prototipo actual distribuye 12 000 briznas por un área de juego de 576 m; la densidad de producción debería ser aproximadamente un orden de magnitud mayor. Las rutas de descarte en CPU procesan 12 000 en menos de un milisegundo, y la aceleración mediante la pirámide es lo que permite mantener ese rendimiento con 120 000.

Tercero, cuando migremos a THREE.WebGPURenderer, trasladaremos el mismo bucle a un shader de cómputo. Los metadatos se convierten en un búfer de almacenamiento. El descarte escribe los argumentos de drawIndirect. La pirámide se carga como una textura 2D con la reducción por máximos ya incorporada. La estructura del código permanece prácticamente idéntica, que es precisamente la idea: no estamos apostando la migración a un algoritmo nuevo, sino trasladando un algoritmo que ya tenemos a una pista más rápida.

Guerrilla presentó la versión para GPU de este enfoque en el sistema de colocación procedimental de Horizon Zero Dawn; la canalización de renderizado importa menos que las estructuras de datos, y las suyas tienen la misma forma:

Hi-Z seguirá mereciendo su lugar cuando incorporemos edificios y elementos densos que ocluyan en direcciones que el mapa de alturas no puede describir. Pero la pirámide del mapa de alturas seguirá en la canalización porque es estrictamente más barata que Hi-Z para las instancias pegadas al terreno, y la hierba que cruza la silueta de una cresta es precisamente el caso que Hi-Z peor resuelve.

Referencias

La justificación completa, ordenada por prioridad, y las decisiones arquitectónicas aparecen más arriba; estas son las fuentes canónicas de cada técnica, aproximadamente en el orden en que aparecen en la pila.

• Yalim y Akman, Descarte de oclusión por horizonte para terrenos jerárquicos (IEEE Visualization 2002, el artículo original sobre descarte por horizonte del terreno).
• Turitzin, Búferes de profundidad jerárquicos (la explicación más clara sobre cómo se construyen y consultan las cadenas de niveles mip de Hi-Z).
• VKGuide, Descarte basado en cómputo (referencia de la canalización de descarte controlada por GPU; la adaptación a WebGPU es mecánica).
• Kruskonja, Descarte de oclusión en dos pasadas (la arquitectura al estilo de Nanite explicada fuera de las diapositivas de Epic).
• Karis et al., Nanite: análisis en profundidad (SIGGRAPH 2021) (la referencia moderna de cómo es el descarte controlado por GPU a escala AAA).
• Karis, Ponencia principal de HPG 2022: el camino hacia Nanite (un contexto más amplio sobre por qué importa la etapa de descarte).
• Sanders, Entre la tecnología y el arte: la vegetación de Horizon Zero Dawn (la pila completa de descarte de vegetación AAA).
• Guerrilla, Colocación procedimental en tiempo de ejecución basada en GPU en Horizon Zero Dawn (colocación de instancias y visibilidad por instancia).
• Scthe, Nanite WebGPU (una implementación de referencia en WebGPU, con HZB incluido).
• Kitware, Descarte de oclusión con WebGPU en VTK (el primer HZB de producción ejecutado en el navegador del que tengo constancia).
• Acerola, ¿Cómo renderizan los juegos tanta hierba? y Lo que hice para optimizar la hierba de mi juego (el recorrido accesible en YouTube).
• RasterGrid, Descarte de oclusión basado en mapas Hi-Z (la introducción a Hi-Z que sigue siendo la referencia canónica).
• Intel, Descarte de oclusión por software con máscaras (la familia de rasterizadores para CPU, por si alguna vez decides que la opción n.º 6 merece la pena).

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 28 trató sobre la hierba y la oclusión. Veintiocho partes construyeron un mundo en el que estar: terreno que puedes interpretar, agua en la que puedes nadar, vegetación que se mantiene convincente hasta el horizonte y un servidor que recuerda lo que cambiaste. Esta parte trata sobre aquello que se mueve por todo ese mundo, y es la culminación de todo el motor, porque el objetivo no es crear un controlador para el jugador. Es crear un controlador al que no le importe qué cuerpo controla, de dónde proceden sus animaciones ni si quien está al mando es una persona o una IA. El spike 58 construye el movimiento como una pila de comportamientos conectables sobre un motor de físicas que no sabe nada sobre locomoción y después demuestra la arquitectura ejecutando tres cuerpos diferentes con una instancia del mismo motor. El spike 59 acopla un avatar real con animaciones retargeteadas a ese controlador sin cambiar ni una sola línea. El spike 60 acopla un paquete de animaciones distinto que no necesita ningún retargeting y extrae la lógica de selección de clips para convertirla en algo que realmente se puede probar.

Un motor de físicas que no sabe nada sobre caminar

Abrir el spike 58 en una pestaña nueva ↗ · Ver código fuente

La regla de diseño es estricta, y ese es precisamente el objetivo: el motor de cápsulas no posee ninguna lógica de locomoción. Ni caminar, ni correr, ni saltar, ni fricción, ni límite de velocidad máxima, ni siquiera gravedad. Integra una cápsula cinemática contra el terreno y nada más. Cada comportamiento de locomoción —caminar, deslizarse, planear, escalar, nadar, agacharse o gestionar la resistencia— vive en un controlador autocontenido registrado en el motor. En cada fotograma, el motor actualiza todos los controladores, pregunta a cada uno si quiere tomar el control y permite que el candidato con mayor prioridad escriba la velocidad. Caminar no tiene ningún estatus especial. Es simplemente el controlador de menor prioridad que siempre responde que sí, por lo que actúa como comportamiento predeterminado cuando no se activa ningún otro. Un controlador consta de seis funciones pequeñas: un tick que actualiza su propio estado interno en cada fotograma aunque no esté activo; un predicado puro wantsControl que reclama el fotograma; un applyForces, ejecutado únicamente por el ganador, que escribe la velocidad y aplica su propia gravedad si la necesita; además de los opcionales onEnter, onExit y stateName. El controlador de natación devuelve ownsCollision: true desde applyForces para hacerse cargo de la gestión del terreno, porque, de lo contrario, su resorte de flotabilidad entraría en conflicto con el ajuste de los pies al suelo del motor.

Incluso las cosas que no son locomoción terminan filtrándose a través de ese contrato, y eso fue lo que obligó a introducir la siguiente idea: los canales. Un diseño anterior de un solo canal pasaba todo por un único arbitraje, lo que significaba que un monitor de resistencia o una postura agachada tenían que fingir que eran locomoción y después rechazar el control mediante un truco en el que wantsControl devolvía falso, solo para poder realizar su contabilidad interna. La solución divide los controladores en canales con nombre que arbitran de forma independiente y se aplican en un orden fijo: recursos, después postura y, por último, locomoción. Los recursos se ejecutan primero porque sus escrituras, como la reducción de resistencia, son leídas por los demás. La postura se ejecuta en segundo lugar porque la reducción de altura de la cápsula al agacharse debe aplicarse antes de que el controlador de marcha la lea para limitar la velocidad máxima. La locomoción se ejecuta al final y controla la escritura de velocidad de cada fotograma. Así, un observador de resistencia, un modificador de agachado y un controlador de natación activo pueden coexistir limpiamente, cada uno en su propio canal, sin que ningún controlador tenga que mentir sobre lo que es. La demo visualiza todo esto mediante una cápsula básica que cambia de color según el controlador activo, para que puedas observar cómo se produce el arbitraje: el verde de caminar cambia a naranja en una pendiente pronunciada cuando toma el control el deslizamiento, a cian en el lago cuando gana la natación y a crema en el aire cuando pulsas la tecla de planeo.

Un motor, tres cuerpos

La verdadera prueba de que «no posee ninguna lógica de locomoción» no es el jugador. Es comprobar si el mismo motor, sin modificar, puede controlar algo que ni siquiera sea un jugador. createCapsuleEngine es una fábrica pura sin estado a nivel de módulo, sin singletons y sin efectos secundarios por instancia, por lo que el spike la instancia tres veces. El jugador es una instancia con el conjunto completo de controladores. Un caballo montable es una segunda instancia que solo registra un controlador de marcha, lo que convierte la idea completa en algo literal: el repertorio de movimientos de un cuerpo viene determinado únicamente por los controladores que registraste. Por eso, el caballo es más rápido en terreno llano y físicamente no puede escalar, nadar ni planear, porque esos controladores nunca se añadieron. Un PNJ autónomo es una tercera instancia, actualizada en cada fotograma junto con el jugador y dirigida por un controlador de deambulación que genera sus propias entradas para que el cuerpo se desplace por sí mismo sin manos sobre el teclado. El motor nunca llega a saber que uno de sus cuerpos es un caballo ni que otro está controlado por IA. Todos son el mismo integrador de cápsulas con listas de controladores diferentes.

Montar es la única pieza que vive deliberadamente fuera del motor. Intercambiar el control entre el jugador y el caballo implica coordinar dos motores, y un controlador se ejecuta dentro de un único motor y no puede ver más allá de ese límite. Por tanto, la lógica para montar reside en el nivel del anfitrión: es una pequeña máquina de estados que decide qué motor avanza en este fotograma, congela el otro, desplaza suavemente al jinete hasta la silla mediante un smoothstep de tres cuartos de segundo e indica a la cámara qué cuerpo debe seguir. La fábrica del motor nunca se entera de nada de esto. Esa es la frontera que la arquitectura establece y respeta. Los comportamientos que pertenecen a un cuerpo son controladores; la coordinación entre cuerpos es responsabilidad del anfitrión. Mantener ambos conceptos separados es la razón por la que añadir un cuarto o un cuadragésimo cuerpo no requeriría nada nuevo.

Probado sin navegador

Como el motor no accede a window, document ni Three.js, todo puede ejecutarse sin interfaz gráfica. El spike incluye un arnés de pruebas para Node que simula la interfaz del terreno, hace avanzar el motor fotograma a fotograma con entradas programadas y comprueba el estado resultante. Así, las regresiones que resultan penosas de detectar jugando se capturan mediante un script: la transición de salto y aterrizaje, los umbrales de entrada y salida de la natación, la desactivación automática de la escalada cuando una superficie se nivela y las tasas de consumo de resistencia. Alimentar el motor dos veces con la misma secuencia de entradas e intervalos de tiempo, y comprobar que el estado de salida sea idéntico byte a byte, fija el motor como determinista, que es la propiedad de la que dependerá en el futuro una versión en red. Merece la pena conservar una regresión detectada por el arnés: al pasar de terreno transitable a una pendiente demasiado pronunciada para caminar, antes se activaba el controlador de deslizamiento y el jugador rebotaba cuesta arriba. La solución fue una condición de descenso. El deslizamiento solo comienza si la cápsula está cayendo realmente sobre la pendiente, por lo que caminar horizontalmente contra una superficie inclinada ahora bloquea limpiamente al jugador en lugar de hacerlo deslizarse. La prueba que comprueba que «caminar contra una pendiente no transitable bloquea al jugador» garantiza que siga siendo así.

Conectar un avatar real sin tocar los controladores

Abrir el spike 59 en una pestaña nueva ↗ · Ver código fuente

El spike 59 comprueba si la capa de controladores está realmente desacoplada del cuerpo. Sustituye la cápsula de colores por un personaje real con esqueleto, el rig FBX 3MIKE con clips de Quaternius Universal Animation Library retargeteados sobre él, y los controladores no cambian en absoluto. El punto de unión es una única cadena. Cada controlador ya comunica un nombre de estado mediante stateName: idle, walk, run, jump, fall, land, slide, glide, swim y swimIdle. La capa del avatar asigna ese nombre a un clip retargeteado mediante una tabla de alias y realiza una transición por fundido al cambiar. El controlador de marcha elige dinámicamente su propio subestado a partir del contacto con el suelo, la velocidad vertical y la velocidad horizontal. De este modo, un único controlador de marcha gestiona los estados de reposo, caminar, correr, saltar, caer y aterrizar, y el avatar se limita a seguir el nombre comunicado. Como este spike es para un solo jugador, el avatar elimina la indirección mediante enteros de red y la abstracción de múltiples personajes de los spikes de red anteriores, y asigna el nombre del estado directamente a un clip. La prueba es que toda la mejora visual, desde una cápsula hasta un humano con rig, no modificó ni una sola línea del código de locomoción, que es exactamente la ventaja que debe ofrecer un controlador conectable.

Un paquete que no necesita retargeting y un selector que puedes probar

Abrir el spike 60 en una pestaña nueva ↗ · Ver código fuente

El spike 60 conecta un tercer cuerpo, el paquete POLYGON Base Locomotion de Synty, y el cargador es casi inexistente. Cada clip se distribuye como un FBX independiente que contiene una copia integrada del mismo esqueleto de Synty junto con una animación horneada. Como el rig del personaje y todos los clips utilizan nombres de huesos idénticos, basta con tomar el clip de fbx.animations[0] y reproducirlo directamente en el mezclador del personaje, sin que intervenga ninguna biblioteca de retargeting. Three.js resuelve los destinos de las pistas de animación por el nombre del hueso, no por la identidad del objeto, así que un paquete del estilo de Synty o Mixamo creado para el rig correspondiente funciona directamente. Ese es el contraste deliberado con la ruta de UAL del spike anterior, que requiere un retargeting pesado porque los clips de origen y el rig de destino se crearon para esqueletos diferentes. El mismo controlador, el mismo punto de unión mediante nombres de estado y dos pipelines de animación completamente distintos detrás.

La otra mitad del spike 60 consiste en hacer comprobable la lógica de selección de clips. Elegir qué clip reproducir está lleno de umbrales subjetivos, y esa lógica estaba enterrada dentro de la capa del avatar, junto a FBXLoader y el DOM, donde no se podía probar. El spike extrae el selector a funciones puras que no acceden ni a Three.js ni a la ventana: reciben un registro simple del jugador —velocidad, velocidad horizontal, orientación, contacto con el suelo, normal del terreno y velocidad de impacto— y un sustituto de la acción del clip, y devuelven una cadena con el alias del clip. Esto permite que los umbrales existan como constantes con nombre y verificadas mediante aserciones. El salto se divide en variantes caminando, corriendo y esprintando mediante intervalos de velocidad alineados con el umbral real de esprintar del controlador de marcha; los aterrizajes se dividen en suaves, medios y fuertes según la velocidad de impacto; las variantes de clips cuesta arriba y cuesta abajo se activan a partir del producto escalar de la proyección sobre la pendiente, con una zona muerta que usa el clip para terreno llano por debajo de unos siete grados; una transición de reposo a locomoción siempre se resuelve hacia delante para que arrancar desde parado nunca reproduzca un clip hacia atrás; y una transición de parada está condicionada por un tiempo mínimo dentro del bucle, porque los clips de parada según la fase de los pies de Synty contienen aproximadamente un segundo de desaceleración creada de antemano que resulta ridícula si se añade a un paso que el jugador apenas llegó a dar. Un pequeño estabilizador de estados retrasa el estado de caída durante unos fotogramas para que una pérdida de contacto con el suelo de un solo fotograma al cruzar una junta no haga parpadear la animación. Extraer todo esto de la envoltura de renderizado permite probar las reglas con tests unitarios sin GPU, aplicando la misma disciplina de ejecución sin interfaz gráfica que recibió el propio motor en el spike 58. Esa es la diferencia entre ajustar las sensaciones de locomoción a base de conjeturas y poder definirlas con precisión.

Tecnología mencionada en este capítulo

Un motor de físicas sin locomoción. El motor de cápsulas integra un cuerpo cinemático contra el terreno y no posee lógica para caminar, correr, saltar, aplicar fricción, limitar la velocidad ni aplicar gravedad. Cada comportamiento es un controlador registrado que expone tick, wantsControl, applyForces y, opcionalmente, onEnter/onExit/stateName. Caminar es simplemente el comportamiento predeterminado de menor prioridad que siempre responde que sí, y un controlador puede devolver ownsCollision: true para hacerse cargo de la gestión del terreno. El controlador de natación lo hace para que su resorte de flotabilidad no entre en conflicto con el ajuste de los pies al suelo.

Canales de arbitraje independientes. Los controladores se registran en canales con nombre —recursos, postura y locomoción— que arbitran por separado y se aplican en un orden fijo. Así, observadores como la resistencia y modificadores como agacharse coexisten con la locomoción activa en lugar de fingir que toman el control para después rechazarlo. Las escrituras de recursos, como la resistencia, son leídas por la postura y la locomoción; las escrituras de postura, como la altura de la cápsula al agacharse, son leídas por el límite de velocidad de la locomoción; la locomoción se ejecuta al final y controla la escritura de velocidad. Una fábrica, muchos cuerpos. createCapsuleEngine es una fábrica pura sin singletons, por lo que el mismo motor controla al jugador, un caballo montable que solo puede caminar y un PNJ con dirección autónoma alimentado mediante entradas sintéticas. El repertorio de movimientos de un cuerpo viene determinado exactamente por el conjunto de controladores registrados, así que el caballo no puede trepar ni nadar porque esos controladores nunca se añadieron. La lógica para montar reside en el nivel del host, no en un controlador, porque coordina dos motores que no pueden acceder el uno al otro. Consulta LOD controlado por GPU.

Pruebas deterministas sin interfaz gráfica. El motor no accede a window, document ni Three.js, por lo que un entorno de pruebas de Node lo controla fotograma a fotograma y comprueba el salto y aterrizaje, los umbrales de natación, la desactivación automática de la escalada y el consumo de resistencia. Reproducir dos veces una entrada idéntica y comprobar que la salida también sea idéntica demuestra el determinismo, y una prueba de regresión fija el umbral de descenso que impide que un desplazamiento horizontal contra una pendiente pronunciada haga que el jugador se deslice hacia atrás.

Vinculación de avatares independiente del cuerpo con un selector verificable. Los controladores devuelven una cadena con el nombre del estado y la capa visual la asigna a un clip, por lo que sustituir una cápsula por un avatar 3MIKE + UAL con retargeting no requiere modificar el código de locomoción. Los clips de Synty POLYGON comparten los nombres de los huesos con el rig y se reproducen sin retargeting (Three.js vincula las pistas por el nombre del hueso), a diferencia del costoso retargeting de la ruta UAL. El selector de clips se extrae en funciones puras con constantes con nombre para los intervalos de velocidad de salto, la intensidad del aterrizaje, las variantes de proyección sobre pendientes, una transición desde reposo siempre hacia delante, una duración mínima de protección para la transición de parada y un filtro antirrebote del estado de caída, de modo que las sensaciones de locomoción puedan probarse mediante tests unitarios en lugar de ajustarse a ojo.

Parte 29 de 30. Anterior: Parte 28 - Hierba hasta el horizonte y un terreno que se oculta a sí mismo Siguiente: Parte 30 - Una cámara que respeta las paredes Guía de la serie: /blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 27 construyó la isla y le dio un suelo que no parece repetitivo. Esta parte trata los dos elementos que hacen que un terreno parezca habitado en vez de vacío. El Spike 56 se ocupa de la hierba, el detalle superficial que convierte una ladera texturizada en un lugar por el que caminarías, y el problema consiste en lograr que un campo parezca un campo en lugar de un conjunto de trazos dispersos. El Spike 57 aborda lo contrario a dibujar más: no dibujar lo que una colina ya está ocultando. Y el resultado interesante es que la forma rápida de comprobarlo también resultó ser la correcta.

Hierba que parece un campo, no confeti

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

La decisión fundamental es geométrica. Una única brizna fina y afilada ocupa menos de un píxel desde la mayoría de los ángulos de cámara, así que medio millón de briznas planas parecen confeti verde disperso en vez de un campo. La solución es una mata de quads cruzados: tres quads afilados rotados sesenta grados entre sí alrededor del eje vertical local, de modo que, desde cualquier dirección de visión, al menos uno quede casi perpendicular a la cámara y cada instancia cubra aproximadamente tres anchuras de brizna de área real en pantalla. Esa es la diferencia entre ver trazos verdes y ver hierba.

Un kernel de cómputo de WebGPU coloca cada mata una sola vez durante la inicialización. Convierte mediante hash el índice de instancia en cinco flujos aleatorios descorrelacionados, elige una posición XZ dentro del área, muestrea la altura del terreno a partir del mismo FBM que utiliza la malla de suelo de la CPU —un port a TSL con un mod que conserva el signo para que los valores coincidan exactamente y las briznas descansen sobre la superficie en vez de flotar sobre ella—, calcula una normal mediante diferencias centrales y genera una anchura, una altura y un tono para cada mata. En el lado del renderizado se usa un grafo de vértices TSL que omite por completo la matriz de instancia y escribe directamente en el espacio de recorte: escala el quad cruzado unitario, rota el eje vertical local hasta alinearlo con la normal del terreno mediante la fórmula de Rodrigues y lo traslada a la posición de la mata. El LOD por distancia se obtiene gratis y sin una pasada de descarte, porque el grafo de vértices multiplica la altura de la mata por $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$; así, las matas lejanas se aplanan hasta tener altura cero y dejan de consumir relleno. El viento consta de dos octavas de seno y coseno sobre las coordenadas XZ de la mata en el mundo más el tiempo, se aplica horizontalmente y queda limitado por la fracción de altura para que la base permanezca anclada mientras se mueven las puntas. Además, una ligera inclinación dependiente de la cámara orienta cada mata hacia el espectador para que se abra en perspectiva en vez de parecer una tarjeta plana.

La fórmula de color procede del shader URP de Breath of the Wild creado por NedMakesGames: sombreado plano con el color de la brizna interpolado desde un tono de raíz hasta otro de punta a lo largo de la fracción de altura; a su vez, los tonos de raíz y punta se interpolan entre dos paletas mediante el valor de tono de cada mata. Esto produce el aspecto moteado de dos tonos que tiene un campo de hierba real de BotW. La iluminación difusa compara la normal del terreno con el sol e incluye un mínimo de luz ambiental, porque las normales de cada quad cruzado son demasiado ruidosas para sombrearlas individualmente con un estilo visual estilizado. Todo el campo se dibuja en una sola llamada y se coloca y anima por completo en la GPU.

Cuatro formas de descartar lo que oculta una colina

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

El Spike 57 compara cuatro métodos de descarte sobre el mismo mundo procedimental que transmite por streaming el cliente de producción, escalado verticalmente 1,8 veces para que las colinas oculten de verdad el follaje. T0 solo tiene en cuenta la distancia, igual que el sistema de visibilidad de chunks que ya utiliza la versión publicada. T1 añade descarte por frustum, la mejora barata más importante, que elimina todo lo que queda fuera del cono de visión. T2 añade una prueba de horizonte que tiene en cuenta el terreno: recorre un rayo desde el ojo hasta cada instancia y la rechaza si el mapa de alturas supera el rayo en algún punto del trayecto, de modo que un árbol situado detrás de una cresta se descarta aunque esté dentro del frustum. T3 conserva la misma prueba de horizonte, pero la acelera mediante una pirámide de alturas máximas. T4 traslada toda la prueba de distancia, frustum y horizonte a un kernel de cómputo TSL que escribe una escala de visibilidad por instancia, leída por el material del follaje para colapsar los vértices ocultos. Un contador que mantiene la visibilidad durante dos fotogramas suaviza el parpadeo de un solo fotograma que se produce cuando un punto de muestreo cae justo dentro o fuera de un texel al mover ligeramente la cámara. Se mantiene corto deliberadamente, porque una duración mayor ocultaría errores algorítmicos en lugar de corregirlos.

La pirámide es donde el spike demuestra su valor, y la lección consiste en hacer que la prueba coincida con lo que realmente aparece en pantalla. El terreno renderizado es una malla de triángulos con vértices situados en una cuadrícula fija de dos metros, y entre los vértices el rasterizador interpola linealmente. Por tanto, la altura máxima real renderizada dentro de cualquier rectángulo es el máximo de los vértices que contiene, nunca el pico del ruido continuo situado entre ellos. Si la pirámide de oclusión muestrea el ruido en una cuadrícula más fina, encuentra picos fantasma que la malla nunca muestra y empieza a bloquear rayos que la cámara puede ver atravesar claramente. Por eso, los texeles de la base de la pirámide se sitúan exactamente sobre la cuadrícula de vértices y cada uno almacena el máximo de sus cuatro vértices de esquina. Los niveles superiores son reducciones máximas 2x2 convencionales, lo que hace que la pirámide sea exacta respecto a la malla renderizada. Para la prueba del rayo en cada paso, el código muestrea deliberadamente la malla por puntos mediante interpolación bilineal en vez de consultar la pirámide, porque una consulta AABB más pequeña que un texel devuelve el máximo de todo el texel y eleva la altura varios metros en crestas pronunciadas. Ese es precisamente el tipo de oclusión excesiva que ocultaría elementos visibles.

El resultado sorprendente es que T2, la referencia por fuerza bruta, es el método incorrecto. Como T2 muestrea directamente por puntos el ruido continuo, detecta picos entre vértices de la malla que nunca se renderizan, por lo que produce una ligera oclusión excesiva y oculta follaje que el jugador sí puede ver. El método de la pirámide es más rápido, gracias a la reducción AABB de $O(\log N)$ para las pruebas a nivel de chunk, y también más correcto geométricamente, porque solo puede devolver alturas que la malla muestra realmente. Esa es la idea central del spike: la estructura acelerada no es una concesión de calidad a cambio de velocidad, sino la versión que coincide con la realidad. El descarte de chunks ejecuta una prueba de cinco puntos por chunk —las cuatro esquinas superiores más el centro a la altura máxima del chunk— y excluye del conjunto de oclusores la huella de cada propio chunk para que nunca se ocluya a sí mismo. El método recomendado para producción es T4: enviar los metadatos de instancia y el campo de alturas a búferes de almacenamiento y ejecutar el mismo bucle en un shader de cómputo con dibujo indirecto, puesto que el renderizador ya está migrando a WebGPU.

Tecnología mencionada en este capítulo

Hierba de GPU con quads cruzados. Tres quads afilados rotados sesenta grados entre sí por mata garantizan que uno quede casi perpendicular desde cualquier ángulo, de modo que medio millón de instancias parezcan un campo en vez de confeti de menos de un píxel. Un kernel de cómputo coloca cada mata —altura del terreno FBM muestreada con el mismo mod que conserva el signo que utiliza la malla de la CPU, normal por diferencias centrales, tamaño y tono por mata— y un grafo de vértices TSL omite la matriz de instancia para escalar, rotar mediante Rodrigues hasta la normal, trasladar y aplicar viento limitado por la altura. El LOD por distancia es gratis: las matas colapsan hasta una altura cero mediante $1-\text{smoothstep}(\text{fadeNear},\text{fadeFar},\text{dist})$. El color sigue la fórmula de BotW de NedMakesGames: un degradado de la raíz a la punta sobre dos paletas mezcladas según el tono. Consulta LOD controlado por GPU.

Descarte por oclusión del horizonte del terreno. Cuatro métodos comparados sobre el mundo de producción: distancia; más frustum; más una prueba de rayos sobre el mapa de alturas que rechaza instancias situadas detrás de una cresta; más una pirámide de alturas máximas que la acelera; y un port completo a cómputo TSL. La pirámide muestrea exactamente sobre la cuadrícula de vértices de dos metros que tesela la malla —texel base = máximo de los cuatro vértices de esquina, seguido de reducciones máximas 2x2 hacia arriba—, por lo que solo devuelve alturas que el rasterizador muestra realmente.

Acelerado y correcto, no una concesión. El muestreo por puntos del ruido continuo —el método T2 por fuerza bruta— encuentra picos entre vértices de la malla que nunca se renderizan y oculta en exceso follaje visible. La pirámide basada en la cuadrícula de vértices es más rápida —reducción AABB de $O(\log N)$— y geométricamente exacta. Por eso, las pruebas de rayos por paso muestrean la malla bilinealmente en vez de consultar el máximo por texel de la pirámide, que elevaría las alturas varios metros en crestas pronunciadas. El descarte de chunks utiliza una prueba de cinco puntos y excluye la huella de cada propio chunk para que nunca se ocluya a sí mismo. El método de producción envía los metadatos y el campo de alturas a búferes de almacenamiento para realizar el descarte en un shader de cómputo con dibujo indirecto.

Parte 28 de 29. Anterior: Parte 27 - Una isla creada con ruido y un suelo que parece suelo Siguiente: Parte 29 - Un controlador, cualquier cuerpo Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 26 añadió agua al mundo. Esta parte construye la tierra que hay debajo en dos etapas que reflejan cómo llega a formarse un lugar real. El Spike 54 es el terreno en sí: no se esculpe a mano, sino que se genera a partir de ruido y luego se erosiona hasta adquirir el drenaje y la costa de un lugar por el que realmente ha corrido el agua. El Spike 55 es la piel de ese terreno: resuelve el problema que arruina casi todos los suelos procedurales, que una textura teselada parece teselada. Juntos responden a una pregunta: ¿puede un creador obtener una isla verosímil y un suelo que se perciba como tal sin que un artista intervenga en ninguno de los dos? La respuesta es sí, si se copian las recetas adecuadas.

Una costa que el ruido por sí solo no puede darte

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

El mapa de alturas sigue las recetas de Red Blob Games, que consisten en una pila de pequeñas transformaciones donde cada una corrige un defecto específico del ruido sin procesar. El movimiento browniano fraccionario suma varias octavas de ruido Perlin para que el terreno tenga tanto colinas amplias como detalles finos, pero el FBM básico parece suave y alineado con la cuadrícula, así que primero se aplica una deformación de dominio al punto de muestreo: cada coordenada se desplaza mediante otro campo de ruido, $p^{\prime }=p+\text{noise}(p)\cdot s$, lo que curva las crestas y les da un aspecto orgánico en lugar de dejarlas ancladas a los ejes. Después, la redistribución, que eleva la altura a una potencia $e^k$, reduce los tonos medios para que el mundo tenga valles planos y picos escarpados, en vez de mantenerlo todo en la misma pendiente suave. Lo que lo convierte en una isla, en lugar de en colinas infinitas, es una atenuación radial: se calcula la distancia euclídea desde el centro, $d=min(1,\sqrt{n_x^2+n_y^2})$, y se mezcla la elevación hacia $1-d$ para que el terreno descienda hasta el océano en los bordes. Un segundo campo de ruido independiente se convierte en un mapa de humedad, que no afecta a la forma, pero alimenta posteriormente la etapa de asignación de biomas.

Eso produce una forma, pero sigue siendo una forma creada con ruido. No tiene ríos, valles excavados por el agua ni abanicos de sedimentos, porque nada ha fluido nunca sobre ella. La solución es la erosión hidráulica, adaptada de la implementación de Sebastian Lague con licencia MIT. Miles de gotas de agua aparecen en posiciones aleatorias y descienden por las pendientes. Cada una conserva inercia para no realizar giros bruscos en ángulo recto, recoge sedimentos cuando acelera y los deposita cuando frena o se estanca. Un pincel circular precalculado distribuye cada evento de erosión sobre un radio pequeño para que la excavación sea suave en lugar de un arañazo de un solo píxel, y la evaporación elimina la gota al final de su vida. Con suficientes gotas, el terreno desarrolla aquello que el ruido no puede imitar: redes de drenaje que convergen, valles que se ensanchan aguas abajo y zonas llanas donde se acumularon los sedimentos.

Erosión en la GPU y ríos que saben dónde están

La erosión en la CPU es correcta, pero lenta, así que el spike también la adapta a un shader de cómputo de WebGPU. Lo interesante es lo que las operaciones atómicas de la GPU obligan a hacer. Las alturas se almacenan como valores de punto fijo i32 con una escala de un millón, porque WGSL no permite sumas atómicas con números de coma flotante. La única forma de que miles de gotas depositen y retiren sedimentos de una misma celda en paralelo sin condiciones de carrera es utilizar atomicAdd y atomicSub con enteros. La conversión de ida y vuelta a punto fijo implica que, bajo una erosión concurrente intensa, una celda puede volverse ocasionalmente un poco negativa, algo inofensivo que se limita al recuperar los datos. La versión para CPU precalcula una tabla de pinceles por celda, pero con una cuadrícula de ${1001}^2$ esa tabla ocupa alrededor de 100 MB. Por eso, la versión para GPU vuelve a calcular sobre la marcha el pincel de cada gota, intercambiando un poco de aritmética por un gran ahorro de memoria. Las posiciones iniciales de las gotas siguen procediendo de la CPU mediante un generador Mulberry32, por lo que las ejecuciones son deterministas.

Dos pasadas adicionales convierten el terreno erosionado en un mapa legible. El drenaje utiliza el método D8 de acumulación de flujo de Red Blob: se deposita una unidad de lluvia en cada celda, se ordenan todas las celdas por elevación descendente y se transfiere el agua acumulada de cada celda a su único vecino más bajo. Así, el agua se concentra a lo largo de los valles naturales y cualquier celda cuya acumulación supere un umbral se marca como río. El problema es que un mapa de alturas erosionado tiene depresiones, hundimientos locales sin salida cuesta abajo. El agua que entra en una depresión simplemente se detiene y rompe la acumulación. Por eso, antes de calcular el drenaje, el rellenado de depresiones Planchon-Darboux eleva cada una hasta situarla justo por encima de su vecino más bajo, $\text{minNeighbour}+ϵ$, iterando durante menos de veinte pasadas hasta que todas las celdas tienen algún lugar por el que drenar. Por último, los biomas se asignan al estilo de Red Blob mediante una consulta en dos ejes que cruza elevación y humedad, de modo que una celda alta y seca se convierte en roca, mientras que una baja y húmeda se convierte en ciénaga. Encima se aplican excepciones basadas en la pendiente: las caras empinadas se fuerzan a roca sin importar la humedad, la franja de la línea de agua se convierte en playa y las elevaciones más altas reciben nieve. El resultado es una isla que se entiende de un vistazo, generada de principio a fin a partir de dos semillas de ruido.

La tesela que no deja de repetirse

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

Un terreno necesita un material que cubra kilómetros a partir de una textura de apenas un par de metros, y en cuanto se escala una tesela para cubrir el suelo, el ojo detecta la repetición. El Spike 55 es una prueba comparativa A/B de cuatro modos de muestreo sobre la misma geometría e iluminación, por lo que la única variable es cómo se lee la textura. La referencia básica es plain: una sola muestra en las UV escaladas, que se repite de forma evidente cada pocos metros y solo existe como el rival al que hay que superar. Las capas PBR gratuitas proceden de Poly Haven a través de su CDN: textura difusa, mapa ARM empaquetado (oclusión ambiental, rugosidad y metalicidad) y un mapa normal GL, todo con licencia CC0, cargado con anisotropía 8 y mipmaps.

Los otros tres modos son distintos ataques contra la repetición. El modo hex-linear es la cuadrícula triangular de Heitz-Neyret: se coloca una retícula triangular sesgada sobre la superficie, y cada fragmento queda dentro de un triángulo cuyos tres vértices toman muestras desplazadas aleatoriamente. Estas se mezclan mediante pesos baricéntricos para que las regiones vecinas muestreen distintas partes de la textura y el teselado a gran escala desaparezca. Sin embargo, una mezcla lineal básica de tres muestras promedia sus colores en los bordes de los triángulos, lo que deja un patrón triangular visible, exactamente el artefacto que apareció en el spike 48. El modo hex-vp es la corrección publicada en el mismo artículo de 2018: tras la suma baricéntrica, resta el color medio de la textura, vuelve a escalar mediante la raíz cuadrada inversa de la suma de los pesos al cuadrado para mantener constante la varianza y, después, vuelve a añadir la media. Esto mantiene estable el contraste en toda la mezcla y hace que los triángulos desaparezcan. Por esa razón, el material realiza inicialmente una lectura de 1 por 1 de cada textura cargada para estimar su color medio. El cuarto modo, iq-untiled, es la técnica 3 de repetición de texturas de Inigo Quilez: dos muestras desplazadas que se mezclan mediante un patrón de variación de baja frecuencia; solo dos muestras en lugar de tres y ninguna estructura triangular desde el principio, la opción económica que mantiene una buena calidad.

Sobre cualquiera de estos modos puede aplicarse una proyección triplanar opcional, que permite que el mismo material envuelva un acantilado sin estirarse. En vez de utilizar una sola UV, el shader muestrea tres proyecciones sobre los ejes del mundo: las superficies orientadas hacia X leen el plano YZ, las orientadas hacia Y leen ZX y las orientadas hacia Z leen XY. Después las mezcla mediante abs(normalWorld) elevado a una potencia de realce entre cuatro y ocho, para que una pendiente de 45 grados no convierta las tres proyecciones superpuestas en una masa borrosa. La comparativa deja clara la contrapartida: la mezcla hexagonal que conserva la varianza ofrece la mejor calidad, mientras que el método de dos muestras de Quilez es la opción orientada al rendimiento. Ambos superan al modo básico por un margen lo bastante amplio como para que ningún creador deba publicar jamás una tesela sin tratar.

Tecnología mencionada en este capítulo

Generación de mapas de alturas mediante recetas apiladas. Las recetas de Red Blob Games combinan ruido sin procesar para convertirlo en terreno: FBM con deformación de dominio ($p^{\prime }=p+\text{noise}(p)\cdot s$) para crear crestas orgánicas, redistribución $e^k$ para obtener valles planos y picos escarpados, y una atenuación radial euclídea mezclada hacia $1-d$ para hundir los bordes en el océano y formar una isla. Un segundo campo de ruido sirve como mapa de humedad para asignar los biomas. Consulta generación de paisajes.

Erosión hidráulica en CPU y GPU. El modelo de gotas de Sebastian Lague (inercia, capacidad de transporte, pincel circular precalculado para depositar sedimentos y evaporación) excava redes de drenaje reales que el ruido no puede imitar. La adaptación de cómputo para WebGPU almacena las alturas como valores de punto fijo i32 con una escala de un millón, de modo que las gotas puedan aplicar atomicAdd/atomicSub en paralelo sobre la misma celda. También recalcula sobre la marcha el pincel de cada gota para evitar una tabla de unos 100 MB con una resolución de ${1001}^2$, y genera las posiciones iniciales mediante un generador Mulberry32 determinista.

Drenaje D8 con rellenado de depresiones. La acumulación de flujo D8 de Red Blob deposita una unidad de lluvia por celda, ordena las celdas por elevación descendente y transfiere el agua al vecino más bajo de cada celda, marcando como ríos las que superan un umbral. El rellenado de depresiones Planchon-Darboux eleva primero cada hundimiento local hasta $\text{minNeighbour}+ϵ$ (en menos de veinte pasadas), de modo que el agua nunca quede atrapada y la acumulación permanezca conectada. Una consulta en dos ejes que cruza elevación y humedad asigna los biomas, con excepciones según la pendiente que fuerzan roca en los acantilados, playa en la línea de agua y nieve en los picos.

Cuatro formas de romper la repetición de texturas. Sobre geometría e iluminación idénticas: plain (una muestra, con un teselado evidente), hex-linear (cuadrícula triangular de Heitz-Neyret, cuya mezcla lineal deja un patrón triangular), hex-vp (la corrección de EGSR 2018 §3.3 que conserva la varianza restando la media, reescalando mediante la raíz cuadrada inversa de los pesos al cuadrado y volviendo a sumar la media, lo que requiere una lectura media de 1×1 por textura) e iq-untiled (la técnica 3 de dos muestras de Inigo Quilez). La proyección triplanar muestrea tres planos de los ejes del mundo y los mezcla mediante abs(normalWorld) elevado a una potencia de 4-8 para evitar que los acantilados se estiren. La conservación de la varianza gana en calidad; las dos muestras, en coste. Consulta materiales de terreno.

Parte 27 de 29. Anterior: Parte 26 - Tres formas de crear agua Siguiente: Parte 28 - Hierba hasta el horizonte y un suelo que se oculta a sí mismo Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 25 vistió a los avatares. Esta parte trata sobre el agua, y consta de tres experimentos porque el agua es la superficie en la que un atajo barato y la solución correcta parecen idénticos en una captura de pantalla, pero completamente distintos en movimiento. El experimento 51 genera reflejos mediante el espacio de pantalla, la opción tentadora, y choca de frente con su limitación inherente. El experimento 52 cambia al método que utilizan realmente todos los juegos publicados. El experimento 53 incorpora una biblioteca de agua terminada para ver lo lejos que estamos de poder considerarlo «listo». Los tres comparten una misma capa de refracción, por lo que la única variable que cambia entre los dos primeros es cómo se calcula el reflejo.

Reflejos a partir de la pantalla que ya tienes

Abrir el experimento 51 en una pestaña nueva ↗ · Ver el código fuente

Los reflejos en espacio de pantalla reutilizan el fotograma que ya has renderizado. Para cada píxel del agua, reflejas el rayo de visión sobre la superficie, haces avanzar ese rayo reflejado por el búfer de profundidad y, cuando el rayo pasa por detrás de una superficie registrada, has encontrado lo que refleja el agua, muestreado directamente desde el búfer de color. La adaptación sigue línea por línea el SSRNode de three.js, que a su vez sigue la introducción a SSR de lettier. El avance es un recorrido DDA en espacio de pantalla: se proyectan el inicio y el final del rayo a coordenadas de píxel y se avanza por el eje que sea más largo, con una muestra por píxel. La profundidad del rayo reflejado en cada paso necesita una interpolación con corrección de perspectiva, $\frac{1}{1/z_0+s(1/z_1-1/z_0)}$, porque interpolar linealmente la Z de vista es sencillamente incorrecto y produce intersecciones en lugares equivocados.

Dos cosas hacen que esto sea utilizable en lugar de una presentación de diapositivas. El recorrido grueso está limitado a 64 pasos, porque, de lo contrario, un rayo largo proyectado a lo largo de mil píxeles ejecutaría cientos de iteraciones por fragmento, y un plano de agua con un millón de fragmentos multiplicado por cientos de iteraciones y por varias muestras de textura da como resultado una escena a 30 fps. La calidad controla la zancada efectiva dentro de ese límite, en lugar del número de iteraciones. Y como un recorrido grueso limitado deja bandas visibles en forma de escalones, un refinamiento binario de seis iteraciones biseca el intervalo entre el último fallo y la intersección, lo que proporciona una precisión de subpaso 64 veces mayor, suficiente para que los fragmentos de agua vecinos dejen de fijarse en la misma posición de intersección gruesa. Una comprobación final de distancia entre punto y línea confirma que el candidato está realmente sobre el rayo de reflexión y no solo a la misma profundidad, con una tolerancia de grosor que se ajusta automáticamente a la anchura en espacio de vista de un píxel a esa profundidad: más estricta de cerca y más permisiva de lejos.

La parte honesta de este experimento está escrita en sus propios comentarios: SSR no puede reflejar lo que la cámara principal nunca muestreó. La parte inferior de un árbol, cualquier cosa que esté fuera de pantalla o cualquier cosa ocluida no existe en los búferes, así que no puede aparecer en el reflejo. Esa es la «pérdida de información del lado incorrecto» que ninguna mejora de calidad del recorrido puede solucionar, y es exactamente la razón por la que existe el siguiente experimento.

El espejo que no puede mentir

Abrir el experimento 52 en una pestaña nueva ↗ · Ver el código fuente

Un reflejo planar renderiza la escena una segunda vez desde una cámara reflejada respecto al plano del agua, hacia un destino fuera de pantalla que el shader del agua muestrea. Este es el patrón canónico, el que utilizan UE5 Water, el propio WaterMesh de three.js, ABZÛ y Sea of Thieves, porque dispone de todos los píxeles de la escena, incluida la geometría que SSR nunca puede ver. En TSL resulta casi anticlimático: reflector() asigna la cámara auxiliar reflejada y su destino de renderizado, añades su destino a la malla para que se actualice en cada fotograma y muestreas su color. Cuando incorporemos las olas, el reflejo ondulará al añadir un desplazamiento de distorsión al nodo UV del reflector, que es exactamente la línea que utiliza WaterMesh.

El error que merece la pena registrar estaba en la red de seguridad, no en el espejo. Una versión anterior mezclaba la salida del reflector con un cielo procedimental como alternativa, ponderada según la magnitud del color reflejado, basándose en la teoría de que un reflejo cercano a cero significaba que el destino no contenía nada allí. Pero una sombra oscura bajo el dosel también tiene una magnitud baja, por lo que la limitación nunca alcanzaba su intensidad máxima y esos píxeles realmente oscuros acababan mezclados con el cielo luminoso. El síntoma detectado por el usuario era preciso: en modo de depuración, el destino del espejo sin procesar mostraba árboles oscuros perfectos, mientras que el renderizado compuesto presentaba reflejos desvaídos, y el diagnóstico fue que el shader «hace desaparecer los colores oscuros». La solución fue eliminar código. El destino del reflector es fiable después del primer fotograma, así que no hace falta ninguna alternativa. Ambos experimentos comparten la misma refracción subyacente: muestrear la escena detrás de la superficie, reconstruir a qué profundidad bajo la línea de flotación se encuentra cada píxel y aplicar una extinción de Beer-Lambert por canal para que el rojo desaparezca tras unos pocos metros mientras el azul persiste, con una máscara de cielo para que la imagen de fondo del plano lejano no reciba niebla. El efecto Fresnel de Schlick mezcla refracción cuando miras directamente hacia abajo dentro del agua y reflejo cuando miras a través de ella.

Qué aspecto tiene un resultado terminado

Abrir el experimento 53 en una pestaña nueva ↗ · Ver el código fuente

El experimento 53 es la comprobación entre desarrollar o comprar. Incorpora threejs-water-pro tal como se distribuye, con su preajuste tropical, su clipmap oceánico predeterminado, seguimiento de cámara y cielo de Rayleigh, y carga la misma isla glTF que utiliza la demostración de la propia biblioteca. El objetivo es ver la distancia entre un shader de agua plana creado a mano y un sistema oceánico completo, y esa distancia es grande: este tiene un sistema de flotabilidad que muestrea la altura de las olas en varios puntos bajo el casco de un barco para que cabecee y se balancee en lugar de limitarse a subir y bajar, un generador de estelas, espuma en la costa y la superficie, y una pasada de máscara que impide renderizar agua dentro del casco para que las ondas no atraviesen la cubierta.

La integración reveló el tipo de detalle que solo se aprende usando una biblioteca en lugar de leyendo su README. El preajuste hace referencia a las texturas de espuma por nombre de archivo, pero cargarlas es responsabilidad de quien usa la biblioteca; sin ellas, la costa parece un borde duro en la línea de flotación en lugar de olas rompiendo. La isla está situada de modo que su geometría submarina desciende más allá del fondo oceánico, permitiendo que la malla del fondo de la biblioteca oculte el anillo exterior del modelo sin dejar visible el borde del plano. Este es el patrón previsto por la biblioteca: aportar un modelo 3D, no sintetizar el terreno. Además, el antialiasing está desactivado deliberadamente en el renderizador a favor de una pasada FXAA de posprocesado, porque MSAA mezcla los fragmentos de borde con el fondo antes de que se aplique la niebla atmosférica basada en profundidad, lo que deja una franja oscura y fina allí donde la geometría se encuentra con la niebla. Resolver el aliasing después de la niebla, en lugar de antes, elimina esa franja. Lo que esto reduce es el riesgo de la propia decisión: un océano para producción es un sistema grande y especializado y, en los casos en que necesitamos uno, adoptar una biblioteca mantenida es mejor que reconstruir desde cero las estelas, la flotabilidad y la espuma, mientras que el shader de espejo planar del experimento 52 sigue siendo la solución adecuada para las masas de agua interiores más pequeñas que un creador coloca en su propio mundo.

Tecnología mencionada en este capítulo

Agua con reflejos en espacio de pantalla. Un rayo de visión reflejado recorre el búfer de profundidad en espacio de pantalla mediante DDA, utilizando interpolación 1/z con corrección de perspectiva, un límite estricto de pasos para acotar el coste por fragmento y una pasada de refinamiento binario para eliminar las bandas que deja un recorrido limitado. Una confirmación de punto a línea con un grosor ajustado según la profundidad rechaza intersecciones falsas. El límite absoluto del método es que solo puede reflejar la geometría que la cámara principal ya ha muestreado, por lo que las superficies fuera de pantalla y del lado incorrecto nunca aparecen. Consulta materiales del terreno.

Reflejo de espejo planar. Una cámara auxiliar reflejada respecto al plano del agua renderiza la escena en un destino fuera de pantalla que muestrea el shader del agua, lo que proporciona reflejos perfectos a nivel de píxel, incluida la geometría que SSR no puede ver. Este es el patrón que utilizan UE5 Water y WaterMesh de three.js, con la distorsión de las olas aplicada como desplazamiento al nodo UV del reflector. Una alternativa de cielo ponderada por magnitud borraba erróneamente los píxeles oscuros del reflejo; el destino del reflector es fiable después del primer fotograma, así que la solución fue eliminar esa alternativa.

Refracción con tinte de profundidad de Beer-Lambert. Ambos shaders muestrean la escena detrás de la superficie, reconstruyen la profundidad de cada píxel del fondo bajo la línea de flotación y aplican extinción exponencial por canal —el rojo desaparece en cuestión de metros, mientras que el azul persiste— compuesta hacia un color de niebla acuática, con una máscara de cielo para que el plano lejano no reciba niebla. El efecto Fresnel de Schlick mezcla refracción en incidencia normal con reflejo en ángulos rasantes.

Adopción de una biblioteca de agua para producción. threejs-water-pro incluye un clipmap oceánico, cielo de Rayleigh, flotabilidad multipunto para el cabeceo y balanceo de barcos, estelas, espuma y una pasada de máscara para el casco. Los detalles del lado del consumidor importan: las texturas de espuma deben cargarse explícitamente, la geometría submarina de la isla debe descender más allá del fondo oceánico para que este oculte sus bordes y el antialiasing debe ejecutarse como una pasada FXAA de posprocesado, en lugar de utilizar MSAA, para evitar una franja oscura de niebla en los bordes de la geometría.

Parte 26 de 29. Anterior: Parte 25 - Un esqueleto, todos los atuendos Siguiente: Parte 27 - Una isla creada con ruido y un suelo que parece suelo Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Un bosque es una de las peores cosas que se le puede pedir renderizar a una GPU. Cada hoja es un cuadrilátero texturizado recortado mediante una máscara alfa. Decenas de esos cuadriláteros se apilan unos sobre otros a lo largo de cada rayo de visión. El rasterizador no tiene forma de saber de antemano qué fragmentos superarán la prueba alfa, por lo que la optimización estándar de Z temprana que aligera las escenas opacas queda desactivada en su mayor parte. El resultado es que un solo píxel de la pantalla puede ejecutar el shader completo de las hojas 10 o 15 veces antes de completar el fotograma. Eso es el sobredibujado del follaje, y es el componente más costoso de un fotograma de mundo abierto en cualquier juego publicado durante la última década.

La buena noticia es que es un problema resuelto. No en el sentido de que alguien lo haya arreglado con un único truco, sino en el de que existe un conjunto de siete u ocho técnicas que, combinadas, reducen el sobredibujado efectivo de 8-15x en un bosque denso a 1-2x. Todos los motores modernos incluyen alguna versión de este conjunto. Veamos qué contiene, por qué existe cada componente y cuáles son las referencias canónicas de cada uno.

1. Por qué el sobredibujado del follaje es tan costoso

En una escena opaca típica, la GPU realiza un rechazo temprano por profundidad: antes incluso de que se ejecute el shader de píxeles, el hardware consulta el búfer de profundidad existente y omite los fragmentos que ya están detrás de algo. Esto es prácticamente gratuito y es lo que mantiene bajo control el coste de la geometría densa.

El follaje con prueba alfa rompe este proceso. El shader de fragmentos tiene que ejecutarse de verdad para evaluar la textura alfa y llamar a discard (o clip) en los píxeles excluidos por la máscara. El hardware no puede saber si se descartará un fragmento hasta después de ejecutar el shader, por lo que, en la mayoría de las GPU, usar discard en cualquier parte de un shader desactiva por completo la Z temprana para esa llamada de dibujo. En las GPU basadas en mosaicos (dispositivos móviles, serie M y algunas consolas), puede desactivar Hi-Z y la compresión de profundidad para todo el fotograma. El shader de píxeles se ejecuta una vez por cada triángulo que cubre un píxel, y la mayoría de esas evaluaciones terminan en un descarte.

Apila 10 cuadriláteros de hojas frente a un solo píxel de la pantalla y el shader de las hojas se ejecutará 10 veces. Multiplícalo por 4 millones de píxeles y el coste será brutal. El artículo de Marco Salvi To Early-Z, or Not To Early-Z es la introducción más accesible a por qué sucede esto en el nivel del hardware, y es el lugar adecuado para empezar si nunca te lo habías planteado.

2. La prepasada de profundidad para geometría enmascarada

La mayor mejora individual, y la técnica que incluyen todos los motores modernos, consiste en dividir el dibujado del follaje en dos pasadas. La primera pasada solo escribe la profundidad, con un shader mínimo que realiza la prueba alfa, descarta los píxeles enmascarados y no escribe nada más. La segunda pasada renderiza el material completo con la prueba de profundidad configurada como «igual» y la escritura de profundidad desactivada. Ahora, cada píxel visible sombrea la BRDF completa exactamente una vez, sin importar cuántos cuadriláteros de hojas haya apilados detrás.

Esto puede parecer el doble de trabajo porque se procesan los mismos triángulos dos veces, pero el shader de la prepasada es tan barato —una muestra de textura, un descarte y una escritura de profundidad— que el ahorro en la pasada principal supera con creces el coste adicional. En un bosque denso, la pasada principal pasa de ejecutar el shader completo de las hojas entre 10 y 15 veces por píxel a ejecutarlo exactamente una vez.

Unreal, Frostbite, Decima y las ramas modernas de Rage y Dunia hacen esto. También es la razón principal por la que los materiales enmascarados siguen siendo más baratos que los materiales translúcidos en cualquiera de estos motores.

Análisis en profundidad:

• Pettineo, To Early-Z, or Not To Early-Z (el artículo canónico sobre cómo interactúa discard con Hi-Z y la Z temprana).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, la arquitectura de Frostbite de prepasada de profundidad y descarte dirigido por la prepasada).
• Sanders, Between Tech and Art: The Vegetation of Horizon Zero Dawn (GDC 2018, con el renderizado de follaje en dos pasadas de Decima).
• Persson, A couple of notes about Z (sigue siendo una de las explicaciones más claras de la prueba de profundidad «igual» y de la rentabilidad de una prepasada).

3. LOD agresivos e impostores octaédricos

La segunda mayor mejora consiste en no dibujar las hojas en absoluto cuando no hace falta. Los recursos de follaje incluyen varios niveles de LOD. El más cercano es la malla completa con tarjetas individuales para cada hoja. A media distancia, las hojas se agrupan en tarjetas compuestas más densas —un grupo de 30 hojas se convierte en una tarjeta texturizada con la misma silueta—. Más allá de un umbral de distancia, el árbol entero se convierte en un impostor: una pequeña pieza de geometría texturizada con vistas prerenderizadas del árbol desde múltiples ángulos.

El formato moderno es el impostor octaédrico: una pieza geométrica de 8 caras texturizada con un atlas de vistas capturadas desde puntos de una esfera mediante mapeado octaédrico. Durante la ejecución, el shader elige las dos o tres vistas prerenderizadas más cercanas según la dirección de la cámara y mezcla entre ellas. El resultado es un sustituto de pocos triángulos que parece tridimensional desde cualquier ángulo y que puede tener sombreado correcto, mapas de normales e incluso animación por viento. La implementación de Ryan Brucks, originalmente un plugin de la comunidad y ahora parte de Unreal, es la referencia. Los bosques de mil millones de árboles de Microsoft Flight Simulator son esencialmente impostores octaédricos en todas partes salvo cerca de la cámara.

La mayor ventaja estructural es que los impostores son opacos o casi opacos a distancia. La tarjeta compuesta por 30 hojas es un solo cuadrilátero enmascarado en lugar de 30. El impostor del árbol entero tiene unas pocas caras, no miles. El sobredibujado a larga distancia se reduce a casi nada.

Análisis en profundidad:

• Brucks, Octahedral Impostors (la referencia canónica, con las matemáticas y la implementación para UE).
• Halen, Octahedral Impostors in Unreal Engine (el flujo de trabajo integrado en UE).
• Häggström, Real-Time Rendering of Vegetation (una tesis clara que cubre las cadenas de LOD, los impostores y las matemáticas subyacentes).
• Crytek, SpeedTree integration in CryEngine 3 (GPU Gems 3, aún la mejor introducción a las cadenas de LOD para árboles).

4. Descarte de clústeres gestionado por GPU

Incluso con una prepasada de profundidad, la propia prepasada tiene un coste: todavía debe procesar cada triángulo de cada árbol visible —o potencialmente visible—. Los motores modernos reducen ese coste mediante el descarte de clústeres gestionado por GPU, que elimina grupos enteros de triángulos antes de que lleguen al rasterizador.

La canalización funciona así: cada malla se divide previamente en clústeres de 64 o 128 triángulos con una caja delimitadora ajustada y un cono de normales. Durante el renderizado, un shader de cómputo recorre la lista de instancias, comprueba cada instancia contra el frustum, después comprueba contra el frustum cada clúster de cada instancia visible y, por último, realiza una prueba de oclusión Hi-Z de cada clúster superviviente contra la pirámide de profundidad del fotograma anterior. Las ramas completas de los árboles que quedan ocultas detrás de una colina o delante de otro árbol se descartan antes de que se ejecute ningún shader de vértices. El resultado es una lista compacta de argumentos del tipo «dibuja estos clústeres», enviada directamente a una única llamada DrawIndirect.

Esto es lo que permite renderizar un bosque de 10 000 árboles en milisegundos en lugar de segundos. La charla de Ubisoft sobre Assassin's Creed Unity presentó esta canalización en un entorno de producción —entre un 20 y un 40 % de triángulos descartados, entre un 30 y un 80 % de triángulos de sombras descartados y 10 veces más instancias en pantalla que en la generación anterior—, y la charla de Wihlidal sobre Frostbite la llevó aún más lejos. Nanite de UE5 es el resultado visible de esta evolución: descarte de clústeres hasta el nivel del píxel.

Análisis en profundidad:

• Haar y Aaltonen, GPU-Driven Rendering Pipelines (SIGGRAPH 2015, la charla fundacional sobre Assassin's Creed Unity).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, la prepasada gestionada por GPU de Frostbite).
• Karis, Stubbe y Wihlidal, A Deep Dive into Nanite Virtualized Geometry (SIGGRAPH 2021, descarte de clústeres con granularidad de meshlet).
• Liktor, Geometry Rendering Pipeline Architecture at Activision (la versión de Call of Duty del descarte de clústeres, 2021).

5. Ordenación de instancias y clústeres de delante hacia atrás

Cuando la prepasada cumple su función, el orden empieza a importar. La prepasada escribe la profundidad, pero solo para los fragmentos que superan la prueba alfa. Si primero dibujas la parte trasera del bosque y al final la delantera, cada fragmento delantero sobrescribe uno trasero, y el shader de la prepasada sigue ejecutándose para la parte trasera. Si dibujas de delante hacia atrás, cada llamada sucesiva llena una parte mayor del búfer de profundidad con valores más pequeños, y Hi-Z rechaza cada vez más fragmentos traseros antes de que se ejecute el shader.

Por eso casi todos los motores modernos ordenan las instancias de follaje por distancia a la cámara antes de emitir la prepasada. La ordenación es barata —unos cientos de miles de instancias en la GPU mediante una ordenación radix— y convierte la propia prepasada en una operación que se va reduciendo a sí misma. Por el mismo motivo, el descarte a nivel de clúster ordena con granularidad de meshlet. La prepasada de profundidad y la ordenación de delante hacia atrás forman una de esas parejas en las que cada técnica es buena por separado, pero la combinación es excelente.

Análisis en profundidad:

• Persson, Depth in-depth (notas arquitectónicas sobre la ordenación del búfer de profundidad, la rentabilidad de una prepasada y el comportamiento de Hi-Z).
• Giesen, A trip through the graphics pipeline (la explicación técnica detallada de cómo depende la tasa de rechazo de Hi-Z del orden de dibujado).
• Wihlidal, Optimizing the Graphics Pipeline with Compute (GDC 2016, incluye la ordenación de instancias en la GPU de Frostbite).

6. Transiciones de LOD con tramado y alfa con hash

La otra gran trampa son los fundidos. La forma ingenua de realizar la transición entre dos LOD —o de hacer aparecer o desaparecer gradualmente una instancia a medida que se acerca la cámara— es la mezcla alfa. Pero la geometría mezclada no puede escribir en el búfer de profundidad, lo que envía cada árbol en transición a la lenta ruta de translúcidos y rompe la prepasada. La solución es mantener la geometría en la ruta enmascarada y realizar el fundido dentro de la prueba alfa.

Dos técnicas principales:

• Las transiciones de LOD con tramado muestrean un patrón de Bayer de 4x4 u 8x8 —o una textura de ruido azul en el espacio de pantalla— y lo usan como modificador del umbral por píxel. En un árbol con una mezcla del 50 %, sobrevive un patrón ajedrezado de píxeles; los píxeles ausentes los rellena el patrón complementario del siguiente LOD. El TAA convierte el patrón en una transición suave a lo largo de dos o tres fotogramas. Es barato, estable y se integra con todo lo demás en el motor.
• La prueba alfa con hash (Wyman y McGuire, I3D 2017) sustituye el umbral alfa fijo de 0,5 por un umbral con hash por píxel en [0,1). La geometría alfa distante que normalmente desaparecería por completo —porque el alfa con mipmapping cae por debajo de 0,5— conserva una dispersión estable de píxeles supervivientes. De nuevo, el TAA se encarga de suavizar el resultado.

Ambas técnicas mantienen el follaje en la ruta opaca o enmascarada donde funciona la prepasada de profundidad, por lo que no hay que asumir el coste completo del renderizado translúcido solo para hacer aparecer algo gradualmente. Alfa a cobertura es el equivalente de la época del MSAA: convierte el alfa en una máscara de cobertura de subpíxeles y obtiene transparencia parcial sin abandonar la ruta enmascarada. El inconveniente es que A2C solo destaca de verdad con MSAA, que la mayoría de los renderizadores diferidos modernos ya no utilizan.

Análisis en profundidad:

• Wyman y McGuire, Hashed Alpha Testing (I3D 2017, el artículo canónico sobre alfa con hash).
• Castaño, Computing Alpha Mipmaps (blog de The Witness, la forma correcta de generar mipmaps para texturas con prueba alfa sin que los árboles lejanos desaparezcan).
• Yuksel, Alpha Distribution for Alpha Testing (una mejora más reciente para los mipmaps alfa).
• NVIDIA, Anti-Aliased Alpha Testing (un repaso de A2C, alfa con hash y alternativas con tramado).

7. Reducción del coste de sombreado en píxeles enmascarados

Incluso con una prepasada perfecta y un descarte perfecto, todavía hay que sombrear una vez cada píxel visible del follaje. Los motores también reducen ese coste:

• BRDF más barato. El follaje es mate y realmente no necesita una ruta especular Cook-Torrance completa. Basta con una reflexión difusa Lambertiana envuelta y una aproximación especular de una sola línea.
• Mapas de normales de menor frecuencia. Las hojas ya tienen mucho ruido visual. Un mapa de normales de 256x256 se ve igual que uno de 1024x1024 a distancias de observación habituales y ahorra ancho de banda.
• Sin paralaje, anisotropía ni capa transparente. El menú de funciones PBR se desactiva para las hojas.
• Transmisión fina de dos caras en lugar de dispersión subsuperficial completa. Las hojas transmiten la luz desde detrás, pero puede simularse con un único producto escalar de contraluz.
• Sombreado a media resolución en algunos motores. El follaje se sombrea a una tasa de 1/4 o 1/2 píxel y luego se reescala. El ruido estocástico del TAA oculta el remuestreo.
• Omitir texturas de detalle y calcomanías en materiales enmascarados de forma predeterminada.

Cada una de estas optimizaciones supone una pequeña mejora por separado. Combinadas, los shaders de follaje enmascarado pueden ejecutarse entre 2 y 3 veces más rápido que el material opaco equivalente.

Análisis en profundidad:

• Lagarde y de Rousiers, Migración de Frostbite al renderizado basado en física 3.0, secciones sobre follaje y translucidez (SIGGRAPH 2014, los ajustes PBR de referencia para materiales finos de dos caras).
• Jimenez, Renderizado de personajes de nueva generación (las matemáticas de Lambert envuelto y translucidez posterior, creadas originalmente para la piel pero adaptadas ampliamente a las hojas).
• Sanders, Entre la tecnología y el arte: la vegetación de Horizon Zero Dawn (GDC 2018, con las simplificaciones del shader de follaje de Decima).

8. Búferes de visibilidad y Nanite para materiales enmascarados

La solución más limpia al sobredibujado es desacoplar por completo el sombreado de la rasterización. Un búfer de visibilidad rasteriza la geometría en un búfer ligero (solo el ID del triángulo y el ID de la instancia por píxel) y luego ejecuta el material completo como un pase diferido que lee el búfer de visibilidad y sombrea cada píxel exactamente una vez. Por diseño, no hay sobredibujado en la etapa de sombreado. El artículo de Burns y Hunt de 2013 presentó esta técnica; Nanite de UE5 es su implementación con calidad de producción, incluso para follaje enmascarado desde UE 5.5.

La particularidad de Nanite es que lo hace con geometría virtualizada a nivel de clúster, por lo que el propio rasterizador utiliza una ruta de software para triángulos de tamaño inferior a un píxel y mantiene limitado el sobredibujado. Los materiales enmascarados de Nanite necesitan la función de «rasterización programable»: la prueba alfa se ejecuta durante el pase del búfer de visibilidad, pero el sombreado del material sigue realizándose una sola vez por píxel visible durante la resolución diferida. El resultado es que el follaje muy denso de Nanite, antes conocido por su lentitud con materiales enmascarados, ahora es competitivo con los materiales opacos o incluso más barato, porque el sobredibujado durante el sombreado es nulo. Hay una contrapartida: a menudo es mejor procesar geometría de árboles opaca y con muchos polígonos mediante Nanite que conservar árboles de pocas caras construidos con tarjetas enmascaradas, porque la ruta enmascarada añade el coste de la rasterización programable.

Análisis en profundidad:

• Burns y Hunt, El búfer de visibilidad: un enfoque de sombreado diferido eficiente para la caché (JCGT 2013, el artículo original).
• Karis, Stubbe, Wihlidal, Análisis en profundidad de la geometría virtualizada de Nanite (SIGGRAPH 2021, la arquitectura de producción).
• Epic, Materiales de Nanite controlados por la GPU (GDC 2024, con la canalización de materiales enmascarados y rasterización programable).
• Notas de «Materiales de Nanite controlados por la GPU» (una explicación clara de terceros sobre la misma charla).

9. Representaciones de sombras separadas para el follaje

Los mapas de sombras para follaje con prueba alfa son el segundo problema de sombras más costoso de cualquier fotograma de mundo abierto, después de las cascadas grandes. Cada cascada necesita su propio prepase de profundidad, cada prepase ejecuta la prueba alfa y el coste se acumula rápidamente entre 4 cascadas y decenas de frustos de luz. Por eso, la mayoría de los motores no renderizan las sombras del follaje del mismo modo que su color.

Sustituciones habituales:

• Sombras mediante campos de distancia de malla (UE Lumen, motores personalizados). Cada malla tiene un campo de distancia con signo precalculado. Un breve trazado de conos a través del SDF produce una sombra suave sin tocar nunca la malla con prueba alfa. Resulta especialmente adecuado para los árboles porque el SDF captura la silueta de la copa como una única masa sólida e ignora el detalle de cada hoja.
• Cascadas de menor resolución para el follaje. Las sombras del follaje se escriben en una sección a media resolución y se amplían mediante un filtrado sensible a los bordes. El ojo no percibe la pérdida de resolución porque las sombras ya son suaves.
• Mapas de sombras de alfa a cobertura con MSAA. En los motores que aún utilizan MSAA en su ruta de sombras, A2C produce sombras de follaje con bordes suaves sin el coste completo de la prueba alfa.
• Sombras de cápsula para el tronco y las ramas grandes, campo de distancia para la copa y prueba alfa completa solo en la cascada más cercana. Se emplean representaciones distintas para diferentes distancias y se combinan en el pase de iluminación.
• Distancia de desactivación de WPO. El desplazamiento de posición en el mundo impulsado por el viento se desactiva más allá de un umbral para que los datos de sombras almacenados en caché sigan siendo válidos entre fotogramas. Los mapas de sombras virtuales de UE dependen en gran medida de esta técnica.

Análisis en profundidad:

• Epic, Sombras suaves mediante campos de distancia en Unreal Engine (la referencia de UE para las sombras mediante campos de distancia de malla).
• Wright, Lumen: iluminación global en tiempo real en Unreal Engine 5 (SIGGRAPH 2022, con la integración de los SDF de malla de Lumen para el follaje).
• Epic, Mapas de sombras virtuales (la arquitectura moderna de sombras de UE5, con las reglas específicas del follaje para desactivar WPO y gestionar la caché).
• Persson, Mapas de sombras en cascada prácticos (la referencia aún vigente sobre CSM, con notas acerca de los emisores de sombras con prueba alfa).

10. Viento, animación y caché de sombras

Un problema relacionado y sutil: la mayor parte del follaje se mueve. La animación de vértices impulsada por el viento (World Position Offset en UE y sus equivalentes en Frostbite y Decima) hace que la geometría del follaje no sea estable entre fotogramas, lo cual rompe la caché de sombras y la reproyección. Los motores modernos combaten esto de dos formas:

• Limitar WPO a cierta distancia. Más allá de un umbral, la amplitud de la animación del viento se reduce gradualmente hasta cero. De todos modos, el ojo no puede apreciar el balanceo a tanta distancia, y las cachés de sombras siguen siendo válidas.
• Incorporar el viento a los límites del clúster. Las cajas delimitadoras de los clústeres se amplían según el desplazamiento WPO máximo, de modo que el descarte siga siendo conservador sin volver a cargar datos en cada fotograma.
• Desfases por instancia. Los árboles idénticos utilizan una semilla aleatoria por instancia para desfasar la animación del viento, de modo que un bosque no se balancee al unísono sin tener que pagar una animación única para cada árbol.

Este es el tipo de detalle que no aparece en las listas de técnicas, pero que en la práctica marca la diferencia entre un bosque de 3 ms y uno de 9 ms.

Análisis en profundidad:

• Sanders, Entre la tecnología y el arte: la vegetación de Horizon Zero Dawn (GDC 2018, con la canalización de animación del viento y la caché de sombras de Decima).
• McAuley, Renderizado del mundo de Far Cry 4 (GDC 2015, incluye el muestreo de la cuadrícula de viento para la vegetación).
• Epic, Follaje y mapas de sombras virtuales (las recomendaciones de la comunidad de UE5 sobre la distancia de desactivación de WPO y la caché de VSM).

11. Las matemáticas combinadas

Ninguna de estas técnicas es una solución mágica. Lo interesante es lo que sucede al combinarlas:

• Un pase de follaje enmascarado ingenuo en una escena de bosque denso presenta un sobredibujado efectivo de entre 8 y 15 veces. Cada píxel visible ejecuta el shader de hojas entre 8 y 15 veces.
• Al añadir un prepase de profundidad, el pase principal baja a un sobredibujado de ~1x, pero el propio prepase todavía toca toda la geometría.
• Al añadir ordenación de delante hacia atrás, el prepase empieza a descartar trabajo por sí mismo.
• Al añadir descarte por GPU a nivel de clúster, el prepase solo toca lo que podría llegar a ser visible.
• Al añadir cadenas de LOD e impostores, la cantidad de cuadriláteros visibles se reduce en un orden de magnitud más allá de 30 m.
• Al añadir la ruta de búfer de visibilidad/Nanite, la etapa de sombreado se ejecuta realmente una sola vez por píxel, incluso con una superposición densa.
• Al añadir sombras mediante campos de distancia, el coste de las sombras deja de escalar con la prueba alfa.

El resultado principal, repetido en las charlas enlazadas anteriormente: el sobredibujado efectivo se desploma de 8-15x a 1-2x, y el coste total del follaje por fotograma se reduce entre 4 y 6 veces en una escena de bosque denso. Esa es la razón por la que los juegos modernos de mundo abierto pueden renderizar bosques a más de 60 fps en hardware de consumo.

12. Qué significa esto para el navegador

La mayor parte de este conjunto de técnicas se adapta limpiamente a WebGPU. Ya hemos implementado descarte controlado por la GPU, despacho indirecto, oclusión Hi-Z y prepases ordenados de delante hacia atrás en el motor de mundo abierto para navegadores. El prepase de profundidad para geometría enmascarada es sencillo: WebGPU admite pruebas de igualdad de profundidad y discard en shaders de fragmentos, con las mismas salvedades respecto a early-Z. Los impostores octaédricos se trasladan de forma mecánica; las matemáticas se reducen al desplegado de esfera a octaedro y la indexación del atlas.

Las partes más difíciles son las modernas. Un búfer de visibilidad en WebGPU implica escribir un ID de triángulo de 32 bits en un destino de renderizado y resolver los materiales en un pase de cómputo a pantalla completa; los componentes necesarios existen, pero su orquestación es compleja. Las sombras mediante campos de distancia de malla requieren una textura 3D por recurso y un trazado de conos corto, dos cosas que están al alcance de WebGPU. El alfa con hash y los LOD con tramado requieren una sola función de shader cada uno.

El camino que debe seguir el follaje en el navegador es el mismo que el del resto de este conjunto tecnológico: lanzar primero las técnicas baratas y robustas (prepase, instancias ordenadas, LOD, impostores y alfa con hash) y añadir después la maquinaria pesada (búfer de visibilidad y sombras mediante SDF de malla). El nivel mínimo del hardware para navegadores por fin es lo bastante alto como para que no haya ninguna razón arquitectónica por la que un bosque de WebGPU no pueda verse y funcionar como uno de consola. Solo quedan razones de ingeniería, y las razones de ingeniería son las que nos gustan.

Lecturas adicionales sobre todo el conjunto tecnológico

Si buscas una única fuente que reúna todo esto, el archivo «Advances in Real-Time Rendering in Games» de SIGGRAPH (advances.realtimerendering.com) contiene las charlas de referencia sobre follaje y renderizado controlado por la GPU desde 2014. Los artículos de análisis de GPU de Adrian Courrèges incluyen desgloses fotograma a fotograma de GTA V y Horizon Zero Dawn que muestran cada pase analizado aquí en su orden de producción. Para las matemáticas de la prueba alfa en particular, la página de investigación de Chris Wyman contiene los artículos sobre alfa con hash y transparencia estocástica, además de shaders de referencia. Y los capítulos de Real-Time Rendering, 4.ª edición sobre transparencia, muestreo y gestión de la profundidad siguen siendo el punto de partida académico.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 24 hizo que el mundo fuera persistente y dio viento a su vegetación. Esta parte vuelve a tratar sobre las personas que lo habitan, pero desde el lado del vestuario: ¿puede un creador elegir un cuerpo base, cambiar la ropa, escoger un peinado y reproducir cualquier animación, todo con un paquete de recursos gratuito, sin rigging ni creación de animaciones? Crear un rig personalizado no es lo que conviene validar para reducir riesgos. La pregunta que merece respuesta es si un paquete CC0 puede soportar toda la carga.

Un paquete creado para encajar

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

Quaternius ofrece cuatro recursos que encajan de una forma casi sospechosamente perfecta: Universal Base Characters, con cuerpos masculinos y femeninos, además de ocho peinados y dos conjuntos de cejas; Modular Character Outfits, dividido en piezas para cuerpo, brazos, piernas y pies, con accesorios como hombreras y una capucha; y los paquetes uno y dos de Universal Animation Library, con un total de 262 clips que abarcan locomoción, combate, escalada, agricultura, pesca, poses inactivas y movimientos sociales. Al inspeccionar sus glTF se reveló por qué encajan: absolutamente todas las mallas de los cuatro paquetes están vinculadas al mismo esqueleto de estilo UE5 con 65 articulaciones, con los mismos nombres de articulaciones y las mismas poses de enlace, desde la raíz, pasando por la pelvis y la columna, hasta la cabeza, con brazos simétricos que incluyen quince articulaciones de dedos por lado y piernas simétricas. No hace falta retargeting. Esto es exactamente lo contrario del problema de retargeting entre tres esqueletos del Spike 35, donde un rig facial de 213 huesos tenía que comunicarse con un rig de Mixamo de 65 huesos. Aquí, los cuatro paquetes se crearon deliberadamente sobre el esqueleto de la biblioteca de animaciones, y la correspondencia es exacta.

Eso convirtió el spike en un ejercicio de vinculación en lugar de un problema de canalización de animaciones. La capa base carga el glTF de un cuerpo, clona la escena con SkeletonUtils.clone para que cada personaje obtenga una instancia nueva del esqueleto en vez de devolver las mutaciones de los huesos a la escena almacenada en caché por el cargador, y guarda en caché ese esqueleto de 65 huesos como referencia canónica junto con el objeto de armadura que sirve de raíz para la animación.

Revincular un abrigo a un cuerpo

El truco que hace funcionar todo esto es que no se puede simplemente cambiar la malla de un atuendo de padre dentro de la escena, porque sigue haciendo referencia a los huesos de su propio glTF, que se encuentran en un subárbol diferente. Cada pieza modular —el cuerpo de un campesino o las piernas de un explorador— llega como su propio SkinnedMesh con su propio clon de la misma armadura. La vinculación recorre los huesos del esqueleto de origen en su orden original, busca cada uno por nombre en el esqueleto canónico y crea un nuevo Skeleton a partir de esos huesos revinculados, reutilizando las matrices inversas de enlace del origen; después llama a SkinnedMesh.bind con la matriz de enlace identidad del origen. Tras la vinculación, la malla se separa de su escena de origen y pasa a depender directamente de la raíz del personaje. Como la matriz de enlace captura la transformación global en el momento de la vinculación y la raíz se encuentra en identidad, la transformación global de la propia malla nunca afecta al resultado y el skinning se realiza por completo a través de los huesos ahora compartidos.

El pelo y las cejas también son ranuras, y permitieron corregir una suposición errónea. La estructura de carpetas decía «vinculado al hueso de la cabeza», lo que sugería que el pelo sería una malla estática dependiente de la cabeza con un desplazamiento predefinido. No es así. Cada archivo de pelo es un SkinnedMesh ponderado entre las 65 articulaciones, y los pesos del pelo largo se extienden hasta la parte superior de la columna y el cuello para que caiga de forma natural cuando el personaje mira hacia abajo. Por tanto, el pelo sigue la misma ruta de revinculación por nombre que cualquier pieza de atuendo. El único caso especial es la ranura del cuerpo del atuendo: cuando se adjunta, la malla del cuerpo base se oculta para que no atraviese el atuendo, mientras que los brazos, las piernas, los pies y los accesorios simplemente se superponen, porque el paquete se diseñó para que coexistieran con el cuerpo base visible allí donde la ropa deja piel al descubierto.

262 animaciones gratuitas

La animación resulta casi trivial una vez que se comparte el esqueleto. Se cargan los dos glb de las bibliotecas, sus clips se combinan en una única lista con nombres y las pistas de esos clips hacen referencia a los nombres exactos de las articulaciones mediante bone.position, bone.quaternion y bone.scale. Un AnimationMixer cuya raíz es la armadura del personaje encuentra esos huesos por nombre y los controla directamente, aplicando una transición fundida al cambiar. El panel derecho del visor contiene una lista filtrable con los 262 clips y una etiqueta de origen, de modo que buscar «fish» muestra todas las animaciones de pesca de ambas bibliotecas. Una iluminación estándar de tres puntos con sombras suaves, una cuadrícula polar bajo los pies y el mapeo tonal ACES mantienen legibles las texturas base estilizadas sin empastar las sombras del traje oscuro.

La reducción de riesgos para el producto es considerable. La función de personalización de avatares puede publicarse con un paquete CC0 sin ningún trabajo de rigging ni creación de animaciones: basta con incorporar los cuatro paquetes y conectar una interfaz de vestuario para obtener, desde el primer momento, aproximadamente seis atuendos por ocho peinados, por dos sexos y por 262 animaciones de variación. El esqueleto de 65 articulaciones es lo bastante pequeño como para que el coste del skinning en la GPU sea insignificante, y el trabajo de skinning por lotes del Spike 45 ya permite manejar más de 200 avatares con un rig de este tamaño. CC0 no impone restricciones de uso, por lo que puede utilizarse comercialmente en una plataforma de pago para creadores. La pregunta pendiente son los atuendos personalizados que suban los usuarios, un problema de la fase 3 que se resolverá aplicando retargeting en el momento de la subida hacia este esqueleto canónico, a la inversa del retargeting en tiempo de ejecución del Spike 35. Los recursos ocupan alrededor de 147 MB en disco como archivos PNG 2K sin procesar y glb de animación sin comprimir, una cifra que en producción se reduciría a unos 30 MB mediante compresión de texturas KTX2 y una pasada con gltf-transform.

Tecnología mencionada en este capítulo

Un único esqueleto canónico para todo el paquete. Los cuatro paquetes de Quaternius —cuerpos base, atuendos modulares y dos bibliotecas de animaciones— están vinculados a un esqueleto idéntico de estilo UE5 con 65 articulaciones, los mismos nombres de articulaciones y las mismas poses de enlace, por lo que combinarlos no requiere retargeting. Clonar la base con SkeletonUtils.clone proporciona a cada personaje una instancia nueva del esqueleto en lugar de mutar la escena almacenada en caché por el cargador.

Revinculación del esqueleto por nombre. Cada pieza modular incluye su propio SkinnedMesh, que hace referencia a su propia armadura. La revinculación recorre los huesos de origen en orden, asigna cada uno por nombre al esqueleto canónico, crea un nuevo Skeleton reutilizando las matrices inversas de enlace del origen y llama a SkinnedMesh.bind con la matriz de enlace identidad. Después, hace que la malla dependa de la raíz compartida del personaje para que el skinning se ejecute por completo a través de los huesos compartidos. La ranura del cuerpo del atuendo oculta el cuerpo base para evitar intersecciones; las demás ranuras se superponen.

El pelo como ranura con skinning. El pelo no es un elemento estático adjunto al hueso de la cabeza, sino un SkinnedMesh ponderado entre las 65 articulaciones. El pelo largo tiene pesos asignados a la parte superior de la columna y al cuello para que caiga de forma natural cuando el personaje mira hacia abajo. Sigue la misma ruta de revinculación que las piezas de los atuendos.

Retargeting gratuito de animaciones basado en nombres. Los clips de Animation Library hacen referencia a las articulaciones por su nombre exacto, por lo que un AnimationMixer cuya raíz es la armadura compartida controla directamente los 262 clips con transición fundida, sin retargeting individual por clip. La licencia CC0 permite el uso comercial, y el reducido número de articulaciones mantiene el skinning en la GPU lo bastante barato como para reutilizar la ruta de skinning por lotes del Spike 45. Consulta LOD controlado por la GPU.

Parte 25 de 29. Anterior: Parte 24 - Guardar un mundo y hacer visible el viento Siguiente: Parte 26 - Agua que funciona a cualquier escala Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 23 puso personas en el mundo y les dio voz. Esta parte trata de conseguir que el mundo recuerde lo que hicieron en él y que parezca vivo cuando nadie lo toca. El Spike 47 se centra en la persistencia: un creador esculpe el terreno y coloca elementos, y esas ediciones sobreviven a una recarga, se sincronizan con todos los demás pares y se arbitran de forma limpia cuando dos personas editan a la vez. El Spike 49 se centra en el viento: trasladar los shaders de vegetación de un paquete de naturaleza estilizada para que los árboles, arbustos y la hierba se muevan como pretendía el artista, lo que terminó convirtiéndose más en una lucha con el compilador de shaders que con las matemáticas.

Un mundo que recuerda

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

El escenario es una sesión de creación compartida. Los jugadores recorren un mundo, colocan elementos con un clic, los eliminan con un clic derecho y esculpen el suelo arrastrando un pincel, elevando y reduciendo el mapa de alturas o excavando cuevas volumétricas en el terreno SDF, lo que hace que un chunk pase a usar marching cubes. Todo lo que hacen persiste en un WorldChunkDO de Cloudflare, un Durable Object con autoridad del servidor respaldado por su propio almacenamiento SQLite. Los clientes no escriben el estado directamente. Envían su intención, el DO arbitra y difunde el resultado, y el DO es la única fuente de verdad, por lo que quien acaba de unirse recibe una instantánea y aparece exactamente en el mismo mundo que ven los demás.

Dos detalles de la persistencia demostraron su valor. El terreno no se almacena como un registro de eventos que haya que reproducir al unirse; se guarda como blobs binarios por chunk que constituyen la fuente de verdad y se suben al finalizar cada trazo, de modo que quien se une carga directamente los bytes confirmados en lugar de volver a ejecutar miles de muestras del pincel. Además, esos blobs usan una clave de almacenamiento por chunk en lugar de una única fila grande, porque un solo chunk SDF ocupa 168 KB y el DO tiene un límite de 2 MB por fila. Un índice de chunks registra qué claves existen para que el DO pueda rehidratar el mapa completo al reactivarse. La identidad se gestiona mediante dos almacenamientos en el cliente: el id del jugador se guarda en sessionStorage, por lo que dos pestañas son dos pares distintos en lugar de un mismo par que se sobrescribe a sí mismo en el mapa de jugadores del DO, mientras que el nombre visible se guarda en localStorage, de modo que un cambio de nombre en una pestaña se propaga a todas las demás.

Hacer converger las ediciones simultáneas

La parte realmente difícil de la creación multijugador es qué ocurre cuando dos personas editan una zona de terreno superpuesta en el mismo instante. El spike divide las ediciones según su álgebra. Las operaciones aditivas —elevar y bajar en el mapa de alturas, y sumar y restar en el SDF— son conmutativas: aplicarlas en cualquier orden produce el mismo resultado, por lo que siguen una ruta optimista basada en sellos donde cada cliente aplica localmente el cambio y envía el sello, y el DO lo difunde a todos sin coordinación. El orden realmente no importa, así que no hay nada que coordinar.

Las operaciones dependientes del orden, suavizar y aplanar, fueron el caso interesante. El primer diseño les asignaba un bloqueo de región: un cliente solicita un bloqueo al pulsar el puntero, el DO lo concede o lo deniega, el cliente almacena temporalmente las muestras mientras se mantiene la pulsación y, al soltar el puntero, el DO aplica todo el trazo de forma atómica. Funciona, pero es un protocolo independiente, con su propio TTL de bloqueo y su viaje de ida y vuelta para concederlo o denegarlo. La solución más limpia que lo sustituyó es un delta precalculado: el cliente de origen ejecuta localmente el pincel de suavizado o aplanado, después envía la lista resultante de deltas por celda y cada par se limita a sumar esos deltas a sus propias celdas sin volver a derivar nada. Esto convierte una operación dependiente del orden en una operación conmutativa al fijar su resultado en el origen, por lo que todo el sistema de edición funciona con un único protocolo conmutativo uniforme, con una convergencia idéntica y sin ningún bloqueo. Los bloqueos de elementos se mantienen por un motivo distinto: el bloqueo por registro sustituyó a la eliminación exclusiva del propietario, de modo que cualquier par puede eliminar cualquier elemento salvo que alguien lo haya bloqueado, y solo quien lo bloqueó puede desbloquearlo. Deshacer y rehacer funcionan permitiendo que el cliente asigne un id al elemento antes de colocarlo, de modo que conoce el id antes de recibir el eco del servidor y puede revertir sus propias acciones de forma determinista. Los WebSockets en hibernación mantienen gratuita una sala inactiva en todo momento, la misma propiedad que abarató el relé de avatares de la parte anterior.

Un viento trasladado fielmente y luego combatido

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

El Spike 49 toma el Stylized Nature MegaKit de Quaternius y traslada su viento a nuestra pila tecnológica. El paquete incluye sus shaders originales de Godot, cuatro en total, y lo acertado era traducirlos fielmente en lugar de reinventarlos. La corteza tiene una función de vértices vacía, así que los troncos son rígidos; un intento anterior basado en una máscara procedural hacía que los troncos se balancearan, y la solución fue simplemente dejar de aplicar viento a la corteza. Las hojas reciben un balanceo caótico por vértice a partir de un hash de pulsos triangulares, enmascarado según la altura para que las copas se muevan mientras la base permanece plantada. El follaje básico recibe en el espacio del mundo un balanceo seno/coseno modulado por ruido. La hierba es follaje básico más una oscilación de líneas de viento que muestrea una textura de ruido en desplazamiento mediante una curva de potencia, de modo que solo contribuyen las bandas claras de la textura, lo que produce las ondas visibles que recorren una pradera. La selección sigue la propia convención de nombres de materiales del paquete, por lo que un material llamado Leaves_Birch se dirige a la ruta de hojas y Grass_Common a la ruta de hierba, sin conjeturas.

Una sorpresa del traslado es que el color de las hojas no está en la textura. Quaternius define por completo el aspecto de las hojas mediante un degradado vertical y un borde Fresnel: el albedo es una mezcla desde un color adicional en la parte inferior de la copa hasta el color de la hoja en la parte superior, determinada por la altura, con un tinte de dispersión subsuperficial añadido como emisión escalada mediante un término Fresnel $(1-\mathbf{N}\cdot \mathbf{V}{)}^3$. Por eso una pasada sencilla con textura se veía plana. Los colores proceden del degradado y del borde, no del mapa pintado. El port lee un atributo de vértice heightFactor precalculado en lugar de la Y local sin procesar, normalizado por grupo de hojas durante la carga a partir de la Y en el espacio del mundo, para que tanto el degradado como la máscara de viento se comporten correctamente sin importar cómo haya rotado la importación FBX los ejes locales de cada malla. Las constantes de color de Godot están etiquetadas como sRGB y se convierten a lineal antes de llegar al shader, así que el port realiza la misma conversión en lugar de introducir los valores sRGB brillantes como si fueran lineales y desteñir el follaje.

La recompilación que devoró la tasa de fotogramas

El motivo por el que esto se publicó primero con una base FBX, dejando a un lado el conjunto completo de materiales de viento en un archivo .bak, es un error de recompilación por fotograma que reducía la escena a aproximadamente 1 fps. Superponer TSL personalizado sobre materiales cargados desde FBX hacía que Three.js reconstruyera los programas de shaders en cada fotograma, con needsUpdate prácticamente atascado en el estado activo. El método de diagnóstico consistió en reducir cada material de follaje a una pasada sencilla con textura, sin nodos personalizados, y observar si el bucle de recompilación persistía. Si se detenía, el culpable era el grafo personalizado; si continuaba, la causa estaba en una fase anterior, en la configuración de materiales FBX o en el propio Three.js. La solución que permitió recuperar los shaders reales fue vincular como uniforms todas las diferencias entre materiales —color de las hojas, color SSS, intensidad y mezcla— para que todos los recursos de hojas compartieran un único programa compilado, en lugar de que el compilador emitiera un shader nuevo para cada combinación de colores única y saturara la cola de compilación.

Merece la pena conservar otros dos elementos. La hierba se renderiza como un InstancedMesh por archivo de origen, y su viento se calcula en el espacio del mundo porque las fases sinusoidales dependen de la posición global. Sin embargo, el desplazamiento debe aplicarse en el espacio local antes de que se ejecute la matriz de instancia, y WGSL no dispone de inverse(). Para una matriz de instancia compuesta por una traslación, una rotación Y y una escala uniforme, la inversa del bloque superior de 3×3 es simplemente su transpuesta dividida por la escala al cuadrado, por lo que el shader multiplica el desplazamiento global por la matriz de modelo transpuesta y lo divide por el cuadrado de la longitud de la primera columna de la matriz, recuperando la escala sin una raíz cuadrada. Cuando la transformación de vértices vuelve a aplicar la matriz, el movimiento termina en el espacio del mundo exactamente como se diseñó, con independencia de la rotación o escala de cada mata. Además, cada mata realiza un descarte de frustum por vértice en la GPU: proyecta el centro de la instancia al espacio de recorte y, si queda fuera del frustum con un margen, colapsa todos los vértices en el origen local para que los tres vértices de cada triángulo coincidan; el rasterizador descarta el triángulo degenerado y no se realiza ningún trabajo de fragmentos, prueba alfa ni sombras para la hierba fuera de pantalla. Esto se suma al descarte aproximado por esfera envolvente de chunk que Three.js ya realiza, construido con step de tipo float en lugar de booleanos para que pueda multiplicarse directamente en la mezcla de posiciones.

Tecnología mencionada en este capítulo

Persistencia del mundo con autoridad del servidor. Un Durable Object WorldChunkDO arbitra la colocación de elementos y las ediciones del terreno, conserva blobs binarios por chunk como fuente de verdad —para que quienes se unen carguen los bytes confirmados en lugar de reproducir un registro de eventos— y almacena una clave por chunk para mantenerse por debajo del límite de 2 MB por fila del DO. El id del jugador se guarda en sessionStorage para que las pestañas sean pares distintos; el nombre visible se guarda en localStorage para que los cambios de nombre se propaguen entre pestañas.

Convergencia conmutativa de las ediciones. Las operaciones aditivas sobre el terreno —elevar/bajar y sumar/restar en el SDF— son conmutativas y siguen una ruta optimista basada en sellos sin coordinación. Las operaciones dependientes del orden —suavizar y aplanar— se vuelven conmutativas enviando deltas precalculados por celda en lugar de adquirir un bloqueo de región, por lo que todo el sistema converge mediante un único protocolo uniforme sin bloqueos. Los bloqueos de elementos por registro sustituyen a la eliminación exclusiva del propietario, y los ids de objetos asignados por el cliente permiten deshacer y rehacer de forma determinista antes de que llegue el eco del servidor. Consulta LOD controlado por GPU.

Traslado fiel de shaders de Godot a TSL. Los cuatro shaders de viento originales de Quaternius se traducen línea por línea: corteza rígida, balanceo de hojas enmascarado por altura, balanceo del follaje en el espacio del mundo y hierba con una oscilación de líneas de viento en desplazamiento, seleccionados mediante la convención de nombres de materiales del paquete. El color de las hojas procede de un degradado de altura más un borde SSS controlado por Fresnel, en lugar de la textura, y las constantes creadas en sRGB se convierten a lineal para que el aspecto coincida con los renders de referencia.

Evitar recompilaciones de shaders por fotograma. Superponer TSL personalizado sobre materiales FBX puede dejar needsUpdate activado y reconstruir los programas en cada fotograma, reduciendo el rendimiento a unos 1 fps. Vincular como uniform todas las diferencias entre materiales permite que todas las variantes compartan un único programa compilado, en lugar de emitir un shader nuevo por cada conjunto único de parámetros. Una pasada de diagnóstico sencilla con textura permite aislar si la causa es el grafo personalizado o la configuración anterior.

Viento en el espacio del mundo para follaje instanciado. El viento de la hierba se calcula en el espacio del mundo y se transforma de vuelta al espacio local mediante una inversa derivada manualmente —transpuesta dividida por la escala al cuadrado— porque WGSL no dispone de inverse(). Un descarte de frustum por vértice en la GPU colapsa las matas fuera de pantalla en un triángulo degenerado para evitar cualquier trabajo de fragmentos o sombras, sumándose al descarte por esfera envolvente de chunk de Three.js.

Parte 24 de 29. Anterior: Parte 23 - Cincuenta avatares y una voz en la sala Siguiente: Parte 25 - Un esqueleto, cualquier atuendo Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 22 puso un cielo sobre el mundo. Esta parte pone personas en él. Un mundo abierto en tercera persona necesita más de 50 personajes visibles en todo momento y oír a quienes están a tu lado. El spike 45 aborda el renderizado: llevar esa cantidad de avatares animados a la GPU sin colapsar el hilo principal. El spike 46 aborda el audio: voz entre pares que se panoramiza y atenúa según la posición, ajustada para sonar como una videollamada normal en lugar de como una demostración técnica.

Una llamada de dibujo para cincuenta bailarines

Abrir el spike 45 en una pestaña nueva ↗ · Ver el código fuente

La ruta predeterminada de Three.js asigna a cada personaje su propio SkinnedMesh, su propio AnimationMixer, su propia carga de matrices de huesos y su propia llamada de dibujo. Con 50 avatares en el Mac local, eso suponía unos 13 ms de sobrecarga de JavaScript puro por fotograma antes de que la GPU hiciera una sola cosa. La pregunta de reducción de riesgos para toda la línea de trabajo multijugador era si una arquitectura única de skinning por lotes podía controlar ese coste y escalar linealmente con la cantidad de personajes.

La respuesta consiste en separar dónde se calcula la animación de dónde se dibuja. Tres clases de personajes comparten una plantilla FBX. El jugador local es un Avatar normal, un clon completo del esqueleto con su propio mezclador y la ruta estándar de Three.js, porque nunca hay más de uno. Cada par remoto es un VirtualSkeleton: también un clon completo con su propio mezclador ejecutando los mismos clips, pero todos los nodos SkinnedMesh se eliminan inmediatamente después de la clonación para conservar solo los huesos. Nunca se añade a la escena. En cada fotograma, después de que el mezclador se actualice y las matrices se estabilicen, empaqueta (bone.matrixWorld × boneInverse) para los 100 huesos en una posición de un Float32Array compartido. A continuación, BatchSkinnedRenderer posee un InstancedMesh por cada pieza de geometría; todos leen de un único StorageBufferAttribute de matrices de huesos con un tamaño de maxInstances × numBones × mat4, es decir, 60 × 100 × 64 = 384 KB. Un MeshStandardNodeMaterial con positionNode y normalNode personalizados lee cuatro influencias de huesos por vértice directamente desde ese búfer de almacenamiento. El resultado es una carga al almacenamiento y una llamada de dibujo por pieza de geometría para toda la multitud, independientemente de cuántas personas haya. El skinning se ejecuta en el shader de vértices y el coste de JavaScript por avatar se reduce a ejecutar un mezclador y copiar 100 matrices.

El HUD que mide esto también tuvo que rehacerse. La versión anterior marcaba «presupuesto excedido» cuando el tiempo total de GPU del fotograma superaba los 3 ms, pero el fotograma siempre incluye el mapa de sombras, el suelo y la malla completa con skinning del jugador local, que juntos consumen entre 3 y 5 ms en hardware real sin importar cuántos pares sintéticos existan. La solución es un presupuesto que se calibra por sí solo: mientras no haya avatares procesados por lotes, captura el tiempo de GPU en vivo como referencia mediante una EMA rápida; después congela esa referencia y aumenta el presupuesto linealmente en 0,06 ms por cada avatar añadido cuando aparecen los sintéticos. En reposo muestra PASS en todas las máquinas y se ajusta proporcionalmente a medida que crece la multitud.

El fallo era una cara que no podías ver

Las primeras ejecuciones en Chrome mostraron sombras plateadas sobre el suelo y ningún avatar, junto con un error de análisis de WGSL: cannot index type 'f32' en una línea que intentaba indexar object.nodeUniform2[i] cuando el uniforme estaba declarado como un escalar. La parte sincera de esta historia es que la primera solución era incorrecta y aun así funcionó. La suposición fue que la ruta de matrices de instancias de InstancedMesh estaba generando el código erróneo, y sustituirla por un StorageInstancedBufferAttribute hizo que el error desapareciera en Chrome. Pero desapareció porque la nueva ruta emitía un código de shader diferente, no porque solucionara la causa, que es el tipo de arreglo más peligroso.

El verdadero culpable eran los morph targets. 3MIKE.fbx incluye expresiones faciales mediante blend shapes, la geometría clonada hereda los morphAttributes y MorphNode.setup() de Three.js declara morphTargetInfluences como un float escalar y después intenta aplicarle .element(i) dentro de un bucle sintetizado, que es exactamente la indexación de un escalar que el compilador rechazó. La solución es una sola línea: borrar geometry.morphAttributes = {} en la geometría que no utiliza morphs, para que Three.js nunca inyecte el MorphNode. La solución accidental para Chrome se mantuvo durante un tiempo y después se volvió en contra: en Safari, la ruta de instancias en almacenamiento produjo Vertex buffer is not big enough 256 veces, porque el backend WebGPU de Safari no la traduce correctamente. Revertirla fue la decisión adecuada, y el búfer de almacenamiento simple de matrices de huesos, que forma parte del núcleo de WebGPU en vez de ser una ruta de instancias generada, funciona bien en todas partes. La lección que merece conservarse es esta: cuando una solución funciona en un navegador y no puedes explicar el mecanismo, has parcheado un síntoma, así que lee el WGSL generado. Un shim de getCompilationInfo() añadido más adelante en el spike convirtió el genérico «module is not valid» de Three.js en el error real de Tint y amortizó con creces el tiempo invertido.

Junto a esto hay otro truco para esquivar el framework. Three.js detecta los nombres estándar de atributos skinIndex y skinWeight e intenta inyectar su propio SkinningNode, incluso en un InstancedMesh cuyo positionNode personalizado ya realiza el skinning. Renombrar esos atributos como boneIndex y boneWeight los oculta al framework, y el TSL personalizado los lee con sus nuevos nombres.

Un relé que te olvida entre palabras

La primera versión sincronizaba los pares mediante BroadcastChannel, un sustituto dentro del mismo navegador con el formato y la cadencia reales de la comunicación, y el comentario del protocolo prometía que cambiarlo por un transporte real requeriría una sola línea. Cumplir esa promesa dio lugar a AvatarRoomDO, un Durable Object de Cloudflare de 74 líneas que ni siquiera decodifica la trama binaria de 36 bytes. Reenvía cada mensaje tal cual a todos los demás pares de la sala, porque el id del remitente está integrado en la trama y cada receptor filtra su propio eco en el cliente. El relé no sabe nada sobre identidades. Los WebSockets en hibernación hacen que una sala inactiva sea gratuita: el DO desaparece de la memoria entre mensajes y el entorno de ejecución restaura los sockets etiquetados cuando llega el siguiente paquete. Con 10 eventos por segundo y por par, eso supone 36 000 solicitudes al DO por hora de conexión de cada par, aproximadamente medio centavo, con salida de datos gratuita en Cloudflare y un coste entre 6 y 10 veces menor que una configuración WebSocket equivalente en AWS.

El cambio sacó a la luz un fallo de la máquina de estados que merece recordarse. Un jugador remoto seguía caminando después de haberse detenido. La solicitud de animación comprobaba this._state, el clip que se estaba reproduciendo, en lugar del último nombre puesto en cola. Por eso, cuando dos mensajes de red llegaban en el mismo tick, primero walk y después idle, idle se comparaba con un estado que todavía no había avanzado y se descartaba silenciosamente. El par quedaba caminando para siempre, porque los futuros paquetes idle se eliminaban antes por deduplicación al no haber cambiado. La solución es sobrescribir siempre el nombre pendiente y dejar que el asistente de transición descarte las solicitudes genuinas del mismo estado, algo que ya hacía. Esta clase de fallo es general: una comprobación de deduplicación contra el valor de referencia equivocado se traga silenciosamente la entrada que importa.

Safari necesitó dos protecciones adicionales. Abre el WebSocket más rápido que Chrome, por lo que el primer mensaje entrante de un par podía llegar antes de que terminara de construirse el renderizador por lotes y desreferenciar un valor nulo; descartar mensajes mientras no exista el renderizador es seguro porque los pares vuelven a emitir cada 100 ms. Además, 'gpu' in navigator devolvía true mientras requestAdapter() devolvía null, de modo que Three.js recurría silenciosamente a WebGL2, donde la cadena de skinning mediante búfer de almacenamiento no tiene una traducción válida y generaba errores sin parar. Comprobar que existe un adaptador real y verificar que el backend sea efectivamente WebGPU convierte un renderizado degradado en un mensaje claro en la pantalla de carga. Incluso había una diferencia de dialecto WGSL: Three.js emite la forma moderna de dos argumentos @interpolate(flat, either), que el compilador de WebKit aún no admite. Se solucionó reescribiendo el código fuente del shader al entrar en createShaderModule para eliminar el segundo argumento, lo cual no tiene coste porque la interpolación plana transporta el mismo valor en cada vértice independientemente de él.

Una voz que se panoramiza con la sala

Abrir el spike 46 en una pestaña nueva ↗ · Ver el código fuente

El spike 46 implementa voz de proximidad: WebRTC entre pares con audio espacial HRTF, cuyo alcance se definió expresamente para igualar la calidad de Google Meet y Microsoft Teams en una sala silenciosa o moderadamente ruidosa. Un VoiceRoomDO gestiona la señalización como un relé JSON: envía a cada par nuevo una lista de participantes, anuncia entradas y salidas, enruta SDP e ICE a un par específico mediante la etiqueta del socket y difunde actualizaciones de posición que controlan los panoramizadores espaciales. Añade el id del remitente a cada mensaje para que los pares no puedan suplantarse entre sí, y el audio nunca pasa por el DO. Hay una RTCPeerConnection por cada par remoto, y el id de par lexicográficamente menor siempre crea la oferta para que ambos lados coincidan en quién inicia la conexión sin tener que implementar por completo el patrón de negociación perfecta.

En el lado receptor, el audio de cada par pasa por un PannerNode configurado como HRTF con atenuación de distancia inversa, y el AudioListener se actualiza en cada fotograma a partir de la posición y la orientación del jugador local mediante forwardX = sin(facing), forwardZ = cos(facing), lo que coincide con la convención de orientación atan2(wx, wz) de la escena. Una peculiaridad de Chrome costó una hora: un MediaStream consumido únicamente por Web Audio a veces no recibe paquetes, por lo que cada flujo también se conecta a un elemento <audio> oculto y silenciado para obligar al decodificador a programar el procesamiento. En cuanto a la calidad, los navegadores usan de forma predeterminada Opus mono a unos 32 kbps, así que el spike modifica la línea fmtp de cada oferta y respuesta para elevarla a 128 kbps, con FEC en banda activado y DTX desactivado, y después llama a setParameters con una tasa de bits máxima elevada para garantizar que el codificador utilice realmente lo que anuncia el SDP. FEC es la segunda mejora audible más importante después del aumento de la tasa de bits, ya que permite recuperarse de la pérdida de paquetes sin renegociar.

Eliminar hasta conseguir un audio limpio

La cadena de audio publicada es mucho más pequeña que aquella con la que empecé, y reducirla fue la verdadera lección. La primera versión tenía un filtro de paso alto, un limitador de chasquidos ajustado para capturar el ruido del teclado, un compresor, una puerta de ruido y una mezcla con fundido entre señal procesada y seca, todo ello controlado desde un panel flotante con más de doce deslizadores. Cuando el usuario informó de que se oían las pulsaciones del teclado, el primer impulso fue ajustar el limitador de forma más agresiva y reducir la mezcla seca: una pila de parches. La respuesta estructural era que, una vez que hay un eliminador de ruido basado en aprendizaje automático en la cadena, el limitador de chasquidos, la puerta y la mayor parte del filtro de paso alto resultan redundantes, porque RNNoise está entrenado precisamente con ruido de teclado, ratón y escritura, y el recorte de amplitud es una versión claramente peor de la misma tarea. Los clientes de producción incluyen eliminación de ruido mediante aprendizaje automático, cancelación de eco, ganancia automática y un compresor suave para nivelar, y nada más. Así que se eliminaron cuatro etapas, el panel de deslizadores y los controles para «elegir la reducción de ruido», dejando una única cadena fija.

Cada etapa que sobrevivió justifica su presencia. La cancelación de eco del navegador se mantiene porque RNNoise no elimina el eco, y sin ella la realimentación del altavoz al micrófono no tiene límite. La supresión de ruido del navegador se desactiva porque combinarla con RNNoise produce artefactos en las fricativas, así que hay que elegir un solo eliminador de ruido. La ganancia automática del navegador se mantiene porque desactivarla hacía que la señal fuera demasiado baja para que el compresor pudiera trabajar, y el DynamicsCompressorNode de Web Audio no tiene ningún parámetro de ganancia de compensación; la nivelación amplia del navegador y el compresor rápido del spike operan en escalas temporales diferentes y pueden coexistir. RNNoise funciona con un 92 por ciento de señal procesada mezclada con un 8 por ciento de señal seca, porque puede suprimir en exceso consonantes sordas como s, sh y f cuando disminuye su probabilidad de voz, y la pequeña ruta seca las conserva a cambio de dejar pasar ligeramente el ruido de las teclas. Dos funciones completan el sistema. Pulsar para hablar no cambia track.enabled, porque eso descarta todo lo que aún queda en los búferes de la canalización y corta la última sílaba al soltar la tecla. En su lugar, un GainNode situado cerca del final aplica una rampa con setTargetAtTime: un ataque rápido para conservar la primera sílaba y una liberación lenta para dejar salir la última consonante, mientras la pista permanece habilitada en todo momento. Además, un retardo de emisión de cinco segundos, solicitado como función al estilo de la radio, utiliza una ruta de derivación y otra con un DelayNode, mezcladas mediante fundido cruzado, junto con un botón de corte que silencia de inmediato la salida retardada y muestra una cuenta atrás en el HUD antes de reanudar el audio. Empaquetar el eliminador de ruido fue una pequeña odisea: el worklet de RNNoise publicado utiliza importaciones con especificadores simples que ningún CDN puede resolver, así que la solución fue crear un paquete local con esbuild que produce un único archivo autocontenido de 1,9 MB, con el WASM incrustado en base64, guardado en el repositorio y referenciado mediante una URL relativa al módulo para que funcione por igual en el servidor de desarrollo, la compilación de VitePress y el dominio personalizado. Si el worklet no llega a cargarse, la cadena sigue generando audio mediante un filtro paso alto básico y un compresor, y el HUD muestra el fallo en rojo.

Tecnología mencionada en este capítulo

Skinning por lotes en la GPU para multitudes. Los avatares remotos ejecutan un VirtualSkeleton sin renderizado (un clon completo al que se le han retirado las mallas con skinning, conservando los huesos y su propio mezclador) que empaqueta bone.matrixWorld × boneInverse para cada hueso en un StorageBufferAttribute compartido. Un InstancedMesh por cada pieza geométrica lee esas matrices en un positionNode/normalNode de TSL personalizado, de modo que toda la multitud solo requiere una transferencia al almacenamiento y una llamada de dibujo por pieza, mientras que el trabajo de CPU por avatar se limita a actualizar el mezclador y copiar una matriz. Consulta LOD controlado por la GPU.

Leer el WGSL generado, no el síntoma. Un error de compilación cannot index type 'f32' se rastreó hasta el MorphNode de Three.js, que declaraba morphTargetInfluences como escalar y después intentaba indexarlo; se corrigió vaciando morphAttributes en las geometrías que no utilizan morphs. Una primera solución que solo cambiaba la ruta de shaders generada ocultó la causa y más tarde provocó fallos en Safari. Cambiar el nombre de skinIndex/skinWeight a boneIndex/boneWeight oculta los atributos frente a la inyección automática de SkinningNode de Three.js, de modo que un material de skinning personalizado controle los cálculos.

Relés de Durable Objects en hibernación. Un AvatarRoomDO exclusivamente binario reenvía tramas de 36 bytes a todos los demás pares sin decodificarlas, con la identidad del remitente incrustada en la trama y el eco propio filtrado en el cliente. Los WebSockets en hibernación hacen que una sala inactiva no tenga coste, y esta configuración cuesta aproximadamente medio centavo por hora y por par a 10 Hz, muy por debajo del precio equivalente de WebSockets gestionados. Una protección contra duplicados que comparaba con el estado de la animación en reproducción, en lugar de con el último estado puesto en cola, descartaba silenciosamente los mensajes de detención y dejaba a los jugadores remotos atrapados en un bucle de caminata.

Voz por proximidad mediante WebRTC con HRTF. Una RTCPeerConnection por cada par, con los roles de oferta y respuesta decididos según el orden de los identificadores de los pares; el audio se enruta a través de un PannerNode HRTF con un AudioListener que se actualiza en cada fotograma según la orientación del jugador, y Opus se modifica a 128 kbps con FEC integrada para mejorar la resiliencia. Un elemento <audio> oculto y silenciado obliga a Chrome a extraer paquetes de un flujo utilizado exclusivamente por Web Audio.

Ingeniería de audio sustractiva. Igualar la calidad de Meet y Teams exigió eliminar etapas, no añadirlas: eliminación de ruido mediante ML, más cancelación de eco, ganancia automática y un compresor suave, sin puerta de ruido ni limitador de clics, porque un eliminador de ruido basado en ML y entrenado con ruido de teclado vuelve redundante el recorte de amplitud. Pulsar para hablar aplica una rampa a un GainNode situado al final mediante una envolvente asimétrica, en vez de activar y desactivar la pista, para no cortar las sílabas; además, el worklet del eliminador de ruido se distribuye como un único paquete autocontenido de esbuild para evitar los problemas de resolución de importaciones con especificadores simples.

Parte 23 de 29. Anterior: Parte 22 - Nubes que puedes iluminar y un descarte que necesita datos Siguiente: Parte 24 - Guardar un mundo y un viento que puedes ver Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, director de tecnología y cofundador de Cinevva

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

La parte 21 trataba sobre una técnica de renderizado que no dio resultado. Esta parte presenta una que sí lo dio y otra que necesitó una corrección cuidadosa para funcionar. El Spike 43 es el cielo: una atmósfera basada en la física y nubes volumétricas, la base que hace que una escena parezca un lugar en vez de una demostración técnica. El Spike 44 es culling de estilo meshlet en la GPU, cuya lección fue que la prueba de oclusión solo es tan buena como los oclusores que se le proporcionan.

Un cielo creado mediante física, no con un gradiente

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

Casi todos los efectos meteorológicos cinematográficos dependen de dos componentes de infraestructura: una atmósfera basada en la física, para que el color del cielo y el del sol sigan la hora del día mediante la física en lugar de un gradiente ajustado a mano, y un volumen de nubes volumétricas, para que el cielo tenga estructura 3D en vez de un cubemap precalculado. El Spike 43 construye exactamente ese par sobre la pila existente de WebGPU y TSL, y nada más, porque una vez que ambos existen, el resto de la pila meteorológica —niebla, rayos crepusculares, superficies mojadas y nieve— se convierte en una serie de ampliaciones más pequeñas y conocidas.

La atmósfera utiliza el modelo de Hillaire de 2020, un conjunto de tablas de consulta calculadas en shaders de cómputo WGSL. Una tabla de transmitancia integra la luz solar a través del perfil de densidad de Rayleigh, Mie y ozono, y solo se recalcula cuando se mueve el sol. Una tabla de vista del cielo se vuelve a generar en cada fotograma porque es lo bastante barata como para que no merezca la pena añadir código para condicionarla, y usa una parametrización no lineal alrededor del horizonte para evitar el banding. Por ahora, la dispersión múltiple usa un ajuste analítico en lugar de la tabla correcta, y los atardeceres se ven bien, así que el atajo queda bien disimulado. Las nubes emplean un ray marching al estilo Schneider Nubis a través de una capa horizontal, con formas generadas mediante una textura Perlin-Worley de 128³ erosionada por una textura Worley de 32³. Ambas se precalculan al arrancar mediante cómputo, sin ninguna descarga de red. La iluminación utiliza extinción según la ley de Beer, una función de fase de doble lóbulo y una aproximación de polvo. El acoplamiento clave es que el color solar de las nubes muestrea la misma tabla de transmitancia en cada paso, por lo que la iluminación de las nubes sigue el atardecer sin una segunda fase de ajuste.

En un M1, todo el sistema tarda entre 1,1 y 2,0 ms con las nubes a media resolución, muy por debajo del presupuesto de 6 ms, usa unos 14 MB de memoria de la GPU y funciona a más de 100 FPS. Las dos hipótesis principales se confirmaron en la práctica. El atardecer es la toma estrella, el momento que hace que el renderizador resulte cinematográfico, y surge de la física sin ajustes específicos para cada hora del día. Y hubo un accidente afortunado: al parametrizar la capa de nubes entre los 800 m y los 4000 m, desde una cámara baja las nubes lejanas del horizonte parecen crestas montañosas oscuras, lo que proporciona relieve de fondo al mundo sin que nadie tenga que modelarlo.

Conviene conservar una nota sobre la arquitectura. La estructura natural consiste en pintar primero el cielo en la cadena de intercambio y dejar después que three.js dibuje la geometría encima con autoClear = false. Esto no funciona con el renderizador WebGPU de r184, porque la opción no controla la operación de carga del color como lo hace en WebGL, por lo que three.js sobrescribe el cielo en cada fotograma. La solución es renderizar three.js en un destino fuera de pantalla y realizar la composición final (mix(skyCloud, scene, scene.alpha), seguida de ACES y luego sRGB) en un pase propio que controle la cadena de intercambio.

Un culling que solo es tan bueno como sus oclusores

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

El Spike 44 compara el rendimiento de cuatro modos de renderizado: forward sencillo, culling de clústeres en la CPU, culling mediante cómputo en la GPU y un búfer de visibilidad con culling por oclusión Hi-Z. La ruta Hi-Z es la interesante y tenía un error discreto: su HUD indicaba que la oclusión estaba activada, pero el contador «Eliminados por Hi-Z» permanecía exactamente en el 0,0 % para siempre. El culling del frustum funcionaba, así que la fase previa del shader de culling estaba bien. La parte de oclusión no hacía nada, aunque se pagaba todo su coste.

Una prueba de oclusión Hi-Z proyecta en pantalla el cuadro delimitador de un clúster, elige un nivel mip de la pirámide de profundidad para que el rectángulo en pantalla ocupe unos 2×2 téxeles, muestrea la profundidad del oclusor más lejano dentro de ese rectángulo y descarta el clúster si su punto más cercano sigue estando más lejos que ese oclusor. La pirámide de profundidad se construye en cada fotograma inicializando el mip 0 a partir de un prepase de profundidad opaca y aplicando reducciones por máximos en los niveles sucesivos. El prepase opaco incluye deliberadamente solo oclusores sólidos —el suelo y proxies individuales para los troncos de los árboles—, porque el follaje con prueba alfa dejaría huecos que engañarían a una reducción por máximos.

El error era geométrico, no lógico. El proxy del tronco era una caja de 0,5 m por 4 m por 0,5 m. A 30 m se proyecta en unos 17 píxeles de pantalla. Sin embargo, un clúster de hierba típico situado a 50 m selecciona el mip 5, donde cada téxel abarca 32 píxeles de origen. Un tronco de 17 píxeles no cubre por completo ni un solo téxel del mip 5, así que cada téxel que toca el tronco también toca el suelo circundante. La primera reducción por máximos de 2×2 selecciona el valor de profundidad mayor, correspondiente al suelo más lejano situado detrás del tronco, y la profundidad del tronco se borra en la primera reducción. Al llegar al mip 5, la pirámide contiene la profundidad del suelo casi en todas partes, el clúster nunca está más lejos que el suelo y nunca se ocluye nada.

La solución consiste en hacer el proxy lo bastante grande como para dominar los téxeles que ocupa, dimensionándolo según la silueta del árbol y no según su madera. Un proxy de aproximadamente 2 m por 6 m por 2 m sigue siendo más pequeño que la copa real, por lo que las hojas visibles a través de los huecos nunca se eliminan en exceso, pero es lo bastante grande como para sobrevivir a la reducción por máximos hasta las distancias relevantes, y el contador de oclusión deja inmediatamente de estar a cero. La conclusión se puede generalizar como una regla para el motor de producción: todo aquello en lo que se confíe como oclusor Hi-Z debe dimensionarse de acuerdo con su silueta en pantalla, porque la eficacia de Hi-Z en escenas abiertas con follaje depende de la cobertura del oclusor en el mip correspondiente, no de la elegancia de las matemáticas de la prueba de profundidad. La oclusión de hierba contra hierba tampoco puede activarse, porque una brizna se encuentra a la misma profundidad que el suelo bajo ella, así que las mejoras reales proceden de los árboles que ocluyen follaje lejano y de los árboles que ocluyen otros árboles.

Tecnología mencionada en este capítulo

LUT de atmósfera de Hillaire 2020. Una tabla de transmitancia —la luz solar a través del perfil de Rayleigh, Mie y ozono— que solo se recalcula cuando se mueve el sol, junto con una tabla de vista del cielo por fotograma con parametrización no lineal del horizonte, proporciona colores del cielo y del sol basados en la física que siguen la hora del día sin ningún gradiente ajustado a mano. Un ajuste analítico para la dispersión múltiple sustituye a la tabla completa hasta que algún artefacto obligue a calcularla correctamente. El atardecer surge de la física sin ajustes específicos para cada hora del día.

Nubes volumétricas Schneider Nubis. Un ray marching a través de una capa horizontal, modelada mediante una textura Perlin-Worley de 128³ precalculada al arrancar y erosionada por una textura Worley de 32³, con iluminación basada en la extinción de la ley de Beer, una fase de doble lóbulo y un término de polvo. Muestrear en cada paso el color solar de las nubes a partir de la misma tabla de transmitancia hace que su iluminación siga el amanecer y el atardecer sin coste adicional. El ray marching a media resolución cuesta aproximadamente cuatro veces menos que a resolución completa, sin una pérdida visible de calidad a distancias habituales: el compromiso estándar en producción.

Composición de WebGPU sin procesar con three.js en r184. Pintar el cielo en la cadena de intercambio y dibujar encima la geometría de three.js con autoClear = false falla porque la opción no controla la operación de carga del color en el backend WebGPU. Hay que renderizar three.js en un destino RGBA16F fuera de pantalla y efectuar el mix final, el mapeo de tonos y la conversión a sRGB en un pase que controle la cadena de intercambio.

Culling por oclusión Hi-Z y dimensionamiento de oclusores. Una pirámide de profundidad construida mediante reducciones por máximos permite que un pase de culling en la GPU descarte los clústeres cuyo punto más cercano está detrás del oclusor más lejano de su rectángulo en pantalla. La prueba no hace nada, sin avisar, si los oclusores son demasiado pequeños para dominar un téxel en el mip seleccionado, porque la primera reducción por máximos sustituye la profundidad del oclusor por la del fondo más lejano situado detrás. Los oclusores deben dimensionarse según su silueta en pantalla, no según su núcleo físico. Consulta LOD controlado por la GPU.

Parte 22 de 29. Anterior: Parte 21: Un renderizador más rápido que no era más rápido Siguiente: Parte 23: Cincuenta avatares y una voz en la sala Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 20 simuló profundidad superficial sobre un quad plano. Esta parte trata sobre una decisión de arquitectura de renderizado, y es el experimento en el que la respuesta de manual resultó ser incorrecta para nuestro hardware. La pregunta: para renderizar hierba con prueba alfa y densidad cinematográfica bajo una cámara en tercera persona, ¿necesitamos un búfer de visibilidad antes de escalar hasta la densidad necesaria para 200 jugadores? La recomendación habitual es un sí rotundo. Lo implementamos, lo medimos y la respuesta fue no.

La técnica que todo el mundo recomienda

Abrir el experimento 40 en una pestaña nueva ↗ · Ver código fuente

Un búfer de visibilidad divide el renderizado en dos pasadas. La pasada 1 rasteriza la geometría y escribe únicamente los identificadores de triángulo e instancia en un destino entero compacto, además de la profundidad, sin realizar ningún sombreado. La pasada 2 es una pasada a pantalla completa que lee los identificadores de cada píxel cubierto, vuelve a obtener los vértices de ese triángulo, reconstruye los atributos interpolados y sombrea cada píxel visible exactamente una vez. La propuesta es una eliminación perfecta del sobredibujado: la prueba de profundidad se ejecuta sobre fragmentos que no han realizado ningún trabajo de sombreado, por lo que el material costoso solo se ejecuta sobre aquello que realmente se ve.

El experimento ejecuta dos rutas en un mismo lienzo y dispositivo, de modo que la única variable sea dónde se realiza el sombreado. La ruta forward usa un MeshStandardNodeMaterial normal mediante three.js. La ruta del búfer de visibilidad es un pipeline WebGPU de dos pasadas sin abstracciones que se ejecuta fuera de three.js, lee la textura de hierba de three.js directamente desde el backend, escribe (instanceId, triId) en un destino RG32Uint durante la pasada 1 y resuelve la iluminación en la pasada 2. Ambas comparten una única configuración de iluminación de referencia.

Hay dos notas de implementación que merece la pena conservar. WebGPU todavía no dispone de una variable integrada primitive_index portable en los shaders de fragmentos, así que el truco consiste en incorporar un identificador de triángulo por vértice en una geometría no indexada y leerlo con interpolación flat. Esto triplica el número de vértices, pero resulta insignificante en una tarjeta de hierba de 12 vértices. Además, compartir el lienzo con el renderizador de three.js apenas causa problemas siempre que nunca se reconfigure el contexto ni se modifiquen las dimensiones del lienzo, pues three.js controla ambas cosas. Medir los tiempos de la ruta forward fue la parte más delicada, ya que three.js no ofrece ningún punto de extensión para inyectar consultas de marcas de tiempo de la GPU dentro de su pasada de renderizado. La solución alternativa consiste en delimitar su trabajo con dos pasadas de marcas de tiempo sin operaciones, enviadas antes y después, que la GPU ejecuta en el orden de envío.

Los números van en la dirección equivocada

En un Mac de la serie M a unos 1080p, con briznas de hierba formadas por tarjetas cruzadas sobre un campo de 80 m:

Con 50.000 instancias, la ruta del búfer de visibilidad ganó por un 25 %: 4,13 ms frente a los 5,51 ms de la ruta forward. Con 100.000 quedaron empatadas. Con 200.000 instancias, la ruta forward ganó por un 44 %: 5,44 ms frente a los 7,80 ms del búfer de visibilidad. La ruta del búfer de visibilidad se vuelve relativamente peor a medida que aumenta la densidad, justo lo contrario de la creencia popular según la cual destaca precisamente cuando el sobredibujado es intenso.

Por qué la ruta forward mantiene el rendimiento

Las GPU Apple Silicon son renderizadores diferidos basados en mosaicos, y eso cambia todo el cálculo. El sombreado forward en un TBDR cuenta con una etapa de eliminación de superficies ocultas que se ejecuta antes del shader de fragmentos: el rasterizador reúne todos los fragmentos que corresponden a un mosaico, los ordena por profundidad y solo los supervivientes —después de la prueba alfa— llegan al shader de fragmentos. Por tanto, la ruta forward ya obtiene gratis, dentro del propio hardware, la mayor parte de la promesa del búfer de visibilidad de «sombrear una vez por píxel». A medida que las briznas llenan la pantalla, la eliminación de superficies ocultas descarta más fragmentos antes de ejecutar cualquier sombreado, y el coste efectivo por píxel de la ruta forward se mantiene aproximadamente constante en lugar de crecer con el sobredibujado.

La pasada 1 de la ruta del búfer de visibilidad obtiene esa misma ventaja del TBDR. El problema está por completo en la pasada 2. Esta lee la matriz de instancia de cada píxel desde un búfer que, con 200.000 instancias, ocupa 12,8 MB, mucho más que cualquier caché de GPU. Los píxeles adyacentes en pantalla suelen pertenecer a instancias de hierba diferentes —la distribución usa una cuadrícula con desplazamientos aleatorios, por lo que las briznas vecinas tienen identificadores de instancia arbitrarios—, así que cada wave que accede a ese búfer provoca fallos de caché divergentes. Ese acceso aleatorio e incoherente consume por sí solo unos 4 ms por fotograma. La ruta forward lo evita por completo porque la matriz de instancia llega junto con el vértice mediante la ruta de atributos por instancia. Por ello, cuando se ejecuta el shader de fragmentos, los datos de vértices transformados ya están en registros locales del mosaico y no es necesaria ninguna lectura aleatoria a escala de megabytes.

Este es exactamente el coste que la pasada de clasificación de materiales de Nanite pretende amortizar: agrupa los píxeles por instancia y lanza waves de cómputo ordenadas para que las lecturas de cada wave sean coherentes. Nosotros no contamos con eso. Un cálculo aproximado indica que ordenar los píxeles por instancia reduciría esos 4 ms quizá hasta 1,5 o 2 ms y desplazaría el punto de cruce hasta las 400.000 o 500.000 instancias. Pero eso supone apilar optimizaciones sobre una arquitectura que, para empezar, aquí no está ganando.

La conclusión sincera y la auditoría que la respalda

Para follaje de tarjetas cruzadas con prueba alfa en WebGPU sobre Apple Silicon, la ruta forward con el pipeline TSL de three.js ya iguala o mejora el coste del búfer de visibilidad. Toda la infraestructura de este búfer no aporta ninguna ventaja visible hasta superar ampliamente las 200.000 instancias, y solo si además se añade una pasada de ordenación o agrupamiento. La decisión práctica para el motor de producción es mantener la combinación de renderizado forward, LOD e impostores de los experimentos anteriores y no invertir en infraestructura de búfer de visibilidad hasta que las GPU discretas de NVIDIA o AMD sean nuestro objetivo de despliegue dominante —donde el coste del sobredibujado es más lineal— o adoptemos una arquitectura de meshlets, en la que el búfer de visibilidad ya constituye la salida natural.

Como el resultado es contrario a la intuición, la conclusión solo tiene valor si la comparación es justa, así que sometimos el experimento a una auditoría completa. Aparecieron y se corrigieron varios errores reales: un control deslizante de escala de las briznas que desincronizaba silenciosamente ambas rutas; la mitad de las briznas forward, que se renderizaban casi negras debido a normales antiparalelas —corregido con el truco habitual de orientar hacia arriba las normales del follaje—; y el búfer de visibilidad, que se veía aproximadamente el doble de brillante por usar un factor Lambert elegido manualmente en lugar del 1/π que conserva la energía, un término de iluminación ambiental fijo y la ausencia de mapeo de tonos. La corrección copió en WGSL la curva fílmica ACES exacta de three.js y lee en cada fotograma los colores e intensidades de las luces reales de la escena. La única diferencia conocida que permanece, la falta de especular directo en la pasada 2, sesga la comparación a favor del búfer de visibilidad. Es decir, la ruta forward realiza estrictamente más trabajo por píxel y aun así gana a alta densidad. Esto hace que la conclusión principal sea conservadora, no optimista. La única salvedad sigue vigente: todo esto es específico de la serie M, y el punto de cruce bien podría invertirse en una GPU discreta, por lo que conviene repetir las pruebas antes de adoptar esta combinación para objetivos que no sean de Apple.

Tecnología mencionada en este capítulo

Renderizado mediante búfer de visibilidad. La pasada 1 rasteriza la geometría y escribe únicamente los identificadores de triángulo e instancia, además de la profundidad, sin realizar ningún sombreado. La pasada 2 es una resolución a pantalla completa que lee los identificadores de cada píxel cubierto, vuelve a obtener el triángulo de origen, reconstruye los atributos baricéntricos con corrección de perspectiva y sombrea cada píxel visible una vez. Como WebGPU carece de un primitive_index de fragmento portable, el identificador del triángulo se incorpora como atributo por vértice con interpolación flat en una geometría no indexada.

Eliminación de superficies ocultas en TBDR frente a resolución diferida. En una GPU diferida basada en mosaicos —como Apple Silicon—, el sombreado forward ya descarta los fragmentos ocluidos antes de ejecutar el shader de fragmentos. Por ello, obtiene gratis la mayor parte de la ventaja del búfer de visibilidad de sombrear una sola vez, y su coste por píxel se mantiene aproximadamente constante a medida que aumenta el sobredibujado. En cambio, una pasada de resolución del búfer de visibilidad paga el coste del acceso aleatorio incoherente a un gran búfer por instancia —12,8 MB con 200.000 instancias—, que domina a alta densidad a menos que primero se ordenen o agrupen los píxeles por instancia, como hace la clasificación de materiales de Nanite.

Compartir un lienzo con el WebGPURenderer de three.js. Los búferes de comandos WebGPU sin abstracciones se intercalan correctamente con los envíos de three.js en la cola compartida, siempre que nunca se vuelva a llamar a context.configure() ni se escriba en canvas.width/height, pues el renderizador controla ambas cosas. Los tiempos de GPU de la ruta forward, para los que three.js no ofrece ningún punto de extensión, pueden delimitarse mediante dos pasadas de renderizado de marcas de tiempo sin operaciones enviadas alrededor de su llamada de renderizado, ya que la GPU ejecuta los búferes de comandos en el orden de envío.

Validación de un benchmark contrario a la intuición. Un resultado de rendimiento sorprendente solo es tan fiable como la equidad de la comparación. Auditar ambas rutas para garantizar contenido y sombreado de escena idénticos —el mismo mapeo de tonos ACES, Lambert con conservación de energía, luces leídas de los mismos objetos y escala idéntica de las briznas— fue lo que convirtió «el búfer de visibilidad es más lento» de un probable artefacto de medición en una conclusión defendible, con la única asimetría restante sesgada en la dirección conservadora.

Parte 21 de 29. Anterior: Parte 20 - Simular profundidad en un plano Siguiente: Parte 22 - Nubes que puedes atravesar volando y un culling que merece la pena Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 19 usó un quad plano para simular un árbol entero a distancia. Esta parte usa un quad plano para simular profundidad de cerca: mapeado de oclusión por paralaje, la técnica que hace que una calzada de adoquines parezca tener juntas hundidas 5 cm sin emplear ni un solo vértice adicional. El objetivo era llevarla a la pila de producción (Three.js r184, WebGPU y TSL), para que los materiales de detalle del terreno puedan ofrecer esa ilusión de profundidad donde importa y pagar el coste de una textura plana en el resto.

Tres formas de simular profundidad, una junto a otra

Abrir el experimento 39 en una pestaña nueva ↗ · Ver el código fuente

El experimento coloca tres planos de 5×5 m uno junto a otro, todos con la misma estructura de material y diferenciados únicamente por las UV que alimentan los muestreadores. El modo plano muestrea la textura directamente y sirve como referencia de base. El paralaje de una sola muestra desplaza las UV una vez a lo largo de la dirección de visión según la altura de ese punto; es barato y aceptable con amplitudes bajas, pero se desliza en ángulos rasantes. POM hace avanzar un rayo por pasos en el espacio tangente: recorre el rayo de visión, encuentra la primera capa donde el rayo pasa por debajo del campo de alturas y refina la intersección. El espacio tangente sigue siendo sencillo porque todos los planos de prueba están alineados con los ejes, de modo que la dirección de visión puede transformarse al espacio tangente con un par de inversiones de signo en lugar de una matriz TBN completa por vértice. El conjunto de texturas se obtiene en directo desde la API de archivos de Polyhaven, la misma vía que usó la búsqueda de modelos de la parte 17.

Dos obstáculos de WebGPU y un trazado de rayos sin bifurcaciones

El bucle POM de manual abandona la búsqueda al encontrar la primera intersección. En r184 eso no funciona, por dos motivos distintos. If(...).and(...) compilaba sin errores, pero producía WGSL en el que el cuerpo del bucle nunca se ejecutaba, por lo que el refinamiento posterior al bucle operaba sobre basura y el plano se renderizaba casi blanco. Además, Break() como nodo independiente aún no estaba incluido en la compilación r184, así que ni siquiera con un If funcional había forma de expresar «detenerse en la primera intersección». Ambos problemas se remontan a incidencias conocidas de three.js relacionadas con una optimización excesiva del flujo de control de TSL a través de los límites de If y Loop en esta serie de versiones.

La reescritura no usa bifurcaciones. Cada iteración muestrea la textura de forma incondicional, lo que mantiene el acceso a texturas dentro del flujo de control uniforme exigido por la especificación de WGSL, y después incorpora el nuevo estado mediante una bandera done almacenada como un valor flotante. Una vez que done cambia a 1, las llamadas a mix de cada iteración se reducen a «mantener el estado sin cambios», el equivalente sin bifurcaciones de una interrupción. La bandera done se construye con una función auxiliar step implementada como 0.5 + 0.5 × sign(x + ε), porque la conversión de booleanos a valores flotantes ha sido irregular en la serie r18x y sign() resulta fiable en todas partes. El coste es que cada fragmento ejecuta las 64 iteraciones, independientemente de dónde se produzca realmente la intersección, pero es la compensación adecuada a escala de fragmento: el tiempo de ejecución ya limita el número máximo de pasos y una GPU real también ejecutaría especulativamente más allá de un break «real». Aquí es importante contar con una alternativa limpia: un mix(baseUV, refined, done) final, de modo que, con amplitud cero —el extremo lejano de la transición por distancia—, ningún fragmento interseque, done permanezca en 0 y el material POM sea idéntico bit a bit al plano. Ese es precisamente el objetivo del truco de LOD por distancia: reducirse al coste del modo plano cuando el efecto ya es menor que un píxel.

El error fue un fallo de disciplina, no de matemáticas

La versión sin bifurcaciones funcionaba, pero se veía distorsionada: presentaba artefactos horizontales alargados con una amplitud moderada y un resultado sutilmente incorrecto y poco nítido con amplitudes bajas. La solución surgió de una instrucción de una sola línea: ve a leer la referencia canónica. El tutorial de LlamAcademy que inspiró esto no es más que un nodo de ShaderGraph de Unity, así que la implementación real se encuentra en PerPixelDisplacement.hlsl de Unity. Leerlo línea por línea reveló tres diferencias semánticas que había introducido sin darme cuenta: un desfase de uno en la referencia inicial de altura del rayo —Unity realiza un avance inicial antes del bucle, por lo que mi marco de referencia estaba desfasado un paso entero y situaba las intersecciones en la capa equivocada aproximadamente la mitad de las veces—, una convención de signo para el desplazamiento máximo de la que depende el paso de refinamiento y una elección entre contabilizar el desplazamiento acumulado o las UV acumuladas que complicaba mis cálculos de refinamiento y enredaba el signo.

La causa fundamental no fue un único error, sino mezclar dos referencias. Había tomado como guía el tutorial de POM de LearnOpenGL, que usa convenciones de signo parecidas pero diferentes y una fórmula de refinamiento distinta, y acabé en un estado híbrido donde dos tercios de las matemáticas coincidían con una fuente y el tercio restante con la otra. La reescritura es un portado casi literal del HLSL de Unity a TSL: mismos nombres de variables, mismo avance inicial y mismo refinamiento, conservando por encima la bandera done sin bifurcaciones. Merece la pena recordar la lección: al portar un shader conocido y fiable desde otra pila, pórtalo primero línea por línea y con los mismos nombres; después, refactorízalo según el estilo local. No vuelvas a deducirlo usando una segunda referencia a mitad del portado.

Un plano de referencia que no puede mentir

A la comparación en paralelo le faltaba lo más evidente: un plano con geometría real. Sin él, afirmar que «POM se ve bastante bien» no se puede refutar. ¿Bastante bien comparado con qué? Por eso el experimento añadió un cuarto plano con el mismo mapa de alturas aplicado a las posiciones reales de los vértices. WebGPU no dispone de teselación por hardware —sencillamente no forma parte de la especificación, pues se eliminó por compatibilidad con Metal—, así que el sustituto es un plano densamente subdividido (256×256 segmentos, 131.072 triángulos) con desplazamiento de vértices en la etapa de vértices. El mismo uniforme de amplitud controla tanto POM como el plano geométrico, por lo que ambos se desvanecen a la vez y la comparación sigue siendo equivalente a cualquier distancia.

Con la referencia real en pantalla, las afirmaciones cualitativas pasaron a ser medibles. En una órbita de 16° mirando hacia abajo, POM y el plano teselado coinciden en el sombreado interno. En ángulos rasantes divergen exactamente donde deben hacerlo: POM queda limitado por el borde rectangular perfectamente recto de la geometría, mientras que la malla real muestra un perfil irregular en el horizonte, con picos y valles auténticos que reciben la luz. Así, el «deslizamiento» de los bordes de POM queda demostrado como algo intrínseco al algoritmo, no como un artefacto de la textura o la iluminación. Los dos perfiles de coste también quedan claros: POM está limitado por los fragmentos —el coste crece con los píxeles cubiertos—, mientras que el plano teselado está limitado por los vértices —el coste crece con la densidad de la malla sin importar la cobertura—. Para un bloque de terreno, que ya paga el coste de vértices de un plano controlado por un mapa de alturas, POM es la solución adecuada para el detalle por debajo de la escala de la malla.

El plano de referencia también detectó un error sutil de experiencia de usuario. El usuario observó que la superficie parecía hundirse al aumentar la amplitud. La causa era la convención de Unity, que trata el plano geométrico como la parte superior del campo de alturas, de modo que los picos permanecen anclados al mismo nivel y todo lo demás se desplaza hacia abajo por paralaje, arrastrando la superficie media por debajo de la referencia plana en (1 − mean_h) × amplitude. La solución vuelve a centrar la convención para que h = 0.5 corresponda al plano: los picos ascienden hacia la cámara y los valles se hunden. El algoritmo se ejecuta exactamente como prescribe Unity; el experimento simplemente posprocesa el resultado con medio desplazamiento para ajustarlo a lo que «amplitud» debería significar para una persona que mueve un control deslizante.

El plano de referencia aclaró una cuestión más. Un control deslizante de «Pasos» parecía no hacer nada, lo que daba la impresión de ser un error de conexión, pero no lo era. El refinamiento por secante de tres iteraciones posterior a la búsqueda lineal es tan bueno —el artículo de Tatarchuk de 2006 sobre POM señala que una búsqueda de 4 pasos más 3 pasos de secante resulta visualmente indistinguible de una búsqueda de 64 pasos— que, en un mapa de alturas suave, cualquier cantidad de pasos entre 4 y 64 converge a las mismas UV con precisión inferior a un téxel. La solución fue añadir un interruptor, no rehacer las conexiones: al desactivar la secante, el control de pasos se convierte en el único ajuste de la precisión de la intersección, por lo que reducirlo a 4 produce escalones visibles en los adoquines y aumentarlo a 64 vuelve a suavizarlos. El interruptor es un uniforme 0/1 que usa mix para convertir cada actualización de estado de la secante en una operación nula cuando está desactivado, por lo que alternarlo nunca reconstruye el material ni provoca tirones.

Tecnología mencionada en este capítulo

Mapeado de oclusión por paralaje en TSL. POM hace avanzar un rayo por la dirección de visión a través de un campo de alturas en el espacio tangente, encuentra la primera capa donde el rayo pasa por debajo de la superficie y refina la intersección, produciendo la profundidad de unas juntas hundidas sobre un quad plano sin geometría adicional. Un mix(baseUV, refined, done) final hace que el material sea idéntico bit a bit al modo plano cuando ningún fragmento interseca, lo que permite que la atenuación de amplitud del LOD por distancia reduzca el coste al de una textura plana en la lejanía. Consulta materiales de terreno.

Bucles sin bifurcaciones para el flujo de control de WebGPU. En Three.js r184, If(...).and(...) de TSL puede compilarse a WGSL con un cuerpo de bucle que nunca se ejecuta, y Break() como nodo independiente no está disponible. El patrón portable consiste en realizar una muestra de textura incondicional por iteración —manteniendo el acceso a texturas dentro de un flujo de control uniforme, conforme a la especificación de WGSL— y usar una bandera done almacenada como valor flotante que, mediante mix, convierte cada actualización de estado en una operación nula una vez activada. Una función auxiliar step construida a partir de sign(x + ε) evita la conversión poco fiable de booleanos a valores flotantes. El coste mantiene constante el número máximo de iteraciones, independientemente del punto de salida anticipada, la compensación correcta a escala de fragmento.

Portado literal de shaders. El portado de un shader conocido y fiable desde otro motor debe hacerse primero línea por línea y con los nombres de variables originales; la adaptación al estilo local viene después. Mezclar dos referencias —PerPixelDisplacement.hlsl de Unity y el tutorial de LearnOpenGL— produjo un híbrido con un desfase de uno en la referencia inicial del rayo, un signo de desplazamiento invertido y una fórmula de refinamiento cuyo límite ocultaba los pesos fuera de rango en forma de discontinuidades espaciales. Una única referencia canónica, no una nueva deducción.

Referencia real con vértices desplazados. Como WebGPU no dispone de teselación por hardware, un plano densamente subdividido —256² segmentos— y desplazado en la etapa de vértices sirve como geometría real para validar una simulación ejecutada en la etapa de fragmentos. Controlar ambos mediante el mismo uniforme de amplitud mantiene una comparación rigurosa a cualquier distancia. POM está limitado por los fragmentos —escala con los píxeles cubiertos— y el plano geométrico está limitado por los vértices —escala con la densidad de la malla—, por lo que divergen precisamente en los bordes de la silueta, demostrando que el deslizamiento de los bordes de POM es intrínseco y no un artefacto.

Parte 20 de 29. Anterior: Parte 19 - El impostor que debe sobrevivir a un bosque Siguiente: Parte 21 - Un renderizador más rápido que no era más rápido Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 18 ofreció a los creadores un pincel que llena de árboles la ladera de una colina. El problema es cuánto cuestan esos árboles cuando hay decenas de miles en pantalla. Un árbol distante no necesita 2000 triángulos para aportar cuatro píxeles. Esta parte trata del LOD más profundo: el impostor, un quad plano que lleva una imagen del árbol, y el camino desde «un árbol que se ve bien» hasta un millón de ellos en la GPU.

Un árbol son dos texturas sobre una valla publicitaria

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

Un impostor prerenderiza un elemento desde una cuadrícula de ángulos de visión en dos atlas de texturas, uno para el color y otro para las normales en espacio de mundo, y después, en tiempo de ejecución, muestra un único quad orientado hacia la cámara que muestrea la celda correspondiente a la vista actual. El horneado consta de dos pasadas por celda: una difusa con un material sin iluminación para que esta no quede horneada en la textura, y otra de normales codificadas como normalWorld × 0.5 + 0.5, con el alfa transferido desde el original para que la silueta coincida píxel por píxel. El material en tiempo de ejecución es un MeshStandardNodeMaterial completo, así que el impostor sigue recibiendo el sol y la IBL de la escena como cualquier otra superficie. La ventaja está en la geometría: un quad en lugar de miles de triángulos, con el detalle almacenado en una textura de 1 MB.

Separar esto en su propio spike fue en sí mismo una lección. El impostor comenzó como el LOD más profundo dentro del sistema de dispersión del Spike 37, y cada iteración del horneado tenía que probarse a través de todo el flujo de dispersión, con la corrección del horneado entremezclada con la migración de matrices de instancias y los cambios de LOD. Separarlo para tener un elemento y un quad, uno junto al otro con el original, redujo el tiempo de iteración de minutos a segundos.

Cuando la solución de manual es la solución equivocada

La primera implementación utilizaba codificación octaédrica, el método de manual para empaquetar las direcciones de una esfera en un cuadrado. Superaba las pruebas numéricas de ida y vuelta, pero el usuario seguía enviando capturas en las que el impostor saltaba a una celda que parecía mostrar el árbol ligeramente desde arriba en vez de de frente. Le siguieron seis rondas de correcciones —un uniforme de dirección de vista por quad, un horneado con relación de aspecto cuadrada, materiales de depuración y orientación estática de las vallas— y todas eran realmente necesarias, pero ninguna resolvía el error real. La solución solo llegó al «replantearlo desde cero, KISS, sin parches».

La reescritura descartó el plegado octaédrico y usó azimut por elevación sin más: az = atan2(dir.x, dir.z), el = asin(dir.y), uv = (az/2π, el/π + ½). Esa es toda la codificación, sin normalización L1 ni casos límite relacionados con el signo del cero. La razón por la que aquí es mejor no es que sea más precisa —muestrea una esfera de forma menos uniforme—, sino que el selector de celdas de la CPU y el shader de la GPU utilizan las mismas primitivas, así que no pueden discrepar en una dirección limítrofe como hacía silenciosamente el par octaédrico. El atlas se lee como una hoja de contactos: la columna representa el ángulo alrededor del elemento y la fila, la elevación; resulta evidente de un vistazo en la superposición.

Incluso después de eso, persistía la queja de que «parece visto ligeramente desde arriba», y la causa era una elección de cuantización, no la codificación. Con una cuadrícula de 4×4, los centros de las filas caen en ±22,5° y ±67,5°, por lo que no hay ninguna fila exactamente a 0° de elevación. Un espectador que mira horizontalmente, el caso más habitual con mucha diferencia, siempre cae en una fila horneada con inclinación. La solución es usar un N impar: una cuadrícula de 5×5 sitúa los centros de las filas en 0°, ±36° y ±72°, de modo que el espectador horizontal obtiene una celda horneada exactamente en horizontal. El mismo tipo de error de «desfase de media celda» vuelve a aparecer en el trabajo de paralaje de la siguiente parte, y la solución es plantearse la misma pregunta: ¿mi punto de muestreo discreto cae realmente donde creo para la entrada canónica?

Importaban otras dos cosas. La valla debe permanecer estática por tramos, no orientarse continuamente hacia la cámara. El impostor es una imagen plana tomada desde una dirección de horneado concreta, por lo que el plano de imagen del quad en tiempo de ejecución debe coincidir con el plano de esa cámara de horneado. Esto significa que conserva su orientación a lo largo del arco en el que permanece seleccionada una misma celda y después salta en el límite. Además, el presupuesto debe seguir las zonas hacia las que realmente miran los jugadores: una pasada posterior eliminó por completo las filas inclinadas en vista cenital para favorecer 24 posiciones en un anillo horizontal, separadas por 15°, más una celda completamente cenital, porque los árboles se ven desde la altura de los ojos prácticamente todo el tiempo.

El salto y cómo lo eliminó la mezcla

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

La valla estática por tramos resulta imperceptible a distancia y salta a corta distancia, lo cual no supone un problema hasta que se orbita alrededor. El Spike 42 colocó cuatro variantes una al lado de la otra —el elemento original, la base az/el de 5×5 y dos cuadrículas hemioctaédricas— para aislar el parpadeo y eliminarlo. Hay dos artefactos que provocan el salto. El cambio de celda se produce porque el shader de fragmentos cuantiza la dirección de vista en una de 25 celdas, así que cruzar un límite cambia la celda muestreada y reorienta el quad en el mismo fotograma. La degeneración del polo se da en la vista cenital, donde todos los azimuts convergen en un único punto y la transición entre el anillo y la celda superior es la peor del atlas.

El mapeado hemioctaédrico resuelve ambos problemas. Mapea continuamente el hemisferio superior sobre el cuadrado unitario, por lo que las direcciones 3D adyacentes caen en UV adyacentes, sin singularidad en el polo ni necesidad de una celda cenital especial. La solución al parpadeo es la mezcla bilineal de celdas: en lugar de saltar a la celda más cercana, se encuentra el grupo de 2×2 celdas que encierra la dirección codificada y se mezclan las cuatro, con un total de 8 lecturas de textura —4 difusas y 4 de normales—. Ahora las vistas adyacentes se funden entre sí en vez de saltar. La mezcla de dos vectores normales unitarios no tiene por qué conservar la longitud unitaria, así que se vuelve a normalizar, lo que se comporta como un slerp para los pequeños ángulos entre celdas vecinas. El coste es real —un atlas de 12×12 ocupa unos 9 MB frente a los 1,6 MB del az/el, y el horneado tarda aproximadamente cinco veces más con 288 pasadas sobre destinos de renderizado—, pero el horneado solo se realiza una vez durante la carga y la mezcla ofrece un resultado sin saltos, que es lo que permite utilizar impostores mientras la cámara está realmente en movimiento.

Un millón de árboles, una copia de la posición de la cámara por fotograma

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

El sistema en tiempo de ejecución del Spike 38 ejecuta un lookAt en la CPU por quad y por fotograma, algo que funciona bien con un árbol pero resulta fatal para un bosque. Con un millón de árboles, las actualizaciones de matrices y la carga del búfer de instancias en cada fotograma dominarían todo el procesamiento. El Spike 41 traslada a la GPU todo el flujo por fotograma. El centro, la rotación sobre el eje vertical y la escala de cada instancia se cargan una sola vez durante la construcción como atributos de instancia y nunca cambian. El shader de vértices construye la base de la valla a partir de la dirección de vista en espacio de mundo camPos − center y expande un quad unitario compartido en el espacio de mundo. El shader de fragmentos realiza por píxel la codificación hemioctaédrica y la mezcla bilineal. El único trabajo que la CPU realiza por fotograma para todo el bosque es un Vector3.copy que actualiza el uniforme de posición de la cámara, cuyo coste no aumenta en absoluto con el número de árboles.

Un aspecto elegante de las matemáticas es que la rotación sobre el eje vertical de cada instancia se cancela durante la decodificación de normales. El horneado almacena las normales en el sistema de referencia de la cámara de horneado y, como una rotación alrededor del eje vertical del mundo conserva +Y y el producto vectorial es equivariante bajo rotaciones, la base en tiempo de ejecución construida con la vertical del mundo como referencia ya equivale a la base de horneado rotada. Así, el shader decodifica las normales directamente mediante los varyings de la base en tiempo de ejecución sin utilizar en ningún momento la rotación vertical de cada instancia. La colocación utiliza una cuadrícula con variación aleatoria en vez de una dispersión puramente aleatoria: se divide el área en celdas y se coloca un árbol por celda en el centro más un desplazamiento acotado, lo que garantiza una separación mínima —no hay dos árboles uno encima del otro— sin dejar de parecer un bosque natural. Un detalle fácil de pasar por alto es la esfera envolvente. La plantilla geométrica es solo un quad unitario, así que three.js descartaría por frustum todo el bosque en cuanto la cámara dejara de mirar al origen. Establecer una esfera envolvente explícita que cubra toda el área más el margen de un quad evita que los árboles de las esquinas queden recortados en ángulos rasantes.

Tecnología mencionada en este capítulo

Atlas de impostores octaédricos y de azimut-elevación. Un impostor hornea un elemento desde una cuadrícula de direcciones de vista en un atlas difuso y otro de normales en espacio de mundo, y después renderiza una única valla que muestrea la celda correspondiente, sustituyendo miles de triángulos por dos texturas. El mapeado octaédrico de manual ofrece una cobertura uniforme de la esfera, pero es propenso a divergencias entre CPU y GPU en los límites de los pliegues; una cuadrícula sencilla de azimut por elevación muestrea la esfera de manera menos uniforme, pero garantiza por construcción que el selector de celdas y el shader coincidan. Utiliza un N impar para que una fila caiga exactamente a 0° de elevación y dedica el presupuesto de celdas al anillo horizontal, ya que los elementos suelen verse desde la altura de los ojos.

Orientación estática por tramos de las vallas. Un impostor es una imagen tomada desde una dirección de horneado concreta, por lo que el plano de imagen del quad en tiempo de ejecución debe coincidir con el plano de la cámara de horneado, no orientarse continuamente hacia la cámara en tiempo de ejecución. El quad mantiene su orientación a lo largo del arco en el que permanece seleccionada una misma celda y después salta en el límite, algo imperceptible a la distancia de uso de los impostores y que solo se nota de cerca, donde los impostores no se utilizan.

Atlas hemioctaédrico con mezcla bilineal de celdas. Mapear continuamente el hemisferio superior sobre el cuadrado unitario elimina la singularidad del polo y la celda cenital especial. El salto se elimina muestreando el grupo de 2×2 celdas que encierra la dirección de vista codificada y mezclando bilinealmente las cuatro celdas —8 lecturas—, de modo que las vistas adyacentes se funden entre sí. Las normales mezcladas se vuelven a normalizar, aproximando un slerp en el pequeño ángulo entre celdas. El coste es un atlas más grande —unos 9 MB con 12×12— y un horneado único más largo, a cambio de un sombreado sin saltos cuando la cámara se mueve.

Impostores instanciados controlados por la GPU. El centro, la rotación sobre el eje vertical y la escala de cada instancia se cargan una sola vez como atributos de instancia; el shader de vértices construye la base de la valla y expande un quad unitario compartido, mientras que el shader de fragmentos realiza por píxel la codificación y la mezcla. El coste de CPU por fotograma para todo el bosque se limita a una única copia del uniforme de posición de la cámara, independientemente del número de instancias. La rotación vertical de cada instancia se cancela durante la decodificación de normales porque la construcción de la base mediante productos vectoriales conserva la rotación alrededor del eje vertical del mundo. Una esfera envolvente explícita para todo el bosque evita que three.js descarte por frustum toda la malla instanciada cuando la cámara deja de mirar al origen de la plantilla del quad unitario. Consulta LOD controlado por la GPU.

Parte 19 de 29. Anterior: Parte 18 - Un pincel de dispersión que parece colocar elementos mediante IA Siguiente: Parte 20 - Simular profundidad en un plano Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Hace unas semanas escribí sobre las técnicas de renderizado que realmente incluyen los juegos AAA modernos. Un aspecto que traté por encima fue el cielo y el clima, porque merece su propia lista. Las nubes, la niebla, la lluvia y la nieve son los sistemas que convierten una demo de terreno en un lugar. También comparten más código de lo que parece. Las nubes volumétricas, la niebla a ras de suelo y los rayos crepusculares recurren al mismo trazado de rayos por pasos. Las carreteras mojadas, la acumulación de nieve y los rastros de pisadas utilizan el mismo truco de desplazamiento más PBR. El viento es un único vector de dirección que leen todos los elementos de la escena.

Este es un recorrido breve y subjetivo por la forma en que los grandes estudios construyen estos sistemas en 2026, junto con los artículos y las ponencias sobre motores que respaldan cada parte.

1. Cielo y atmósfera basados en principios físicos

La dispersión atmosférica es la base. El color del cielo, la bruma del horizonte, la forma en que las montañas lejanas adquieren un tono azul y el naranja del atardecer proceden de la dispersión de la luz al atravesar el aire. Los motores modernos calculan este fenómeno a partir de la física: dispersión de Rayleigh para el azul, dispersión de Mie para la bruma alrededor del sol y absorción del ozono para el violeta intenso del cenit.

El método original de Bruneton de 2008 precalculaba todos los datos en tablas de consulta 4D, lo que limitaba los cambios dinámicos de la hora del día y añadía artefactos de LUT cuando el sol estaba bajo. La actualización de Sébastien Hillaire de 2020, que es la que incluye el componente Sky Atmosphere de UE5, sustituye la LUT de alta dimensionalidad por unas pocas texturas 2D y una aproximación de dispersión múltiple que se actualiza en cada fotograma. Funciona tanto en un teléfono como en un PC de gama alta.

Para profundizar:

• Hillaire, Una técnica escalable y lista para producción para renderizar el cielo y la atmósfera (EGSR 2020, el estándar moderno, utilizado en UE5).
• Bruneton y Neyret, Dispersión atmosférica precalculada (EGSR 2008, el enfoque original basado en LUT).
• Bruneton, Dispersión atmosférica precalculada: una nueva implementación (implementación de referencia de código abierto, con soporte para ozono y múltiples planetas).
• Epic Games, Componente Sky Atmosphere (documentación de UE5).

2. Nubes volumétricas con ruido Perlin-Worley

La técnica fundamental para crear nubes en los juegos modernos surgió de la charla de Andrew Schneider sobre Horizon Zero Dawn en 2015. Las nubes no son mallas. Son una función de densidad 3D definida mediante capas de ruido: una mezcla Perlin-Worley de baja frecuencia proporciona la forma general de la nube, mientras que un ruido Worley de mayor frecuencia erosiona la silueta para producir bordes vaporosos. Un mapa meteorológico —una textura 2D muestreada según las coordenadas XZ del mundo— controla la cobertura, el tipo de nube y la precipitación de cada región. Un gradiente basado en la altura mezcla perfiles de cúmulos, estratos y cirros según la altitud.

El renderizador hace avanzar un rayo desde la cámara a través del volumen de nubes, acumulando densidad y dispersión. La iteración «Nubis» de 2017 añadió herramientas de creación y animación a escala regional, y la implementación original para PS4 renderizaba todo el cielo en unos 2 ms. La mayoría de los estudios que publican hoy juegos con nubes volumétricas siguen remontándose a este artículo.

Para profundizar:

• Schneider, Los paisajes de nubes volumétricas en tiempo real de Horizon Zero Dawn (SIGGRAPH 2015, la referencia canónica).
• Schneider, Nubis: creación de paisajes de nubes volumétricas en tiempo real con el motor Decima (SIGGRAPH 2017, la continuación a escala regional).
• Hillaire, Renderizado de cielos, atmósferas y nubes basado en principios físicos en Frostbite (SIGGRAPH 2016, la versión de Frostbite).
• Häggström, Renderizado en tiempo real de nubes volumétricas (una tesis clara y accesible con todo el código de shaders).

3. Nubes de vóxeles y Nubis³

La evolución de Nubis de 2023 abandonó por completo la representación de formas en 2.5D en favor de vóxeles 3D reales. Cada vóxel almacena directamente la densidad de la nube, lo que permite a los artistas esculpir y animar sus formas como si modelaran terreno. El coste de pasar a una representación más densa se compensa acelerando el trazado de rayos por pasos mediante campos de distancia con signo comprimidos y técnicas ingeniosas para aumentar la resolución de datos de vóxeles dispersos.

El resultado es el tipo de paisaje nuboso que puedes atravesar volando sin que los trucos subyacentes queden al descubierto. Es excesivo para la mayoría de los estudios, pero esa es la dirección en la que avanza la gama alta.

Para profundizar:

• Schneider, Nubis³: métodos (y locuras) para modelar y renderizar nubes inmersivas basadas en vóxeles en tiempo real (SIGGRAPH 2023, la charla sobre nubes de vóxeles).
• Schneider, Nubis, evolucionado (SIGGRAPH 2022, el puente entre 2.5D y 3D completo).
• Schneider, Efectos volumétricos y VFX en tiempo real (el sitio personal de Andrew, con material de cursos y análisis detallados).

4. Renderizado de nubes por capas y fondos 2D

No todos los estudios pueden permitirse nubes totalmente volumétricas, y no todos los ángulos de cámara las necesitan. Muchos juegos combinan técnicas: cirros a gran altitud renderizados como una capa 2D en desplazamiento, cúmulos a media altitud como volúmenes trazados por rayos y estratos a baja altitud como una fina lámina de medio participativo. Para el horizonte suele utilizarse un cubemap de cielo precalculado, con el que se fusiona la pasada volumétrica más allá de una distancia de desvanecimiento.

Este sistema de capas es lo que mantiene bajo control el presupuesto de las nubes. Un solo tipo de nube a máxima calidad puede consumir entre 4 y 6 ms; usar distintas calidades para diferentes altitudes permite mantener el mismo aspecto por la mitad del coste.

Para profundizar:

• Vos, Los paisajes de nubes volumétricas en tiempo real de Horizon Zero Dawn (vídeo de GDC 2016; el análisis del sistema de capas está en la segunda mitad).
• Bauer, Creación del mundo atmosférico de Red Dead Redemption 2 (SIGGRAPH 2019, el pipeline combinado de cielo, nubes y efectos volumétricos de RDR2).
• Hillaire, Nubes volumétricas y megapartículas en REDengine 4 (GDC 2025, el pipeline de nubes de Cyberpunk 2077).

5. Niebla volumétrica con cuadrículas de fróxeles

La niebla es un campo 3D, no un efecto de pantalla 2D. El enfoque moderno estándar es la cuadrícula de fróxeles: una textura 3D alineada con el frustum de visión de la cámara, en la que cada celda («fróxel» = frustum + vóxel) almacena la densidad y el color iluminado. Un shader de cómputo inyecta en la cuadrícula la dispersión de cada fuente de luz, acumula la extinción a lo largo del rayo de visión y aplica el resultado como una pasada a pantalla completa.

Esto es lo que genera haces de luz a través de las ventanas, niebla coloreada alrededor de luces puntuales y volúmenes visibles en torno a las explosiones. También es el mecanismo subyacente de la «perspectiva atmosférica», que hace que los objetos lejanos se desvanezcan en el aire. Bart Wronski introdujo la técnica para Assassin's Creed 4 y Sébastien Hillaire la estandarizó en Frostbite.

Para profundizar:

• Wronski, Niebla volumétrica: una solución unificada para la dispersión atmosférica basada en shaders de cómputo (SIGGRAPH 2014, el artículo original sobre cuadrículas de fróxeles).
• Hillaire, Renderizado volumétrico unificado y basado en principios físicos en Frostbite (SIGGRAPH 2015, la implementación lista para producción).
• Kovalovs, Efectos volumétricos de The Last of Us Part Two (SIGGRAPH 2020, con notas sobre jitter temporal y composición con corrección de profundidad).
• Wright et al., Lumen: iluminación global en tiempo real en Unreal Engine 5 (SIGGRAPH 2022, incluye la interacción de Lumen con la niebla volumétrica).

6. Rayos divinos y haces crepusculares

Los rayos de sol visibles en el aire brumoso no son un efecto independiente. Surgen del mismo sistema de niebla, siempre que tanto la densidad de la niebla como el mapa de sombras estén disponibles para el mismo shader de cómputo. Cuando el shader inyecta luz en un fróxel, muestrea el mapa de sombras en la posición de ese fróxel dentro del mundo. Las celdas en sombra permanecen oscuras y las iluminadas adoptan el color del sol. Al recorrer el resultado con el rayo de la cámara, las celdas brillantes forman haces continuos.

También existen variantes más baratas en espacio de pantalla —un desenfoque radial desde la posición del sol hacia el búfer de profundidad— y siguen siendo la opción adecuada para móviles o hardware de gama baja. No captan el sol cuando está fuera de pantalla, pero su coste es casi nulo.

Para profundizar:

• Mitchell, Dispersión volumétrica de la luz como posproceso (GPU Gems 3, el enfoque de desenfoque radial en espacio de pantalla).
• Engelhardt y Dachsbacher, Muestreo epipolar para sombras y rayos crepusculares en medios participativos (I3D 2010, la técnica para GPU más precisa).
• Vos, Efectos de luz volumétrica en Killzone: Shadow Fall (SIGGRAPH 2014, la versión de producción con integración de sombras).

7. Relámpagos y fenómenos meteorológicos estocásticos

Un relámpago es un efecto de un solo fotograma con dos partes: la malla del rayo y la respuesta de la iluminación y el mapeo de tonos de toda la escena. El rayo propiamente dicho suele ser una malla de billboards procedural creada mediante un algoritmo recursivo de subdivisión de segmentos, con variaciones aleatorias para darle un aspecto caótico y un estrechamiento progresivo hacia el suelo. Algunos motores lo renderizan como un destello aditivo en espacio de pantalla; otros, como geometría emisiva totalmente iluminada que proyecta luz sobre el mundo mediante la inyección de una luz puntual durante un fotograma.

Lo interesante es todo lo demás: la parte inferior de las nubes se ilumina desde abajo, el suelo resplandece durante dos fotogramas, la medición de la exposición automática tarda unos cuantos fotogramas en recuperarse y se reproduce un trueno con un retardo basado en la distancia. Bien ejecutado, esto convierte un destello de 16 ms en una secuencia de cinco segundos que transmite la sensación de que el clima ocurre dentro del mundo y no simplemente por encima de él.

Para profundizar:

• Reed y Wyvill, Simulación visual de relámpagos (SIGGRAPH 1994, el algoritmo recursivo de rayos que todavía utiliza todo el mundo).
• Kim y Lin, Animación rápida de relámpagos mediante una malla adaptativa (IEEE TVCG 2007, con una base física más rigurosa).
• Bauer, Creación del mundo atmosférico de Red Dead Redemption 2 (SIGGRAPH 2019, el pipeline de tormentas de RDR2, incluida la temporización de los relámpagos).

8. Partículas de lluvia, mallas de lluvia y gotas en espacio de pantalla

En los juegos modernos, la lluvia rara vez se compone únicamente de partículas. La solución barata y convincente consiste en un pequeño conjunto de texturas en desplazamiento extendidas sobre quads verticales o alineados con la pantalla, iluminados por las mismas sondas de sol y cielo que el resto de la escena. Cerca de la cámara, partículas individuales con forma de estela añaden detalle. En la propia lente de la cámara, las texturas de gotas, los regueros deslizantes y las ondas de impacto refuerzan la sensación de «estar dentro de la tormenta».

El viento afecta a la dirección de la lluvia. El mismo vector de viento desplaza el mapa meteorológico de las nubes, dobla la hierba e inclina los quads de lluvia. Un solo vector para toda la escena y decenas de sistemas que lo utilizan.

Para profundizar:

• Tatarchuk, Renderizado de lluvia en tiempo real dirigible por artistas en entornos urbanos (EGSR 2006, la referencia canónica sobre lluvia por capas).
• Garg y Nayar, Renderizado fotorrealista de trazos de lluvia (SIGGRAPH 2006, la física de la luz al atravesar las gotas de lluvia).
• Wojciechowski, La lluvia en Cyberpunk 2077 (GDC 2021, un recorrido por una implementación moderna en producción).

9. Superficies mojadas, charcos y ondas

La lluvia que no cambia el suelo parece falsa de inmediato. Las superficies mojadas responden oscureciendo su albedo (el agua absorbe la luz incidente), suavizando sus normales (la película de agua alisa la microsuperficie) y reduciendo su rugosidad (el agua es un espejo casi perfecto en ángulos rasantes). El cambio en el shader es pequeño; el cambio visual es enorme.

Los charcos se controlan mediante máscaras: una máscara basada en la altura o pintada sobre los vértices define las zonas bajas que se llenan de agua a medida que aumenta un parámetro de «humedad». Las ondas son texturas de mapas de normales en flipbook que se activan con los impactos de las gotas de lluvia. Las implementaciones realmente buenas acumulan el estado de humedad con el tiempo, de modo que una tormenta larga empapa lentamente el mundo, mientras que un chaparrón breve solo oscurece las zonas altas.

Para profundizar:

• Lagarde y de Rousiers, Migración de Frostbite al renderizado basado en física 3.0, sección 5.5 (SIGGRAPH 2014, los ajustes PBR canónicos para superficies mojadas).
• Lagarde, Adopción de un modelo de sombreado basado en física (la serie original del blog con las matemáticas del PBR para superficies mojadas).
• Cyanilux, Análisis de efectos de lluvia (un recorrido accesible con Shader Graph sobre charcos, ondas y gotas).

10. Acumulación y deformación de nieve

La nieve plantea el problema simétrico al de la lluvia: el mundo debe recordarla, no solo recibirla. El enfoque habitual utiliza una textura cenital de «acumulación de nieve» que se incrementa con el tiempo allí donde el cielo es visible (calculado mediante un mapa de profundidad o de sombras cenital). El shader del terreno muestrea esta máscara y mezcla el material de nieve en las zonas sombreadas, además de aplicar desplazamiento según la profundidad de la nieve en las áreas expuestas.

Las huellas y las rodadas se renderizan en un mapa de deformación deslizante centrado en el jugador. A medida que la cámara se mueve, las huellas antiguas salen del mapa y la textura se repite. El shader del terreno o de la nieve muestrea este mapa de deformación y desplaza los vértices hacia abajo en las zonas donde se ha escrito. La nieve de Battlefield 5 lo hace con teselación por hardware; los enfoques más económicos utilizan una malla de terreno de alta densidad únicamente con desplazamiento de vértices.

Para profundizar:

• Barré-Brisebois, Primer contacto con Battlefield 5: la importancia de los pequeños detalles (el artículo de producción sobre la nieve de Frostbite).
• St-Amour, Deformación de nieve en tiempo real (una tesis con todos los detalles de implementación en la GPU).
• Andersson, Renderizado de terreno en Frostbite mediante splatting procedural de shaders (la base del sistema de splatting sobre la que funciona la acumulación de nieve).

11. El viento como sistema global

El viento no es un efecto de partículas. En los motores de producción es un único vector global (a veces, un campo 3D de baja resolución) que todos los sistemas dinámicos leen desde su shader de vértices. Las briznas de hierba se doblan, las ramas de los árboles se mecen, la tela ondea, las hojas flotan, la lluvia se inclina, el humo es arrastrado y los mapas meteorológicos de nubes se desplazan. Un valor uniforme actualizado por fotograma, decenas de consumidores.

La versión más completa es una «cuadrícula de viento» que almacena la dirección y la intensidad muestreadas según la posición en el mundo, lo que permite crear tormentas con ráfagas localizadas, valles resguardados y estelas detrás de los edificios. Además, el follaje suele recibir un desplazamiento por vértice horneado durante la creación del recurso para que los árboles idénticos no se mezan al unísono. El resultado es un mundo que respira al mismo ritmo.

Para profundizar:

• McAuley, Renderizado del mundo de Far Cry 4 (GDC 2015, incluye la cuadrícula de viento de Far Cry 4 para la vegetación).
• Habel y Wimmer, Renderizado realista de paisajes en tiempo real mediante nubes de billboards (antiguo, pero las matemáticas del viento aplicado a la vegetación no han cambiado).
• Frostbite, La vegetación de Horizon Zero Dawn (SIGGRAPH 2017, con la arquitectura del sistema de viento).

12. Tormentas de arena, ventiscas y meteorología densa

La meteorología extrema constituye una categoría de renderizado propia. Una tormenta de arena es una niebla espesa y opaca, alineada con el suelo, con un marcado sesgo direccional y una niebla de distancia muy intensa. Una ventisca añade una ráfaga de partículas cerca de la cámara y reduce la visibilidad. La ceniza volcánica y el humo utilizan la misma arquitectura con colores distintos.

Lo que hace convincentes estos fenómenos no son las partículas, sino el acoplamiento: el sol se oscurece, el cielo cambia de tono, la gradación de color del posprocesado se modifica, el audio ambiental cambia, los sonidos de las pisadas se alteran y la voz del jugador se amortigua, si la tiene. El renderizador es el mensajero; la inmersión surge cuando todos los sistemas del juego responden al mismo tiempo.

Para profundizar:

• Burley, El cielo y la atmósfera en tiempo real de Uncharted: The Lost Legacy (GDC 2018, con notas sobre la composición de fenómenos meteorológicos densos).
• Khalifa, Efectos meteorológicos atmosféricos en Forza Horizon 5 (GDC 2022, meteorología moderna para mundos abiertos).
• Karis, La tecnología tras la demo «Lumen in the Land of Nanite» de Unreal Engine 5 (SIGGRAPH 2021, la pila volumétrica de la escena de polvo en la cueva).

13. Hora del día y cielos dinámicos

La hora del día en tiempo real es el multiplicador que hace que merezca la pena publicar todos los demás sistemas de esta lista. La dirección y el color del sol se actualizan durante un ciclo de 24 minutos o 24 horas. La LUT de la atmósfera se actualiza con el ángulo del sol. La iluminación de las nubes se recalcula en cada fotograma. Las cascadas de sombras se reorientan. Las sondas de reflexión se actualizan. El color ambiental cambia. La exposición del posprocesado se adapta.

Conseguirlo sin artefactos visibles consiste, sobre todo, en gestionar la caché de texturas y la estabilidad temporal. Las técnicas rápidas precalculan el cielo para ángulos solares fijos e interpolan entre ellos; las más lentas lo recalculan en cada fotograma. El modelo atmosférico de Hillaire de 2020 es lo bastante rápido como para recalcularse, por eso UE5 lo incluye. El mapa meteorológico de nubes se desplaza con el viento, de modo que la cobertura cambia de forma natural sin que nadie tenga que crear fotogramas clave.

Para profundizar:

• Hillaire, Una técnica escalable y preparada para producción para renderizar el cielo y la atmósfera (EGSR 2020, con el análisis de la hora del día dinámica).
• Pesce, Renderizado del cielo en tiempo real: técnicas y compromisos (capítulo de Ray Tracing Gems II, una panorámica moderna).
• Bauer, Creación del mundo atmosférico de Red Dead Redemption 2 (SIGGRAPH 2019, con el pipeline de 24 horas).

14. La máquina de estados meteorológicos

Debajo de todo esto hay una pequeña máquina de estados. La mayoría de los juegos incluyen entre 4 y 12 estados meteorológicos (despejado, parcialmente nublado, cubierto, lluvia ligera, lluvia intensa, tormenta eléctrica, niebla, nieve, ventisca y tormenta de arena), cada uno definido por un conjunto de parámetros: cobertura y tipo de nubes, velocidad y dirección del viento, tipo e intensidad de las precipitaciones, tintes del color ambiental, perfil de audio y gradación del posprocesado.

Las transiciones son interpolaciones lineales entre conjuntos de parámetros durante periodos de 30 a 120 segundos. La transición no es un caso especial: son simplemente dos estados interpolados, mientras cada subsistema de renderizado lee en ese fotograma los valores actuales de los parámetros. La meteorología puede estar guionizada (una cinemática necesita una tormenta), basarse en una semilla (determinista por región y por día del juego, para que dos jugadores del mismo mundo vean el mismo tiempo) o definirse por completo sobre una cuadrícula de regiones. Los pipelines más limpios tratan los tres como planificadores diferentes que escriben en el mismo búfer de parámetros.

Para profundizar:

• Bauer, Creación del mundo atmosférico de Red Dead Redemption 2 (SIGGRAPH 2019, con el pipeline de estados meteorológicos).
• Khalifa, Efectos meteorológicos atmosféricos en Forza Horizon 5 (GDC 2022, con el enfoque de mezcla de parámetros).
• Schneider, Los paisajes de nubes volumétricas en tiempo real de Horizon Zero Dawn (SIGGRAPH 2015, con la evolución de las nubes controlada por mapas meteorológicos).

15. Los momentos cinematográficos

Toda la pila existe para crear unos pocos momentos emblemáticos. Permanecer en una cresta mientras se acerca un frente tormentoso. Ver cómo un rayo de sol atraviesa un claro entre las copas de los árboles. Salir de una cueva y adentrarse en la nieve. Volar a través de una nube cúmulo y ver la luz en su interior.

Estos son los momentos de los que los jugadores hacen capturas de pantalla. También son los momentos en los que todos los sistemas anteriores deben funcionar a la vez: nubes volumétricas, dispersión atmosférica, niebla con integración de sombras, PBR para superficies mojadas, viento sobre el follaje, gradación de color según la hora del día y una transición entre estados meteorológicos, todo ello compuesto en un único fotograma. Si cualquiera de ellos falla, la magia se rompe.

Qué significa esto para el navegador

La mayoría de estas técnicas se trasladan directamente a WebGPU. Ya hemos publicado niebla atmosférica básica, mezcla de skyboxes equirectangulares y bruma de distancia en espacio de pantalla en el motor de mundo abierto para navegador. Las piezas más difíciles —nubes volumétricas completas, niebla con cuadrícula de froxels, PBR para superficies mojadas con charcos dinámicos y mapas de deformación de nieve— son el siguiente paso evidente ahora que el pipeline del terreno es estable. El muestreo por fragmento del color de la niebla a partir del skybox de Spike 24 es una pieza de este rompecabezas. Lo siguiente es un raymarcher de nubes basado en shaders de cómputo que alimente la misma LUT atmosférica.

La buena noticia es que el mínimo de hardware de los navegadores ya es lo bastante potente. WebGPU ofrece cómputo, texturas 3D, despacho indirecto y consultas de marcas de tiempo. La atmósfera de Hillaire de 2020 se ha portado varias veces a WebGL. Nubis, de Schneider, cuenta con implementaciones de referencia de código abierto en GLSL que se traducen a WGSL mediante cambios mecánicos. Ya no hay ningún motivo relacionado con el renderizado que impida que un juego de navegador tenga el mismo cielo que uno de consola. Solo quedan motivos de ingeniería, y los motivos de ingeniería son los que nos gustan.

Lecturas adicionales sobre toda la pila

Si quieres una única fuente que reúna todo esto, el archivo de SIGGRAPH «Advances in Real-Time Rendering in Games» (advances.realtimerendering.com) contiene las ponencias canónicas sobre meteorología y atmósfera desde 2014. Para análisis de producción sobre cómo juegos concretos renderizan el cielo y la meteorología, los artículos de perfilado de GPU de Adrian Courrèges incluyen desgloses detallados fotograma a fotograma de GTA V, Horizon Zero Dawn y Doom Eternal. En cuanto a las matemáticas del cielo y la atmósfera, el capítulo sobre renderizado volumétrico de scratchapixel.com es la introducción más accesible, y el repositorio de la implementación de código abierto de Hillaire es la referencia con calidad de producción.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Si analizas en detalle el pipeline de renderizado de un juego AAA de 2026, descubrirás que casi todo se basa en un pequeño conjunto de técnicas utilizadas por estudios de todo el sector. Los nombres cambian entre motores, pero las ideas son las mismas. Esta es una breve lista de las técnicas que realmente hacen el trabajo en pantalla, con una figura y varias referencias técnicas detalladas para cada una.

1. Renderizado basado en física (PBR)

Los materiales se describen mediante texturas de albedo, rugosidad, metalicidad, normales y oclusión ambiental, y se iluminan con shaders que conservan la energía (reflexión especular Cook-Torrance y reflexión difusa Lambertiana o Disney). Es la base que presupone cualquier motor AAA moderno. Si una superficie mantiene un aspecto coherente bajo la luz del sol, de una lámpara y de una linterna, se debe al PBR.

Análisis en profundidad:

• Burley, Sombreado basado en física en Disney (las notas originales del curso sobre el «BRDF de Disney», SIGGRAPH 2012).
• Karis, Sombreado realista en Unreal Engine 4 (SIGGRAPH 2013, la charla de referencia sobre PBR en UE4).
• Lagarde y de Rousiers, La transición de Frostbite al renderizado basado en física 3.0 (SIGGRAPH 2014, el pipeline completo de Frostbite).
• Real-Time Rendering, 4.ª edición, capítulo 9 (la referencia académica).

2. Sombreado diferido y mediante búfer de visibilidad

En primer lugar, la geometría escribe atributos (normales, identificadores de materiales y profundidad) en un G-buffer o búfer de visibilidad. Después, la iluminación se ejecuta como una pasada a pantalla completa que lee esos búferes y sombrea cada píxel una sola vez. Los búferes de visibilidad (utilizados por Nanite y sistemas similares) llevan esta idea más lejos al almacenar únicamente los identificadores de los triángulos y resolver después los parámetros del material por píxel, lo que reduce el coste del sobredibujado en geometrías densas.

Análisis en profundidad:

• Engel, Sombreado diferido (NVIDIA, la charla fundacional).
• Burns y Hunt, El búfer de visibilidad: un enfoque de sombreado diferido optimizado para la caché (JCGT 2013, el artículo original sobre el búfer de visibilidad).
• Wihlidal, «Optimización del pipeline gráfico mediante cómputo» (GDC 2016, el pipeline diferido basado en cómputo de Frostbite).
• Karis, Stubbe y Wihlidal, Análisis en profundidad de la geometría virtualizada de Nanite (SIGGRAPH 2021, incluye una explicación detallada del búfer de visibilidad de Nanite).

3. Geometría virtualizada (al estilo de Nanite)

Las mallas se preprocesan para formar una jerarquía de clústeres. Durante la ejecución, la GPU transmite y selecciona clústeres con la resolución adecuada para cada píxel, lo que permite obtener un nivel de detalle preciso incluso por debajo del tamaño de un píxel sin crear LOD manualmente. Nanite de Unreal es el ejemplo más conocido. Otros motores ya incluyen sus propias variantes. El resultado práctico son recursos con calidad cinematográfica en tiempo real sin tener que crear LOD.

Análisis en profundidad:

• Karis, Stubbe y Wihlidal, Análisis en profundidad de la geometría virtualizada de Nanite (SIGGRAPH 2021).
• Brian Karis, Charla sobre Nanite en la GDC 2021 (una explicación accesible en vídeo).
• Liktor, Arquitectura del pipeline de renderizado de geometría en Activision (renderizado basado en clústeres, 2021).
• Schied et al., Filtrado guiado por varianza espaciotemporal (técnicas relacionadas de descarte de clústeres).

4. Trazado de rayos en tiempo real para sombras, reflejos y AO

El trazado de rayos por hardware (DXR, Vulkan RT) proyecta rayos de sombra, rayos de reflexión especular y brillante, y rayos de oclusión ambiental contra una BVH construida en cada fotograma. Incluso unos pocos rayos por píxel superan lo que pueden conseguir las técnicas en espacio de pantalla, especialmente en reflejos de elementos situados fuera de la pantalla y sombras de contacto. La mayoría de los juegos lo utilizan de forma selectiva, no para todo.

Análisis en profundidad:

• Microsoft, Especificación funcional de DirectX Raytracing (DXR) (la referencia de la API).
• Wyman, Introducción a DirectX Raytracing (las notas del curso de SIGGRAPH, muy accesibles).
• Boksansky y Marrs, Ray Tracing Gems II, capítulos 17-19 (PDF gratuito sobre técnicas modernas de DXR).
• Stachowiak, Reflejos estocásticos en espacio de pantalla (Frostbite, el puente entre SSR y RT).

5. Trazado de rayos por software (al estilo de Lumen)

No todos los jugadores tienen una tarjeta RTX, por lo que los motores también incluyen alternativas basadas en campos de distancia o cachés de superficies. Lumen de Unreal, por ejemplo, realiza el trazado contra campos de distancia con signo y cachés de superficies para obtener una iluminación global difusa de bajo coste, y solo recurre a rayos acelerados por hardware cuando es necesario. Así es como los juegos AAA consiguen un «aspecto de trazado de rayos» en consolas.

Análisis en profundidad:

• Wright et al., Lumen: iluminación global en tiempo real en Unreal Engine 5 (SIGGRAPH 2022, el artículo sobre Lumen).
• Epic Games, Detalles técnicos de Lumen (documentación oficial del motor).
• Wright, Caché de radiancia para iluminación global en tiempo real (SIGGRAPH 2021).
• Wright, Charla sobre Lumen en la GDC 2022 (versión en vídeo).

6. ReSTIR y muestreo de reservorios

Para calcular la iluminación directa e indirecta con miles de fuentes de luz, ReSTIR (remuestreo por importancia de reservorios espaciotemporales) reutiliza muestras de luz entre píxeles y fotogramas. Así es como juegos como Cyberpunk 2077 con trazado de caminos mantienen un nivel de ruido bajo con uno o dos rayos por píxel. Cabe esperar que aparezca en más motores a medida que el trazado de caminos se convierta en el objetivo para la gama alta.

Análisis en profundidad:

• Bitterli et al., Remuestreo espaciotemporal de reservorios para trazado de rayos en tiempo real con iluminación directa dinámica (SIGGRAPH 2020, el artículo original sobre ReSTIR).
• Ouyang et al., ReSTIR GI: remuestreo de caminos para trazado de caminos en tiempo real (HPG 2021, ReSTIR para iluminación indirecta).
• Lin et al., Muestreo por importancia remuestreado generalizado (SIGGRAPH 2022, los fundamentos matemáticos).
• NVIDIA, Análisis técnico en profundidad del trazado de caminos de Cyberpunk 2077 (blog de ingeniería).

7. Nubes volumétricas, niebla y atmósfera

Los cielos se calculan mediante marcha de rayos a través de ruido 3D y volúmenes de densidad. La atmósfera utiliza tablas de dispersión precalculadas (al estilo de Bruneton) para las transiciones del sol y la luna. La niebla utiliza una cuadrícula de froxels (imagina una textura 3D alineada con el frustum de la vista) que captura la iluminación local. Juntas, estas técnicas permiten crear un «sistema meteorológico» en lugar de limitarse a un skybox.

Análisis en profundidad:

• Schneider, Los paisajes de nubes volumétricas en tiempo real de Horizon Zero Dawn (SIGGRAPH 2015, la referencia fundamental sobre nubes).
• Hillaire, Una técnica escalable y lista para producción para renderizar el cielo y la atmósfera (EGSR 2020, el sucesor moderno de Bruneton utilizado en UE5).
• Wronski, Niebla volumétrica: una solución unificada basada en shaders de cómputo para la dispersión atmosférica (SIGGRAPH 2014, niebla de froxels de Assassin's Creed 4).
• Hillaire, Renderizado volumétrico unificado y basado en física en Frostbite (SIGGRAPH 2015).

8. Mapas de sombras en cascada y mapas de sombras virtuales

Para las sombras del sol, los mapas de sombras en cascada dividen el frustum en intervalos y renderizan cada uno con la resolución adecuada. Los mapas de sombras virtuales llevan la idea más lejos: un único mapa de sombras enorme se divide en páginas y solo se renderizan las páginas visibles desde la cámara. Así es como los juegos AAA mantienen sombras nítidas cerca del jugador sin consumir una cantidad descomunal de memoria.

Análisis en profundidad:

• Dimitrov, Mapas de sombras en cascada (informe técnico de NVIDIA, la referencia estándar).
• Microsoft, Técnicas comunes para mejorar los mapas de profundidad de sombras (documentación de DirectX).
• Wright, Mapas de sombras virtuales en el capítulo 4 de Fortnite Battle Royale (SIGGRAPH 2023, la charla sobre VSM de UE5).
• Epic Games, Documentación sobre mapas de sombras virtuales.

9. Efectos en espacio de pantalla (SSAO, SSR, SSGI, SSSSS)

La lectura de los búferes de profundidad y normales permite obtener con un coste reducido oclusión ambiental (SSAO), reflejos (SSR), iluminación global de un rebote (SSGI) y dispersión subsuperficial para la piel (SSSSS). No capturan los detalles situados fuera de la pantalla, razón por la que el trazado de rayos los está sustituyendo, pero siguen utilizándose en todas partes como una solución de base rápida.

Análisis en profundidad:

• Mittring, En busca de la nueva generación: CryENGINE 2 (SIGGRAPH 2007, el artículo original sobre SSAO).
• McGuire et al., Oscurecimiento ambiental escalable (HPG 2012, SSAO moderno).
• Stachowiak y Uludag, Reflejos estocásticos en espacio de pantalla (Frostbite, la referencia sobre SSR).
• Jimenez, Dispersión subsuperficial separable (la técnica utilizada para la piel en la mayoría de los motores AAA).
• Mara et al., Espacio de pantalla profundo (Activision, parte de la evolución de SSGI).

10. Antialiasing temporal y reescalado mediante aprendizaje automático (DLSS, FSR, XeSS)

El fotograma se renderiza a una resolución interna inferior y se reconstruye mediante vectores de movimiento, profundidad y datos históricos. Los reescaladores basados en aprendizaje automático (DLSS 3/4, FSR 3, XeSS) añaden además generación de fotogramas, interpolando fotogramas intermedios a partir del flujo óptico. La mayoría de los títulos AAA se diseñan ya asumiendo que habrá un reescalador activado, lo que cambia cómo se distribuye el presupuesto de renderizado del resto del fotograma.

11. Renderizado controlado por la GPU y sombreadores de malla

El descarte, la selección de LOD y el envío de llamadas de dibujado se ejecutan íntegramente en la GPU. Los sombreadores de malla sustituyen la canalización de vértices, geometría y teselado por una etapa más flexible, similar a la de cómputo, que genera meshlets. En combinación con el dibujado indirecto múltiple, esto elimina por completo a la CPU del bucle crítico por objeto.

Análisis en profundidad:

• Haar y Aaltonen, Canalizaciones de renderizado controladas por la GPU (SIGGRAPH 2015, la charla fundacional sobre Assassin's Creed Unity).
• Wihlidal, Optimización de la canalización gráfica mediante cómputo (GDC 2016, descarte controlado por la GPU en Frostbite).
• Kubisch, Introducción a los sombreadores de malla de Turing (NVIDIA, introducción básica a los sombreadores de malla).
• Pesce, Un recorrido vertiginoso por los sombreadores de malla (y blogs de ingeniería similares recopilados en los análisis con RenderDoc de Adrian Courrèges).

12. Renderizado de cabello, tela y piel

El cabello utiliza sombreado anisotrópico al estilo Marschner con geometría basada en hebras (NVIDIA HairWorks, AMD TressFX o sistemas nativos del motor). La tela se simula en la GPU mediante dinámica basada en posiciones y se renderiza con reflejos especulares anisotrópicos. La piel utiliza dispersión subsuperficial en espacio de pantalla junto con iluminación envolvente preintegrada. Estos tres elementos suelen ser los que delatan la diferencia de presupuesto entre una producción AAA y una independiente.

Análisis en profundidad:

• Marschner et al., Dispersión de la luz en las fibras del cabello humano (SIGGRAPH 2003, el modelo fundacional de cabello).
• Chiang et al., Un modelo práctico y controlable de cabello y pelaje para trazado de trayectorias en producción (Disney 2016, ampliamente utilizado en aproximaciones en tiempo real).
• Müller et al., Dinámica basada en posiciones (la referencia estándar para la simulación de telas).
• Jimenez et al., Dispersión subsuperficial separable y Translucidez realista de la piel en tiempo real.

13. Calcomanías, texturizado virtual y capas de materiales

La variación de las superficies proviene de calcomanías superpuestas (agujeros de bala, suciedad, sangre y mugre) proyectadas sobre el búfer de profundidad, además de texturas virtuales que transmiten detalles de alta resolución justo cuando se necesitan. Las capas de materiales combinan varios conjuntos PBR por píxel mediante máscaras y proyección triplanar, logrando así que una sola roca parezca cinco distintas.

Análisis en profundidad:

• Pranckevičius, Calcomanías diferidas y artículos posteriores (la clásica serie del blog de Aras).
• Mittring, La tecnología detrás de la «demo Elemental de Unreal Engine 4» (SIGGRAPH 2012, incluye detalles sobre el texturizado virtual).
• van Waveren, Desafíos de id Tech 5: de la virtualización de texturas al paralelismo masivo (SIGGRAPH 2009, la charla sobre MegaTexture).
• Williams, Capas de materiales en The Order: 1886 (GDC 2014, materiales PBR por capas).

14. Transparencia independiente del orden

El cabello, el follaje, las partículas y el cristal no se pueden ordenar de forma limpia. Los motores AAA utilizan técnicas como OIT combinada y ponderada, pelado de profundidad o listas enlazadas por píxel para renderizarlos correctamente sin una fase de ordenación en la CPU. Aunque pase desapercibida, es una de las partes más costosas del fotograma en escenas con mucho follaje.

Análisis en profundidad:

• McGuire y Bavoil, Transparencia independiente del orden mediante combinación ponderada (JCGT 2013, el artículo sobre WBOIT).
• Bavoil y Myers, Transparencia independiente del orden mediante pelado doble de profundidad (informe técnico de NVIDIA).
• Yang et al., Construcción simultánea de listas enlazadas en tiempo real en la GPU (la referencia sobre listas enlazadas por píxel).
• Wyman, Exploración y ampliación del continuo de algoritmos OIT (HPG 2016, estudio comparativo).

15. Caché neuronal de radiancia y eliminación de ruido mediante aprendizaje automático

La capa más reciente. La caché neuronal de radiancia de NVIDIA aprende la iluminación indirecta de cada escena y la consulta en lugar de trazar más rayos. Los eliminadores de ruido mediante aprendizaje automático (OptiX, Intel Open Image Denoise o soluciones internas personalizadas) limpian en milisegundos las señales dispersas del trazado de rayos. Cabe esperar que esta categoría crezca rápidamente durante los próximos dos años.

Análisis en profundidad:

• Müller et al., Caché neuronal de radiancia en tiempo real para trazado de trayectorias (SIGGRAPH 2021, el artículo sobre NRC).
• Schied et al., Filtrado espaciotemporal guiado por la varianza: reconstrucción en tiempo real para iluminación global mediante trazado de trayectorias (HPG 2017, SVGF).
• Chaitanya et al., Reconstrucción interactiva de secuencias de imágenes de Monte Carlo mediante un autocodificador recurrente de eliminación de ruido (SIGGRAPH 2017, el primer eliminador de ruido recurrente basado en aprendizaje automático).
• Intel, Documentación de Open Image Denoise (eliminador de ruido de producción de código abierto).

Qué significa esto para el navegador

Hemos implementado varias de estas técnicas en WebGPU para nuestro motor de mundo abierto para navegadores. Los mapas de sombras en cascada, la instanciación controlada por la GPU, el PBR triplanar, la niebla en espacio de pantalla y el terreno virtualizado basado en clipmaps funcionan a 120 FPS en una pestaña. El resto (trazado de rayos por hardware, sombreadores de malla y escalado mediante aprendizaje automático) llegará a la web a medida que la especificación de WebGPU se ponga al día. Para profundizar, consulta nuestras guías sobre tecnología de mundos abiertos para navegadores y generación de paisajes.

Lecturas adicionales sobre toda la pila tecnológica

Si quieres leer un solo libro, Renderizado en tiempo real, 4.ª edición es la referencia estándar que abarca la mayoría de los temas anteriores. Para consultar investigaciones en curso, el archivo del curso de SIGGRAPH «Avances en el renderizado en tiempo real en videojuegos» (advances.realtimerendering.com) ofrece PDF gratuitos de análisis en profundidad de motores AAA que se remontan a 2006. Para conocer en detalle cómo renderizan sus fotogramas juegos concretos, los artículos de Adrian Courrèges sobre análisis de rendimiento de GPU son lectura obligatoria.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

La parte 17 proporcionó al jugador un conjunto de animaciones apto para el combate y una forma de incorporar al mundo cualquier modelo CC0. Esta parte vuelve al lado del creador. La paleta del Spike 34 coloca un objeto por clic, lo cual sirve para situar un objeto protagonista, pero no para crear un bosque. El Spike 37 es el pincel: arrastra sobre el terreno y los árboles llenarán los lugares donde deberían estar.

«Colocado por IA» sin una IA

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

La pregunta que responde este spike es si un pincel puramente heurístico resulta lo bastante inteligente como para prescindir del LLM. La prueba de que algo parece «colocado por IA» es concreta: los árboles se mantienen alejados de los acantilados, las rocas se inclinan siguiendo la pendiente y los guijarros de playa se detienen en la línea de agua, todo desde la primera pincelada. Lo conseguimos con predicados de pendiente y altitud, selecciones ponderadas y espaciado por familia, sin una sola llamada a un modelo.

El pincel funciona sobre un mapa de alturas de CPU de 257×257 con elementos ajustados a mano para que cada preajuste tenga algún lugar donde aplicarse: montañas al norte para las selecciones de pendientes mixtas, una franja de acantilados al este para los canchales, una llanura costera al sur para la playa y la pradera, y una cuenca lacustre al sudoeste. El terreno precalcula los colores de los vértices mediante un clasificador de biomas basado en (altitude, slope), de modo que antes de pintar un solo árbol ya puedes ver dónde se aplicará un preajuste. Se incluyen cinco preajustes como datos planos, cada uno con una lista de selecciones como { category, weight, slopeMin, slopeMax, altMin, altMax, minSpacing, alignToSlope }. Cliff and Scree establece slopeMin: 0.3 para que las rocas solo aparezcan en pendientes reales y alignToSlope: true para que el vector vertical de cada roca siga la normal de la superficie.

En cada pincelada, el motor de dispersión muestrea densityPerM2 × area puntos candidatos dentro del disco del pincel, lee la altura y la pendiente de cada candidato, filtra las selecciones del preajuste para conservar aquellas cuyos predicados se cumplen, elige una mediante selección ponderada y después comprueba el espaciado mediante un hash espacial dentro del radio. Todo es determinista: un generador aleatorio Mulberry32 con semilla controla cada selección, por lo que (seed, brush events) reproduce cualquier sesión con exactitud. En el terreno inicial, una pincelada de Mixed Forest sobre una pradera llana colocó 139 de 158 candidatos en 5 ms, mientras que el mismo preajuste sobre un acantilado solo colocó 106 de 226 y el HUD indicó que 81 habían sido rechazados por la pendiente. Ese desglose de rechazos constituye toda la experiencia de usuario: puedes ver por qué el acantilado solo aceptó unos pocos árboles en lugar de tener que adivinarlo.

La ventaja de mantener los preajustes como datos planos es que, cuando llegue la versión con LLM, bastará con sustituir un JSON en lugar de reescribir el sistema. A paint({ preset }) no le importa si preset.picks procede de una receta ajustada a mano o de un worker que convirtió «bosque caducifolio con rocas cubiertas de musgo» en ponderaciones. El motor tampoco codifica de forma fija ningún identificador de objeto, así que incorporar un catálogo distinto no requiere cambios en el motor.

De 300 llamadas de dibujo a 49

La primera versión renderizaba cada elemento colocado como un clone(true) de un grupo con varias mallas. Esto funciona bien con unos pocos cientos de objetos, pero se convierte en un límite al alcanzar el máximo de 2.500, cuando las llamadas de dibujo suben a varios miles. Antes de llegar a ese punto cambiamos a InstancedMesh, con un bucket por cada (propId, partIndex). Cada bucket crece duplicando su tamaño: se asigna un InstancedMesh mayor, se copian las matrices activas, se sustituye el padre de la escena y se libera el atributo anterior. El borrado usa intercambio con el último elemento, por lo que eliminar una instancia es O(1) independientemente del tamaño del bucket. El determinismo, el espaciado y el HUD de rechazos se mantienen sin cambios porque la sustitución ocurre por completo por debajo del registro de colocación.

Un diagnóstico del paquete MegaKit resolvió una cuestión arquitectónica real. Una malla glTF con varias primitivas —tronco y hojas— puede llegar a three.js como una sola malla con un array de materiales y geometry.groups, o como varias mallas hermanas independientes con un material cada una. Para este paquete, el cargador sigue la segunda ruta: cada parte es una malla de un solo material con los grupos vacíos. Esa estructura es mejor para la dispersión, porque tener buckets separados por primitiva permite que el bucket del tronco crezca de forma independiente al de las hojas si sus cantidades divergen. El número de llamadas de dibujo es el mismo en ambos casos, pero la separación ofrece una mejor distribución de memoria. La mejora medida se mantuvo: una pincelada de bosque que generaba unas 300 llamadas de dibujo pasó a 49, y una sesión completa con varias pinceladas alcanzó 3.221 instancias a 75 FPS con 51 llamadas de dibujo, un límite que la ruta de clonación nunca podría alcanzar antes de agotar el presupuesto por fotograma.

LOD por distancia y cuatro errores ocultos en él

El instanciado redujo las llamadas de dibujo, pero cada instancia seguía renderizando todos sus triángulos, incluso los árboles situados a 90 m que apenas aportaban dos píxeles de detalle en las hojas. Por eso precalculamos tres niveles de LOD por cada parte del objeto con meshoptimizer —completo, 50 % y 15 %—, ampliamos la clave del bucket a (propId, partIndex, lod) y añadimos un move() que traslada un elemento colocado entre buckets hermanos sin asignaciones. Las franjas de distancia son de 0 a 30 m, de 30 a 90 m y más allá, con ±4 m de histéresis alrededor de cada límite para que una cámara situada cerca del borde de una franja no mueva repetidamente un elemento de un lado a otro ni vuelva a subir su matriz en cada fotograma. La reevaluación está limitada a 4 Hz y solo se ejecuta si la cámara se ha movido realmente, por lo que una cámara inmóvil cuesta una sola comparación de distancia al cuadrado por fotograma.

En esa ruta de LOD se escondían los errores más instructivos. El primero se manifestó como elementos que desaparecían o se duplicaban al orbitar la cámara, y empeoraba a medida que se llenaba la escena. La causa era una matriz temporal compartida: move() leía la transformación de un elemento colocado en _tmpMat, definida en el ámbito del módulo, pero la eliminación mediante intercambio del bucket de origen usaba esa misma _tmpMat para su reorganización interna, sobrescribiendo la matriz transportada antes de que el destino pudiera escribirla. El error solo evitaba el caso en el que la posición trasladada ya era la última de su bucket, con una probabilidad aproximada de 1/count, lo que coincide exactamente con el «parpadeo poco frecuente que empeora a medida que crece la escena» observado durante las pruebas. La solución fue reservar una _carryMat exclusivamente para move(). Tras una prueba de estrés con 1.274 movimientos acumulados, el grupo se mantuvo idéntico píxel a píxel.

El segundo error era más sutil: todas las transiciones de LOD parecían fluidas excepto la primera. Los árboles que pasaban a LOD1 mostraban un cambio visible de sombreado aunque su silueta apenas variaba, mientras que reducciones mayores de triángulos en niveles posteriores se veían bien. El simplificador con LockBorder nunca mueve ni crea vértices, por lo que los vértices supervivientes conservan exactamente sus normales, pero aun así llamábamos a computeVertexNormals() después de cada simplificación. LOD0 devuelve intactas las normales originales creadas por el artista; LOD1 y los niveles posteriores recibían el recálculo genérico por promedio de caras de three.js. El límite entre 0 y 1 era el único punto de la escala donde cambiaba el régimen de normales, y por eso el salto aparecía allí. Eliminar esa única línea defensiva corrigió el sombreado y, como ventaja adicional, redujo aproximadamente a la mitad el tiempo de precálculo por objeto, porque dejamos de recalcular normales en cuatro LOD por cada parte.

La auditoría del resultado del simplificador reveló una tercera mejora. Cada LOD era un original.clone() con un índice nuevo, y BufferGeometry.clone() hace una copia profunda de todos los atributos, por lo que cinco LOD almacenaban cinco copias independientes de los búferes de posición, normales, UV y color cuyos valores eran idénticos bit a bit. Refactorizamos el sistema para compartir referencias a los atributos y mantener únicamente un búfer de índices privado por cada LOD, lo que redujo una parte de árbol típica de 20 identidades de atributos distintas a 9 y permitió subir cada búfer de vértices a la GPU una sola vez. El almacenamiento compartido impone dos condiciones: no modificar los datos de atributos desde ningún LOD individual y no ejecutar dispose() sobre la geometría de un solo LOD, ya que ambas acciones afectarían a todos los niveles hermanos que comparten el búfer.

El cuarto error no tenía nada que ver con pintar. El simple hecho de mover el cursor sobre el terreno reducía la velocidad de fotogramas, sin mantener pulsado ningún botón. El controlador pointermove lanzaba rayos contra la malla del terreno, un plano de 131.072 triángulos sin ninguna estructura espacial, por lo que three.js recorría todo el búfer de índices en cada evento, hasta 1.000 eventos por segundo. No necesitábamos la malla para esa consulta, porque el terreno es un mapa de alturas paramétrico. Una marcha de rayos adaptativa contra sampleHeight —pasos grandes muy por encima de la superficie, un mínimo de 0,4 m cerca de ella y después 12 bisecciones cuando cambia el signo— cuesta aproximadamente entre 8 y 30 muestras por rayo en lugar de 131.072 pruebas de triángulos, unas tres órdenes de magnitud menos, y al pasar el cursor vuelve a mantenerse el límite de fotogramas.

El coste solo se desplaza; asegúrate de sacarlo del clic

Después de cambiar el spike a WebGPURenderer en three r184 —el objetivo de producción—, un perfil de DevTools mostró que la primera pincelada bloqueaba durante 265 ms, con un 79 % del tiempo dentro del WASM de meshoptimizer. El precálculo realizaba trabajo real, unas 180 llamadas de simplificación para un preajuste en frío, pero se ejecutaba dentro del controlador del clic porque preloadProps solo descargaba y analizaba escenas, sin activar nunca el precálculo de LOD. La solución fue hacer que la selección del preajuste ejecutara el precálculo completo en segundo plano: ahora preloadProps llama a la ruta de resolución de partes, guarda en caché la promesa en curso para que un clic rápido se una a ella en lugar de iniciar un duplicado y memoriza el preprocesamiento por geometría que el simplificador repetía cuatro veces por cada parte. La primera pincelada bajó de 209 ms a 4 ms en el HUD. El tiempo del WASM no desapareció; simplemente salió de la ruta crítica del usuario y ahora se ejecuta mientras este observa el terreno y decide dónde pintar.

Esa es la lección recurrente de este spike. Casi ninguna de estas correcciones cambió lo que el pincel hace. Cambiaron cuándo se paga el coste: fuera del clic, fuera del movimiento del cursor y fuera del límite cerca del que se encuentra la cámara. Una herramienta de dispersión que parece instantánea no hace menos trabajo; hace el trabajo cuando el usuario no está esperándolo.

Tecnología mencionada en este capítulo

Dispersión heurística por idoneidad. Un pincel muestrea puntos candidatos dentro de un disco, lee (height, slope) por cada punto desde un mapa de alturas en la CPU, filtra las selecciones de un preajuste mediante predicados de pendiente y altitud, elige una de forma ponderada y la rechaza si infringe el espaciado mínimo por familia registrado en un hash espacial. Las selecciones alineadas con la pendiente giran su vector vertical para adaptarlo a la normal de la superficie. Esto genera una colocación que parece intencionada —árboles alejados de los acantilados, rocas inclinadas sobre las pendientes y guijarros que se detienen en la línea de agua— sin ponderaciones aprendidas, y mantiene el preajuste como datos planos para que una lista de selecciones generada por un LLM pueda sustituirla directamente.

Colocación determinista con cargas asíncronas. Un generador aleatorio Mulberry32 con semilla controla cada selección, por lo que (seed, brush events) reproduce una sesión con exactitud. Las extracciones aleatorias se producen antes de cualquier await, y las reservas de espaciado se insertan en el índice espacial antes de que se resuelva el clon de glTF, de modo que los candidatos concurrentes se respetan entre sí y la carga asíncrona de recursos no puede alterar la secuencia.

InstancedMesh organizados en buckets con ediciones O(1). Un InstancedMesh por cada (propId, partIndex, lod), cuya capacidad se duplica bajo demanda copiando las matrices activas en un búfer mayor. El borrado y la expulsión FIFO usan intercambio con el último elemento y corrigen en un array de referencias inversas el índice de la instancia trasladada, por lo que una eliminación es O(1) independientemente del tamaño del bucket. Un diagnóstico confirmó que las partes glTF llegan como mallas de un solo material, lo que convierte un bucket por primitiva en la ruta activa y proporciona a cada primitiva un bucket capaz de crecer de forma independiente.

LOD por distancia con histéresis y búferes de atributos compartidos. Tres niveles simplificados con meshopt por cada parte, seleccionados mediante franjas de distancia con ±4 m de histéresis para que una cámara cerca de un límite no alterne continuamente entre niveles, reevaluados a una frecuencia limitada y solo cuando existe movimiento real de la cámara. Como la simplificación con LockBorder nunca mueve los vértices, todos los LOD comparten un solo conjunto de búferes de posición, normales, UV y color, y solo se diferencian por su búfer de índices privado, lo que reduce aproximadamente a la mitad los búferes de vértices distintos en la GPU. Omitir un computeVertexNormals defensivo mantiene idénticas las normales creadas por el artista en todos los LOD y elimina la única discontinuidad de sombreado de la escala. Consulta LOD y meshoptimizer.

Lanzamiento de rayos analítico sobre el mapa de alturas para consultas de alta frecuencia. Una consulta del cursor a la frecuencia de pointermove contra la malla de un plano de 131.000 triángulos recorre todo el búfer de índices en cada evento. Sustituirla por una marcha de rayos adaptativa contra la función de altura analítica —pasos grandes lejos de la superficie, un mínimo pequeño cerca de ella y bisección cuando cambia el signo de $({\text{ray}}_y-{\text{terrain}}_y)$— cuesta decenas de muestras en lugar de decenas de miles de pruebas de triángulos, unas tres órdenes de magnitud menos, y un vector de salida preasignado mantiene la ruta crítica libre de asignaciones.

Sacar el trabajo de la ruta crítica de la interacción. El trabajo costoso que solo se realiza una vez —precálculos de LOD con meshopt, compilaciones de pipelines WGSL— debe ejecutarse durante los intervalos de inactividad, no dentro del controlador del clic. Precargar el cálculo completo del preajuste activo al seleccionarlo, almacenar en caché la promesa en curso para que un clic rápido se una a ella en lugar de iniciar otra y memorizar el preprocesamiento por geometría redujo la latencia de la primera pincelada de 209 ms a 4 ms sin disminuir el trabajo total realizado.

Parte 18 de 29. Anterior: Parte 17 - Animaciones que no necesitaron retargeting y una búsqueda de recursos en tiempo real Siguiente: Parte 19 - El impostor que tiene que sobrevivir a un bosque Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

¿Es tu primera vez aquí? Consulta la guía de la serie. Explica qué es un spike y enlaza todas las partes.

La parte 16 nos dio un mundo en el que colocar objetos. Esta parte ofrece al jugador algo mejor que hacer en él: un conjunto de animaciones apto para el combate y una forma de incorporar al mundo cualquiera de entre mil modelos CC0 con solo escribir una búsqueda.

262 clips, un esqueleto y tres correcciones de retargeting

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

El rig del jugador es un esqueleto 3MIKE al estilo CC4 con 213 huesos, incluidos un rig facial de más de 80 huesos y todas las articulaciones de los dedos. Las fuentes de animación no coinciden con él. La primera versión aplicaba retargeting a clips de combate de Mixamo seleccionados manualmente, pero el conjunto de fuentes era escaso y la locomoción estaba dividida de forma incómoda entre Mixamo y unas pocas animaciones de reposo BVH de Kimodo. El verdadero avance llegó cuando cambiamos la biblioteca de origen por los dos paquetes Universal Animation Library de Quaternius: 262 clips en total sobre un único maniquí coherente de 65 huesos al estilo UE5, con combos de espada, tiro con arco, escalada, carreras por paredes, esquivas, reacciones a impactos, gestos y un conjunto de locomoción mucho más limpio.

Eso supone pasar de una fuente de 65 huesos a un destino de 213, sin nombres de huesos, orientaciones en pose T ni proporciones de extremidades compartidos. Cada clip se reasigna en tres pasos: un mapa de nombres de huesos, una alineación de la pose de enlace para que ambos rigs compartan una orientación de referencia y un escalado de las pistas de posición para que el rig de origen, más bajo, no deje al personaje hundido hasta las rodillas en el suelo. Hacerlo bien implicó perseguir una serie de errores, cada uno de los cuales nos enseñó algo concreto.

El personaje aparecía excesivamente retorcido, con todos los hombros y codos girados unos 30° de más. La causa era una discrepancia de poses: la fuente UAL viene con una pose T real, la pose de enlace de CC4 es una pose A y el sistema de retargeting suponía que ambos rigs estaban en poses de referencia coincidentes, por lo que la diferencia entre A y T se añadía a cada delta por fotograma. La corrección fuerza la cadena de los brazos de CC4 a adoptar una pose T real para capturar el enlace y después aplica el retargeting, de modo que los deltas se mantengan pequeños.

Después, el cuerpo dejó de trasladarse. Los retrocesos desplazaban la parte superior del cuerpo, pero dejaban los pies clavados. UAL coloca el desplazamiento en el hueso root, no en la pelvis, por lo que leer la posición de la pelvis producía un movimiento casi nulo. La corrección suma root.position y pelvis.position, escala la parte horizontal y escribe una única pista de posición de la cadera. Al hacerlo descubrimos que los desplazamientos verticales se desviaban alrededor de un 12 %, porque habíamos usado la proporción global de las extremidades para el eje Y, cuando la altura de la pelvis necesita la proporción entre la cadera y el suelo. Dos proporciones, dos ejes: $\text{verticalRatio}=|\text{targetHipY}/\text{sourceHipY}|$ para Y y la proporción general para el plano horizontal. Se acabó el exceso de desplazamiento. Además, una sucesión de advertencias NaN de RL_BoneRoot.position resultó deberse a que asignábamos el root de UAL, situado en $Y=0$, a un hueso de destino cuya pista de posición se normaliza dividiéndola entre su Y de enlace. División por cero, NaN y pista descartada silenciosamente. La solución fue eliminar por completo la asignación de la raíz, ya que su traslación ya está incluida en la pista de la cadera.

La corrección más pequeña fue la más satisfactoria de ver. El personaje sujetaba la espada con los dedos flácidos de la pose de enlace porque el mapa de huesos no incluía entradas para los dedos, y el sistema de retargeting solo escribe pistas para los huesos asignados. Añadir 30 huesos de los dedos —cinco dedos, tres segmentos, dos manos, omitiendo el cuarto hueso auxiliar de la punta de UAL, que no deforma— hizo que la mano se cerrara sobre la empuñadura y se abriera al soltarla.

Verificar 262 clips sin tener que ver 262 clips

No se puede verificar visualmente una biblioteca de 262 clips, así que creamos una prueba de paridad de trayectorias sin conexión: un script de Node sin interfaz que carga cada paquete, muestrea el esqueleto de origen a 60 Hz, ejecuta el pipeline de retargeting y compara las posiciones y rotaciones globales de cada hueso con las de la fuente después del escalado. La deriva máxima de la pelvis en Y fue de 0,003 m. Las manos mostraban un desplazamiento constante de 2,5° que al principio interpretamos como «los dedos no siguen la animación», pero un desplazamiento constante es el delta de enlace entre la mano plana de UAL y la pose de enlace ligeramente curvada de CC4, y permanece invariable durante todo el clip. Los errores reales de animación se manifiestan como una deriva que varía de un fotograma a otro. Una vez aclarado esto, la prueba se convirtió en una comprobación de regresión de una sola pasada: si la deriva de un clip deja de mantener esa referencia constante, un cambio reciente ha roto el retargeting.

Un maniquí de referencia mostrado en paralelo hizo decisiva la parte visual de la depuración. Al pulsar la barra invertida aparece junto al jugador el rig de origen al que pertenece el clip actual, de modo que la pregunta «¿por qué está retorcido el hombro?» se convierte en «¿el giro está en la fuente o lo ha añadido el retargeting?». Las pruebas numéricas detectan regresiones, la referencia visual detecta errores de la pose de enlace que los números no revelan y, juntas, eliminaron las conjeturas.

Con el pipeline consolidado, cambiar la base de WASD, salto y natación de Mixamo a UAL solo requirió un pequeño mapa de alias: la máquina de estados finitos sigue usando nombres de estado genéricos como idle y walk, que se resuelven a nombres de clips de UAL durante la reproducción. La natación necesitaba desplazamientos de rig específicos para cada clip porque las poses de estilo libre y de mantenerse a flote anclan la pelvis a distintas alturas anatómicas, así que sumergimos el rig medio metro para la natación activa y algo más para mantenerse a flote, interpolando suavemente entre ambas a 5 Hz.

Escribe una palabra y obtén un modelo

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

El Spike 34 consumió un día entero seleccionando manualmente un paquete CC0. La solución a largo plazo es un cuadro de búsqueda. Polyhaven publica unos 1.100 modelos CC0 mediante una API JSON permisiva y una CDN determinista, y este spike conecta todo el recorrido —consulta, miniaturas, carga y renderizado— desde una página estática sin ningún paso de compilación, en unas 300 líneas de JavaScript puro más three.js.

Al iniciarse, descarga una vez el catálogo completo, de unos 600 KB. La búsqueda usa un sistema de puntuación puramente del lado del cliente —el nombre tiene prioridad sobre el identificador, este sobre la categoría y esta sobre la etiqueta— con un retardo de 120 ms, y muestra las 60 tarjetas principales. Las miniaturas se cargan de forma diferida mediante un IntersectionObserver, para que escribir no dispare 60 solicitudes a la vez. La parte interesante es la carga. El endpoint de archivos de Polyhaven expone glTF de varios archivos, no GLB, con texturas compartidas entre resoluciones y divididas en archivos separados, y devuelve un mapa include que relaciona cada ruta relativa con una URL absoluta de la CDN. En lugar de descargar y modificar nosotros mismos el JSON, pasamos ese mapa por LoadingManager.setURLModifier, que se ejecuta para cada dependencia que necesita el cargador —el .bin y cada textura— y la resuelve mediante la CDN. Un clic, un único archivo en apariencia. Tanto la API como la CDN establecen CORS permisivo, algo que verificamos con curl antes de escribir código de cliente, así que no hace falta ningún proxy. Los materiales PBR se renderizan correctamente con RoomEnvironment y los valores predeterminados del mapeo de tonos ACES, sin ajustes específicos por recurso, y las texturas de 1k mantienen un modelo típico entre 2 y 5 MB en lugar de los 20 a 40 MB de las texturas 4k.

Una pasada WASM de meshoptimizer completa el sistema con un reductor no destructivo: cada malla guarda un clon de su geometría original y, al cambiar la proporción, reconstruye un búfer de índices a partir de ese clon en lugar de simplificar de forma acumulativa. La geometría con varios materiales se simplifica por grupo y reconstruye geometry.groups para que las ranuras de materiales no colapsen. Un sillón pasa de 5.626 triángulos en calidad completa a 2.812 a la mitad.

Tecnología mencionada en este capítulo

Retargeting de esqueletos con alineación de la pose de enlace. Transferir una animación de un esqueleto a otro con distintos nombres de huesos, proporciones y poses de referencia requiere tres correcciones: un mapa de nombres de huesos, una alineación de la pose de enlace para que ambos rigs compartan una orientación de referencia —forzando la cadena de brazos en pose A del destino a adoptar la pose T de la fuente— y el escalado de las pistas de posición. Una discrepancia de poses añade la rotación de A a T a cada delta por fotograma, duplicando la rotación de las articulaciones. Los huesos auxiliares sin asignar deben descartarse, ya que un hueso raíz en $Y=0$ provoca una división silenciosa por cero al normalizar la pista de posición.

Dos proporciones de escala para un solo rig. El desplazamiento horizontal usa la proporción global de las extremidades —el tamaño total del esqueleto—, pero el desplazamiento vertical de la pelvis usa la proporción entre la cadera y el suelo $|\text{targetHipY}/\text{sourceHipY}|$, porque la proporción entre las piernas y el torso difiere entre rigs. Usar una sola proporción para ambos ejes hace que las escaladas se excedan y que las recuperaciones se hundan bajo el suelo. El desplazamiento de UAL también reside en el hueso root, no en la pelvis, así que ambos deben sumarse en una única pista de posición de la cadera para conservar el movimiento en clips de retroceso, escalada y locomoción.

Pruebas sin conexión de paridad de trayectorias. Un script sin interfaz muestrea el esqueleto de origen a 60 Hz, ejecuta el pipeline de retargeting y compara las transformaciones globales de cada hueso con la fuente. Un desplazamiento constante por fotograma es el delta de enlace inofensivo, mientras que una deriva que varía de un fotograma a otro es un error real; por eso, la prueba se convierte en una comprobación de regresión que se activa cuando un cambio elimina o distorsiona una pista. El aislamiento de los GLB por paquete —carga nueva y liberación antes del siguiente— evita la contención de caché durante el recorrido completo.

LoadingManager.setURLModifier para grafos glTF alojados en una CDN. Cuando una CDN distribuye glTF como un grafo de URI relativas acompañado de un mapa de inclusiones —ruta relativa a URL absoluta—, setURLModifier resuelve mediante la CDN cada dependencia solicitada por el cargador sin reescribir el JSON. Esto convierte una distribución de varios archivos y resoluciones en una carga con un solo clic. Liberar la geometría, los materiales y los mapas de texturas de cada modelo anterior antes de cargar el siguiente evita que se acumulen cientos de MB de memoria de GPU durante una sesión de exploración.

Simplificación no destructiva de mallas. Guardar un clon de la geometría original de cada malla y reconstruir solo el búfer de índices para cada proporción de simplificación mantiene los cambios rápidos y evita los daños acumulativos de simplificaciones repetidas. Ejecutar el proceso por cada sección de geometry.groups y reconstruir los grupos conserva las asignaciones de varios materiales. Consulta LOD y meshoptimizer para ver cómo se integra esto en el LOD basado en la distancia.

Parte 17 de 29. Anterior: Parte 16 - Estructura para un mundo que no deja de crecer Siguiente: Parte 18 - Un pincel de dispersión que parece guiado por IA Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Mariana Muntean, CEO de Cinevva

Lo que más suelen decir quienes descubren Cinevva es que se trata de una capa sobre una IA. Llegan a la página de inicio, ven un único cuadro de texto que dice «Describe tu juego» y creen que ya han entendido el producto. Han entendido la puerta de entrada. El producto es todo lo que no ves cuando escribes esa frase y, desde esta semana, también un mundo abierto en el que tus jugadores entran para encontrar tu juego.

Detrás de ese cuadro hay un motor de juegos completo, un orquestador con 26 herramientas tipadas, una flota de modelos generativos, una búsqueda agregada de recursos entre once proveedores, un iframe con el juego en vivo que el agente puede leer y modificar, y un escaparate donde ese mismo agente publica tu juego terminado como un vídeo de gameplay que se puede deslizar. Nada de eso es exótico. Todo es infraestructura. El trabajo interesante consistió en decidir qué conectar con qué.

Este artículo recorre la máquina de arriba abajo. Es la explicación que damos a los inversores técnicos y también a los desarrolladores que están pensando en contribuir. Ambos quieren la misma respuesta.

1. El prompt es la superficie, no el sistema

La primera decisión de diseño fue ocultarlo todo hasta que el usuario ya tuviera algo en juego. La página de inicio tiene una sola función: tomar una frase y convertirla en un proyecto. Dividimos la experiencia en una parte pública (el prompt, las muestras y el feed del escaparate) y otra para creadores (el IDE, las herramientas de recursos y el flujo de publicación), para que quienes solo quieren jugar no tengan que mirar la cabina de mando.

Por eso el texto de ejemplo va alternando entre frases como «Crea un juego de la serpiente con gráficos de neón» y «Shooter de zombis con vista cenital». No son tutoriales. Son una invitación. El usuario entiende que una «idea extraña para un arcade» es una entrada válida.

En cuanto lo envías, ocurren tres cosas. El sistema crea un proyecto de juego nuevo con un ID estable. Inicializa un árbol de archivos vacío (index.html, game.js, style.css, assets/, GDD.md). Y dirige tu frase al orquestador junto con una ventana de contexto del proyecto que apunta a esos archivos vacíos. A partir de ahí, hablas con un agente que tiene manos.

2. Detrás del campo de texto, un IDE completo en el navegador

El espacio de trabajo para creadores es un IDE de tres paneles que se ejecuta por completo en el navegador. El árbol de archivos está a la izquierda, el editor de código en el centro, el iframe con el juego en vivo a la derecha y, en la parte inferior, un campo de chat. Elegimos esta disposición deliberadamente. Quienes ya programan la reconocen al instante. Quienes no, pueden ignorar el panel central y comunicarse únicamente mediante el chat.

El árbol de archivos no es una metáfora. Cada proyecto es realmente un pequeño sitio estático compuesto por HTML, JS, CSS, imágenes generadas, modelos GLB y archivos de audio, servido directamente desde R2 mediante un Cloudflare Worker. No hay ningún paso de compilación. La razón es importante. Significa que el agente puede leer y modificar los archivos que publicarías realmente, y que el mismo artefacto funciona en el iframe, en un teléfono envuelto con Capacitor, en Steam envuelto con Tauri y dentro de Discord como Embedded Activity. Un sistema de archivos, seis destinos de distribución.

Todos los juegos que generamos deben exponer dos funciones en window. getGameState() devuelve un objeto sencillo que describe el juego en ejecución (posición del jugador, puntuación, vidas, enemigos y temporizadores). setGameState(patch) aplica una actualización parcial al juego en vivo. Esa pequeña API es el contrato que permite al agente inspeccionar y modificar un juego en ejecución sin recargarlo. Volveremos al motivo en la sección 6.

3. El orquestador, donde reside el motor propiamente dicho

Lo que no entienden quienes llaman a esto «una capa sobre una IA» es que la IA no escribe código tanto como dirige una pequeña orquesta. El orquestador es un bucle de llamadas a herramientas que se ejecuta sobre un modelo de vanguardia, con un prompt de sistema de unas mil líneas y una interfaz tipada de 26 funciones. Las definiciones de las herramientas son el motor. El modelo es el director.

Las 26 herramientas se dividen en cinco familias. Las herramientas del sistema de archivos (list_game_files, read_files, search_game_file, edit_files, write_files, delete_files, rename_files) permiten al agente tratar tu juego como cualquier otro repositorio de código. Las herramientas de proyecto (create_new_game, list_games, open_game, ask_user, game_ready) gestionan el ciclo de vida de un proyecto y la devolución del control a la persona. Las herramientas generativas (generate_image, generate_skybox, generate_music, generate_sfx, rig_model, apply_animation, list_animations, list_skybox_styles) llaman a modelos especializados que veremos a continuación. Las herramientas de conocimiento (search_fonts, list_library_docs, search_library_docs, list_generations) proporcionan al agente fuentes fiables e indexadas, en lugar de API alucinadas. Y las herramientas de ejecución (read_console_logs, execute_js) permiten al agente ver y manipular el juego en vivo.

Un primer turno típico es más o menos así. El usuario escribe «Crea un shooter espacial de neón». El modelo emite una llamada a write_files con un GDD.md que describe el diseño y después vuelve a llamar a write_files con index.html, game.js y style.css. Llama a generate_music con prompt="shooter espacial synthwave, 120 BPM, línea de bajo enérgica", lo que inicia un trabajo en ElevenLabs Music y devuelve una URL de MP3 dentro de R2. Llama a generate_skybox con un estilo del modelo 3 de Blockade Labs para crear el campo estelar. Llama a game_ready(title, message) para cambiar el iframe a la nueva versión y, por último, a read_console_logs para confirmar que el juego se inició sin errores. Si detecta una traza de pila, vuelve a edit_files y la corrige antes de que el usuario tenga que informar de nada.

La propiedad interesante de este diseño es que el prompt del sistema y los esquemas de las herramientas son lo único específico del producto. Si cambias el modelo, todo sigue funcionando. Durante el último año hemos migrado entre tres modelos de vanguardia sin modificar la interfaz, porque la interfaz es nuestra.

4. La parte de los recursos: distribución entre modelos

El agente no genera imágenes, música, sonido ni modelos 3D. Recurre a especialistas. La parte de recursos de Cinevva distribuye el trabajo entre los mejores modelos de su clase, conectados de modo que la salida de uno sea una entrada válida para el siguiente.

Para imágenes y sprites, generate_image llama a Flux Pro 1.1 con una anchura y una altura que siempre son múltiplos de 32, y un formato de salida que cambia a PNG cuando el prompt solicita transparencia. Para canciones completas, el agente llama a ElevenLabs Music con un prompt estilístico y una duración en segundos. Para efectos puntuales, ElevenLabs SFX produce en entre cinco y quince segundos un clip a partir de texto como «disparo de pistola láser, bláster de ciencia ficción». Para entornos de 360 grados, generate_skybox llama a Blockade Labs con uno de unos noventa estilos y utiliza de forma predeterminada Digital Painting del modelo 3. Para personajes 3D, rig_model envía un GLB a Tripo para añadirle esqueleto y rig como criatura bípeda, cuadrúpeda, hexápoda, octópoda, serpentina o acuática; después, apply_animation reproduce cualquiera de los quince preajustes (reposo, caminar, correr, saltar, escalar, bucear, atacar con arma blanca, disparar, recibir daño, caer y girar, además de las marchas para criaturas no bípedas).

Cada una de estas operaciones es un trabajo, no una llamada síncrona. Tardan desde segundos hasta minutos. El orquestador las inicia, devuelve inmediatamente un jobId y un canal independiente incorpora el resultado a la conversación cuando el recurso está listo. Esto cambia por completo la experiencia. El agente puede seguir creando la lógica del juego mientras un modelo 3D termina de prepararse en segundo plano. El usuario nunca tiene que esperar por una única ruta crítica.

Todos los artefactos terminan en el mismo lugar: R2, detrás de cdn.cinevva.com, accesibles mediante URL normales. Esto significa que la siguiente llamada del agente a write_files puede limitarse a insertar <audio src="https://cdn.cinevva.com/audio/abc.mp3"> y el juego funciona sin más. Sin SDK, sin empaquetador de recursos y sin manifiesto.

5. Búsqueda de recursos entre once proveedores

La generación es excelente cuando necesitas algo específico. La búsqueda es más rápida cuando ya existe lo que necesitas. La Biblioteca de recursos es una búsqueda federada entre once proveedores de recursos gratuitos y con licencia, cuyos resultados se presentan en un único feed ordenado por relevancia.

El registro de proveedores reside en el worker y ejecuta cada consulta en paralelo en PolyHaven, Sketchfab, Freesound, Kenney, AmbientCG, Quaternius, OpenGameArt, la colección 3D del Smithsonian, TurboSquid, Synty y Jamendo. Cada proveedor implementa una interfaz común (search, getMetadata, isBrowsable, getSupportedTypes), por lo que añadir uno nuevo solo requiere un archivo TypeScript. La capa de agregación gestiona la paginación mediante cursores entre proveedores que paginan de forma distinta, elimina licencias duplicadas, normaliza los tipos de recursos en una taxonomía común (modelo, textura, audio, HDRI y sprite) y etiqueta cada recurso con su licencia para que el agente nunca elija algo que no pueda redistribuir.

Cuando ChatGPT recomendó esta herramienta el trimestre pasado como uno de los mejores buscadores gratuitos de recursos para desarrolladores de juegos, fuimos a leer la recomendación. Acertaba en lo importante. La cuestión no es que tengamos una barra de búsqueda para una única biblioteca. La cuestión es que un desarrollador independiente que busca «textura de muro de piedra» obtiene, con una sola consulta y metadatos de licencia coherentes, resultados de PolyHaven y AmbientCG junto a la versión estilizada de Kenney y una opción de fotogrametría del Smithsonian. El agente puede consultar el mismo endpoint y elegir recursos del mismo modo que lo haría una persona.

Esta es la parte del motor que suele infravalorarse. La mayoría de las demostraciones de IA para juegos lo generan todo desde cero y terminan con un aspecto uniforme, brillante y ligeramente inquietante. Los juegos interesantes de Cinevva combinan recursos generados con fotogrametría CC0 real del Smithsonian y un árbol low poly hecho a mano por Quaternius. El orquestador puede hacerlo en un solo turno.

6. El agente juega al juego

Esta es la parte que más sorprende a la mayoría de los ingenieros cuando se la mostramos. El agente no se limita a escribir código en archivos. Ejecuta el juego en un iframe aislado, lee su consola, toma capturas de pantalla por capas para distinguir la interfaz de usuario de la escena 3D y ejecuta JavaScript dentro del entorno en vivo para inspeccionar o modificar el estado. read_console_logs devuelve las últimas cincuenta líneas de console.log, console.warn, console.error y las excepciones no capturadas del iframe. Después de cada llamada a game_ready, el prompt del sistema exige que el agente llame a read_console_logs y corrija cualquier error antes de entregar el resultado al usuario. Esa única regla elimina la mayoría de los fallos del tipo «la IA dijo que había terminado, pero la pantalla está en negro» que sufren otras herramientas.

execute_js es la herramienta más potente. Ejecuta JavaScript arbitrario dentro del ámbito global del juego. Como todos los juegos deben implementar getGameState y setGameState, el agente puede ejecutar JSON.stringify(getGameState()) para leer el estado completo del juego en ejecución y después usar setGameState({player: {x: 500, y: 100}}) para teletransportar al jugador, setGameState({lives: 99}) para concederle invencibilidad o setGameState({level: 3}) para saltar a un nivel posterior. También puede inspeccionar capas de más bajo nivel, por ejemplo con scene.children.map(c => c.type) para examinar el grafo de escena de Three.js o con document.querySelectorAll('canvas').length para confirmar que el renderizador se ha montado.

Es fácil ver por qué esto importa. Cuando un usuario dice «el jugador se queda atascado en la pared del segundo nivel», el agente no tiene que adivinar. Abre el segundo nivel, ejecuta getGameState(), examina los datos de colisión, aplica un parche con execute_js para probar una solución y solo entonces escribe la corrección en el disco. Depura como lo harías tú. Tratamos el iframe como un igual, no como un objetivo.

7. Documentación de bibliotecas: la aburrida fuente de la verdad

Indexamos la documentación oficial de las bibliotecas que realmente usan los juegos (Three.js, Tone.js, Cannon y cada vez más) en un repositorio JSON estructurado y con función de búsqueda. El agente recurre a search_library_docs("threejs", "Mesh") antes de acudir a la web abierta. Es más rápido, está versionado y nunca se inventa un método cuyo nombre cambió hace dos versiones menores.

No es algo espectacular. Es la diferencia entre una IA que produce código funcional y una IA que produce código de apariencia convincente que falla en la línea cuarenta. Gran parte de la calidad visible de los juegos creados con Cinevva procede de esta única decisión.

8. De jugable a descubrible: reels y escaparate

Un juego al que nadie juega es un pasatiempo privado. El problema más difícil aún sin resolver del desarrollo independiente ya no es crear juegos. Es distribuirlos. Por eso el motor no se detiene en «jugable». Se detiene en «delante de los jugadores».

Cada proyecto de Cinevva tiene una URL estable para compartir, como play.cinevva.com/{game-id}, que abre la última versión del juego en un iframe a página completa con una pequeña superposición para indicar «Me gusta» y compartir. Cuando el agente llama a game_ready, no se limita a activar la vista previa del IDE. También ofrece publicar un reel de 15 segundos de la partida en el escaparate de Cinevva. El reel es una grabación real del juego en acción, capturada directamente desde el iframe (incluimos un pequeño script de grabación que el agente inyecta en el entorno de ejecución del juego), de modo que lo que el espectador ve al desplazarse es una partida real, no un montaje de marketing.

Eso cambia el ciclo en el que vive un desarrollador. El ciclo anterior era programar, compilar, empaquetar, subir, escribir una página de Steam, pelearse con un algoritmo y mirar un contador de listas de deseos. El nuevo ciclo consiste en escribir una frase, ver cómo el agente construye el juego, pulsar «Publicar» y ver cómo aparece en el mismo feed vertical junto a todos los demás. El descubrimiento ocurre en el mismo producto en el que ocurre la creación, con la misma URL y el mismo inicio de sesión.

Para quienes forman parte de la comunidad de desarrollo, esta es la parte que conviene examinar. La distribución siempre ha sido la ventaja competitiva que los motores de juego no incluían. Unity proporciona un editor; tú publicas el juego en Steam. Unreal proporciona un editor; tú publicas en Epic Store. Cinevva ofrece ambas mitades. El motor y el escaparate se comunican mediante el mismo orquestador que creó el juego.

9. Mejores juegos: el volante de inercia del descubrimiento

El feed de reels es una mitad del volante de inercia. La clasificación de mejores juegos es la otra. Clasifica los juegos por tendencias, novedades y mejores de todos los tiempos, ponderados según la tasa de finalización (si el jugador terminó una sesión) en lugar de por los clics brutos. La finalización es más difícil de manipular que las instalaciones. Un juego que mantiene la atención durante sesenta segundos supera a uno que se abre y se cierra de inmediato.

Cada señal vuelve a alimentar el siguiente turno del orquestador. Cuando el agente dice «añadamos un potenciador», no está recurriendo a una biblioteca fija de patrones. Recurre a un modelo que ha observado qué mecánicas están consiguiendo retener jugadores en Cinevva este mes. El volante de inercia no es una gráfica al final de la página. Es la señal de entrenamiento de todo el motor.

Para los inversores, este es el foso de datos. No solo tenemos juegos generados. Tenemos juegos generados con métricas reales de interacción en cada sesión, vinculadas a los prompts que los produjeron, a los recursos que eligió el agente y a los jugadores a quienes les gustaron. Cada ciclo refuerza el siguiente.

10. El motor se convierte en un juego

Esta es la parte que llevo meses insinuando en redes sociales. Todo lo descrito en las secciones 1 a 9 corresponde a un sistema que crea juegos. Lo más difícil de explicar, hasta que se ve, es lo que ocurre cuando el propio sistema se convierte en un lugar.

Crear juegos es un trabajo difícil, incluso con todo lo que hemos desarrollado. Si nunca has creado uno, de repente eres responsable de la trama, los personajes, el mundo, las mecánicas, quién hace qué y cuándo, el comportamiento de la luz, la superposición de los efectos especiales, la música, los efectos de sonido y los movimientos de cámara. Es mucho. Y, además, quieres que el resultado parezca tuyo, no una plantilla escupida por la herramienta de otra persona. El prompt y el orquestador se encargan de la mayor parte del trabajo mecánico. Lo que no pueden hacer por sí solos es ofrecer a tu creación terminada un escenario en el que mostrarse mientras otras personas la contemplan.

Así que construimos el escenario. Durante la mayor parte de este año, Oleg y el equipo del motor han ido publicando su trabajo en una serie de 14 partes sobre cómo llevar un mundo abierto al navegador. Terreno esculpido que puedes modificar en tiempo real. Biomas que se pintan automáticamente con roca o hierba según la pendiente y la altitud. 80 000 briznas de hierba que se mecen con el viento sobre terreno generado mediante cómputo. Un personaje que camina, corre, salta y planea tanto sobre terreno de mapas de altura como sobre terreno volumétrico con el mismo sistema de movimiento. Nada de esto era una demostración técnica hecha porque sí. Era la base de todo esto.

Hoy, el mundo abierto ya está disponible en una versión preliminar. Eliges un avatar y entras. Tus juegos publicados aparecen a tu alrededor como espacios que puedes visitar, igual que ahora aparecen en los reels del escaparate y en la clasificación de mejores juegos, salvo que llegas caminando en vez de deslizando el dedo. Puedes entrar en el juego de un desconocido desde el mundo sin salir de él. Puedes colocarte junto a la persona que creó lo que acabas de jugar y contarle qué añadirías a continuación. Puedes esculpir un fragmento de terreno con alguien a quien acabas de conocer y convertirlo en la semilla de un nuevo proyecto. El descubrimiento deja de ser un feed. Se convierte en un paseo.

Nuestro motor siempre ha sido un motor de juego en el sentido técnico. Hoy también se convierte en uno en el sentido literal. Lo que crea tu juego ahora es un juego en sí mismo, y el mismo orquestador de la sección 3, los mismos canales de recursos de la sección 4, el mismo contrato getGameState de la sección 6, los mismos reels de la sección 8 y la misma clasificación de la sección 9 se integran en el único lugar por el que caminan tus jugadores. La frontera entre crear y jugar siempre fue artificial. Ahora ha desaparecido.

Lo que creemos haber hecho bien

Lo primero que hicimos bien fue tratar el prompt como un recurso de interfaz en lugar de como un producto. El producto es el orquestador, el conjunto de herramientas, los canales de recursos y el escaparate. El prompt es la forma más sencilla posible de introducir a un usuario en el sistema.

Lo segundo fue insistir en un sistema de archivos plano y nativo del navegador, sin ningún paso de compilación. Por eso un juego de Cinevva puede distribuirse en móviles, ordenadores, Steam y Discord desde una única fuente de verdad. Por eso el agente puede leer lo que ha escrito.

Lo tercero fue el contrato por el que todos los juegos generados implementan getGameState y setGameState. Esa única línea del prompt del sistema es lo que hace que el agente parezca un colaborador en lugar de un generador de código. El agente puede jugar, y un sistema que puede jugar también puede depurar.

Lo cuarto fue integrar el escaparate en el mismo ciclo que el motor. No vamos a ganar por la calidad bruta del modelo. Llevar dos meses de ventaja a un generador de pesos abiertos no constituye ninguna ventaja defendible. Ganamos cuando el mismo agente que crea tu juego también lo publica, lo mide y aprende de cómo lo jugaron desconocidos.

Si quieres ver toda la máquina en movimiento, el prompt de la página de inicio sigue siendo la puerta de entrada. Escribe una frase. Observa lo que ocurre detrás. Después vuelve aquí y dinos sobre qué parte del motor deberíamos escribir a continuación.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Todos los spikes desde la parte 13 habían seguido la misma receta: copiar el monolito anterior y añadir una función. Al terminar el spike 32, ese monolito era un index.html de 6285 líneas dentro de un único <script type="module">. Las búsquedas de código producían demasiado ruido, encontrar dónde añadir una función llevaba más tiempo que escribirla y cualquier cambio arquitectónico afectaba a un archivo demasiado grande para abarcar mentalmente el diff. Antes de añadir otra función, pusimos la estructura en orden.

Dividir el monolito sin cambiar el comportamiento

Abrir el spike 33 en una pestaña nueva ↗ · Ver el código fuente

La restricción era estricta: cada división debía ser una refactorización pura, no un rediseño. El monolito se convirtió en 19 archivos .mjs más un shell principal de 151 líneas. Módulos de nivel superior para la escena, el agua, la hierba, el personaje, la física, el multijugador y la interfaz; un wgsl.mjs que contiene todas las cadenas de código fuente WGSL como única fuente de verdad para la GPU; y un subárbol terrain/ para el mapa de alturas, el SDF, los chunks, los wrappers de búferes de GPU, el pincel, el LOD y la persistencia. El total quedó en 6555 líneas, básicamente el monolito más el código repetitivo de las importaciones. Ningún cambio neto de volumen y un gran cambio en facilidad de navegación.

Entonces la página cargó con la pantalla en negro. Dos mensajes de error, dos causas raíz sin relación entre sí. El primero era una queja de WebGPU sobre un binding de búfer de cero bytes. En el monolito, el búfer del pincel SDF se asignaba de forma diferida cuando aparecía el primer chunk de marching cubes, y la fábrica de grupos de bindings se ejecutaba después, una vez que el búfer ya existía. Separar terrain/gpu.mjs de terrain/brush.mjs cambió el orden de evaluación de los módulos, así que la fábrica pasó a ejecutarse primero e intentó enlazar un marcador null. La solución fue posponer la creación del grupo de bindings hasta el primer dispatch mediante un helper getOrCreateBindGroup(chunk). El patrón de «crearlo todo por adelantado» era un artefacto de la ruta de inicialización única del monolito.

El segundo mensaje era una alarmante advertencia sobre un esqueleto FBX que resultó ser una pista falsa. Se mostraba desde el spike 25 y era inofensiva. El personaje solo faltaba porque el primer error se propagaba: cada dispatch de cómputo lanzaba una excepción, el mapa de alturas nunca se escribía, las muestras de altura devolvían 0 y el personaje aparecía en el origen y caía a través del mundo. Al arreglar el búfer, el personaje se animaba correctamente, con advertencia incluida.

Esa es la verdadera lección de la refactorización. El monolito ocultaba todas las relaciones del tipo «X debe existir antes de construir Y» dentro del orden de arriba abajo del script. La modularización alteró ese orden y sacó a la luz otros tres errores latentes de ordenación: la dispersión de hierba antes de subir el mapa de alturas, la adición del plano de agua antes de que terminara de decodificarse el mapa de entorno y la carga de la persistencia después del primer fotograma. Los tres se arreglaron con una sola línea y ninguno se habría detectado sin la división.

Cien objetos sin hacer crecer nada

Abrir el spike 34 en una pestaña nueva ↗ · Ver el código fuente

El spike 34 fue la prueba para comprobar si la estructura había valido la pena. El objetivo era crear una paleta en primera persona para colocar árboles, rocas, arbustos, setas y caminos procedentes de un paquete de modelos CC0, con alineación adaptada al terreno, persistencia, sincronización multijugador y colliders físicos, todo ello sin soltar los controles. Cada línea de código nueva se añadió en cinco archivos nuevos dentro de src/props/, y ningún módulo existente creció más de diez líneas de conexión.

El recorrido de los recursos dio un rodeo que merece la pena documentar, porque es el tipo de cosa que consume un día entero. Empezamos con el paquete Ultimate Nature de Quaternius, una biblioteca FBX sin texturas incrustadas. Los materiales FBX venían como MeshPhong sin mapa, así que conectamos una tabla manual de nombres de materiales a archivos PNG, convertimos Phong a Standard y configuramos los espacios de color a mano. Alrededor del 30 % de los materiales no tenía un PNG correspondiente y varios nombres eran ambiguos entre árboles similares. Un segundo paquete FBX presentaba el mismo problema. La solución no era crear más tablas de correspondencias, sino usar un paquete mejor preparado: Stylized Nature MegaKit de Quaternius incluye 116 glTF completos con materiales PBR incrustados y normales precalculadas. Cambiar FBXLoader por GLTFLoader eliminó el escalado de centímetros a metros, la tabla de texturas y la conversión de Phong, y redujo library.mjs en unas 80 líneas. La conclusión: glTF con PBR es el pipeline adecuado para los paquetes CC0 que lo ofrecen, mientras que FBX con asignación manual de texturas requería el doble de código para obtener la mitad de calidad.

La ruta de glTF también trajo algunos problemas delicados. La paleta renderiza 116 miniaturas, y canvas.toDataURL() de WebGPU devuelve una imagen vacía para una superficie GPUCanvasContext, por lo que las miniaturas se renderizan en un RenderTarget, se leen con readRenderTargetPixelsAsync y se copian en un canvas 2D, teniendo en cuenta la alineación de filas de 256 bytes de WebGPU. Las previsualizaciones fantasma clonan cada material para teñirlo de verde, lo que fallaba en las mallas cuyo material era un array; se corrigió con una rama Array.isArray. Además, los mapas de normales de 16 bits, que ocupaban unos 200 MB, se redujeron una sola vez con mogrify -depth 8 hasta unos 32 MB, sin diferencias visuales, ya que los navegadores reducen su resolución durante la carga de todos modos.

Cuando la geometría renderizada solo existe en la GPU

El error más instructivo hacía que la previsualización fantasma saltara en incrementos de entre 1 y 2 metros al mover el cursor. Las mallas del terreno almacenan las posiciones de los vértices en un StorageBufferAttribute porque el pipeline de cómputo las escribe directamente en la GPU, de modo que el Raycaster de CPU de three.js no puede verlas y no devuelve nada. La alternativa era un ray marching aproximado con pasos de 1,5 m contra el mapa de alturas analítico, y ese intervalo fijo era la cuadrícula que veía el usuario. Lo sustituimos por un recorrido adaptativo: pasos de 2,5 m cuando el rayo está muy por encima de la superficie, reducción a 0,4 m al encontrarse a menos de 5 m y, después, 14 bisecciones cuando cambia el signo de $({\text{ray}}_y-{\text{terrain}}_y)$. Así se obtiene una precisión inferior al milímetro con unos 30 pasos amplios más 14 bisecciones por lanzamiento. Cuando la geometría renderizada solo existe en la GPU, no luches contra el raycaster: recorre la fuente analítica.

Colliders que siguen siendo fieles tras las ediciones

Elegimos proxies primitivos en lugar de envolventes convexas o colliders de malla. Los objetos de Quaternius son redondeados y de bajo número de polígonos, sin concavidades relevantes, por lo que las envolventes requerirían aproximadamente 50 veces más código y multiplicarían por 10 el coste en tiempo de ejecución para ofrecer la misma experiencia de juego. Cada objeto se reduce a una forma derivada de su caja delimitadora: árboles y cactus se convierten en una cápsula vertical, rocas en una esfera, troncos en una cápsula horizontal a lo largo de su eje mayor, y los arbustos y flores decorativos no tienen collider. Se puede caminar sobre las rocas y los troncos —empuje solo vertical para poder ponerse encima—, mientras que los árboles y cactus bloquean el paso —empuje 3D completo para impedir trepar por un tronco—. Un hash espacial de 8 m limita la comprobación por fotograma al vecindario de 3×3 del jugador, normalmente entre cero y seis objetos.

Dos decisiones de diseño mantuvieron la coherencia del sistema. La alineación con el terreno es un indicador del manifiesto, no un enum de categorías fijado en el código, por lo que tanto la previsualización fantasma como la colocación confirmada leen el mismo valor placement.alignToTerrain y no pueden discrepar. Además, los objetos colocados reaccionan a las ediciones del terreno mediante un único helper: después de una pincelada —local o reproducida desde otro par—, refreshPlacementsInRadius vuelve a muestrear el suelo bajo cada objeto dentro del disco afectado, reaplica la alineación y vuelve a derivar los extremos del collider. Esculpe una colina debajo de un árbol y el árbol ascenderá con ella. La persistencia y el multijugador reutilizan exactamente el patrón del spike 31: almacenan una lista plana de {uid, propId, x, y, z, rotY, scale} y replican los eventos de colocación, eliminación y ajuste mediante BroadcastChannel.

Tecnología mencionada en este capítulo

Descomposición en módulos ES con WebGPU. Dividir un <script type="module"> monolítico en importaciones .mjs con rutas directas no requiere un empaquetador cuando los módulos se sirven como recursos estáticos, y TSL de three.js funciona sin problemas entre módulos. El coste oculto es el orden de inicialización: un monolito codifica «construir X antes que Y» mediante el orden de arriba abajo del script, mientras que los módulos se evalúan según el orden de importación, lo que puede ejecutar una fábrica de grupos de bindings de GPU antes de que exista su búfer. El patrón de solución es la inicialización diferida (getOrCreate... en el primer uso) y esperar la promesa adecuada en lugar de depender del orden de declaración.

glTF con PBR incrustado frente a FBX con asignación manual. glTF utiliza metros, referencia sus propias texturas y proporciona directamente MeshStandardMaterial, por lo que un paquete CC0 creado como glTF se integra directamente en un pipeline PBR. Los paquetes FBX sin metadatos de vinculación de texturas requieren una tabla manual de nombres de materiales a archivos PNG que queda desactualizada con cada actualización del paquete, además de una conversión de Phong a Standard y el etiquetado manual del espacio de color. Como red de seguridad para el follaje, los materiales transparent sin alphaTest se convierten en tarjetas recortadas con alphaTest: 0.5, para que se ordenen correctamente detrás de la geometría opaca.

Miniaturas fuera de pantalla con WebGPU. canvas.toDataURL() devuelve una imagen vacía para un canvas respaldado por GPUCanvasContext porque no existe una ruta desde una superficie de presentación hasta un contexto 2D. Renderizar en un RenderTarget, leer los píxeles con readRenderTargetPixelsAsync y copiarlos en un canvas 2D funciona, siempre que la copia avance según el stride de lectura alineado a 256 bytes de WebGPU. Los resultados se almacenan en caché en localStorage bajo una clave cuya versión se incrementa para que los cambios en el paquete invaliden los renderizados obsoletos.

Ray marching adaptativo contra un mapa de alturas analítico. Cuando los vértices del terreno viven en un StorageBufferAttribute de la GPU, el raycaster de CPU no puede verlos. Recorrer la función de altura analítica con pasos grandes lejos de la superficie, pasos pequeños cerca de ella y un refinamiento mediante búsqueda binaria cuando cambia el signo de $({\text{ray}}_y-{\text{terrain}}_y)$ proporciona al cursor una precisión inferior al milímetro con un número acotado de muestras. La misma primitiva se utiliza para el cursor del pincel y el objeto fantasma.

Colliders de cápsula primitivos con un hash espacial. Cada objeto se reduce a una cápsula o esfera derivada de su categoría a partir de su caja delimitadora, se registra como {kind, walkable, radius, p1, p2} y se añade a cada bucket de 8 m del hash con el que se solapa. En cada fotograma, el jugador solo comprueba los objetos del vecindario de 3×3 buckets, con una resolución cápsula contra cápsula para cada uno. Los proxies transitables —rocas y troncos— reciben un empuje solo vertical; los proxies que bloquean —árboles— reciben el empuje 3D completo. Consulta Colisiones con terreno SDF para ver las matemáticas de cápsulas en las que se basa este sistema.

Parte 16 de 29. Anterior: Parte 15 - Sustituir la base y después sincronizarla Siguiente: Parte 17 - Animaciones que no necesitaron retargeting y una búsqueda de recursos en vivo Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Mariana Muntean, CEO de Cinevva

En mayo de 2022, me senté para una entrevista en el pódcast Tech Done Different de Ted Harrington. El artículo original sigue disponible en Medium. Llevaba unos dos años al frente de Cinevva. Éramos cinco personas, habíamos recaudado 200.000 dólares, teníamos un premio de Mozilla Builders en la pared y muchas opiniones sobre el rumbo que estaba tomando el desarrollo de videojuegos.

La mayoría de esas opiniones no estaban de moda en 2022. La Web3 hacía mucho ruido, los estudios AAA dominaban la conversación, GPT-3 era un juguete de investigación y WebGL era algo que los aficionados usaban para crear juegos en jams. Decir en voz alta que «cualquier persona creativa podrá desarrollar videojuegos» recibía asentimientos corteses y cero cheques.

La semana pasada volví a leer aquella entrevista. Algunas de las cosas que dije parecen ilusiones. Otras hacen pensar que tenía una máquina del tiempo. Estas son las cuatro apuestas que mejor han envejecido, junto con la realidad de cada una en 2026.

Apuesta 1: Los motores de juegos deben estar en el navegador

Lo que dije en 2022:

La tecnología WebGL puede utilizarse en múltiples plataformas, incluidos los dispositivos móviles, a diferencia de otras API que pueden estar restringidas únicamente a PC. Así que, tanto si estás en la comodidad de tu hogar como si estás fuera, puedes seguir creando y publicando. Los juegos WebGL solo utilizan una fracción de la potencia de CPU y GPU que requeriría un juego tradicional de PC.

En 2022, esta era una apuesta contraria a la corriente dominante. Todos los grandes motores daban por sentados las descargas, las instalaciones y los ciclos de parches. Los juegos de navegador evocaban nostalgia por Flash y Friv.

En 2026, nuestro motor de mundo abierto funciona a 120 FPS en una pestaña del navegador. Terreno, árboles, físicas y sincronización multijugador, todo en una sola URL. Sin descargas, sin tienda de aplicaciones y sin instalación.

El navegador se puso al día porque tres cosas llegaron al mismo tiempo. WebGPU se incorporó a todos los navegadores principales. SharedArrayBuffer y el aislamiento entre orígenes se volvieron fiables. WebAssembly alcanzó la velocidad necesaria para ejecutar auténticos motores de físicas compilados desde Rust. Nuestro equipo publicó un diario de campo de 12 entregas sobre el coste real de cada uno de esos pasos. En resumen, el navegador ya es un verdadero entorno de ejecución para juegos, no un lugar donde alojar la demo del juego de verdad.

La apuesta dentro de la apuesta que no acerté: subestimé cuánto trabajo tendría que hacerse en el ámbito de la cultura de ingeniería. Los motores de juegos para navegador ya no están limitados por los navegadores. Están limitados por la idea de que un juego de verdad debe tener un launcher.

Apuesta 2: La IA forma parte del flujo de trabajo, no es una función secundaria

Lo que dije en 2022:

Para que nuestra plataforma funcione a la perfección, utilizamos herramientas de código abierto para videojuegos, pero también desarrollamos nuestra propia tecnología mediante procesamiento del lenguaje natural, visión artificial y soluciones de OpenAI, como GPT3 para los diálogos y DALL:E para generar imágenes a partir de texto.

En mayo de 2022, GPT-3 era una API de pago que la mayoría de la gente nunca había utilizado. DALL·E apenas tenía un año y contaba con una lista de espera. Decir que íbamos a utilizarlos como herramientas de producción para desarrollar videojuegos era, en el mejor de los casos, una interpretación ambiciosa.

En 2026, todos los flujos creativos serios incorporan modelos de lenguaje y generación de imágenes, incluido el nuestro. Actualmente, dentro de Cinevva usamos ElevenLabs Music para bandas sonoras, ElevenLabs SFX para efectos, Hunyuan3D y SAM3D para recursos, Flux para elementos visuales, Mubert para audio adaptativo y AceStep para instrumentación. Se introducen prompts, salen recursos utilizables y todo sucede dentro del editor.

Las pruebas están en el informe State of the Game Industry de la GDC 2026. El 52 % de las empresas de videojuegos afirma utilizar IA generativa en producción. Ese mismo 52 % de desarrolladores afirma que el uso de la IA está teniendo un impacto negativo en la industria. Ambas cifras son ciertas. La cuestión es que la tecnología subyacente se convirtió en un requisito básico más rápido de lo que nadie quería admitir.

En qué me equivoqué: pensé que la resistencia vendría de ingenieros preocupados por la calidad. La mayor parte vino de artistas preocupados por sus empleos. Esa conversación es mucho más compleja de lo que esperaba, y quienes la presentan como una victoria rotunda no están prestando atención.

Apuesta 3: El desarrollo de videojuegos necesita una colaboración al estilo de Google Docs

Lo que dije en 2022:

El control de código fuente y el trabajo con distintas versiones de las aplicaciones suelen estar vinculados a la colaboración remota. Hoy, para hacerlo, tienes que saber adónde ir, qué versión de la aplicación debes descargar y estar sincronizado con todo el mundo. Dios no quiera que un miembro del equipo utilice una versión incorrecta de la aplicación, porque se convierte en un problema. Aspiramos a ofrecer una experiencia casi en tiempo real como la de un documento de Google: sencilla, sin complicaciones y divertida.

La colaboración en tiempo real dentro de las herramientas de programación era una idea marginal en 2022. Replit la ofrecía. VS Code Live Share existía. La mayoría de los motores profesionales exigían Perforce, una VPN y un ingeniero sénior vigilando tu rama.

En 2026, la colaboración en tiempo real es la opción predeterminada para cualquier herramienta creativa que quiera ser tomada en serio. Figma la normalizó para el diseño. Cursor y Bolt la normalizaron para el código. Lovable la normalizó para el prototipado de aplicaciones. Los motores de juegos se quedaron rezagados en lugar de liderar el cambio.

En nuestro propio motor ya tenemos sincronización multijugador funcionando como un experimento de primera clase, con transmisión de fragmentos, presencia y estado compartido en el navegador. La experiencia se parece más a «abre el enlace y entra» que a «configura Perforce, pregunta en Slack por la versión correcta e instala el launcher».

La parte que subestimé: lo más difícil de la colaboración en tiempo real en videojuegos no son las redes. Es resolver los conflictos de intención creativa. Que dos personas editen el mismo nivel al mismo tiempo es un problema de UX antes que un problema de sincronización, y la mayoría de las herramientas aún no lo han resuelto.

Apuesta 4: El futuro es indie

Lo que dije en 2022:

Las personas creativas que antes no podían crear contenido para videojuegos podrán hacerlo. Descubriremos abundantes formas nuevas de percibir y expresar la creatividad. Esta vez, el proceso no estará controlado únicamente por corporaciones o grandes estudios AAA. El futuro es indie.

Esta fue la frase más romántica de la entrevista y la más fácil de descartar en 2022. Los presupuestos AAA nunca habían sido tan altos. Los proyectos indie nunca lo habían tenido tan difícil para conseguir visibilidad. Las cifras parecían avanzar en la dirección contraria.

En 2026, las cifras dieron la vuelta. Creamos A Breaker Belt en tres días, entre dos personas y para web, móviles y PC desde una única base de código. Antes, eso le habría llevado un trimestre a un equipo pequeño. Los desarrolladores en solitario están publicando juegos, no solo programando por sensaciones, y Steam Next Fest 2026 batió el récord de participantes con equipos de una sola persona.

El coste de averiguar si una idea extraña funciona se ha desplomado. Ese es el verdadero cambio, y todo lo demás —la IA en el flujo de trabajo, el navegador como entorno de ejecución y la colaboración en tiempo real— está a su servicio. Un desarrollador en solitario con las herramientas adecuadas tiene ahora la capacidad de producción que tenía un estudio de 20 personas en 2018.

Lo que no vi con suficiente claridad en 2022: el cuello de botella se desplaza de la producción al descubrimiento. Cuando todo el mundo puede publicar, conseguir visibilidad se convierte en el problema más difícil. Ese es el siguiente conjunto de apuestas y ahora mismo estamos en plena fase de hacerlas.

En qué me equivoqué a propósito

Algunas de las apuestas de 2022 siguen pendientes o necesitan una revisión.

El enfoque Web3 tuvo más protagonismo del que debería en aquella entrevista. La parte de cifrado y pruebas de conocimiento cero sigue siendo válida como base para los derechos sobre el contenido. El planteamiento basado en tokens y marketplaces envejeció mal, y buena parte de la energía que le dediqué en 2022 habría estado mejor invertida en herramientas de IA, donde estaba el verdadero potencial.

También subestimé hasta qué punto «cualquiera puede crear un juego» es un problema de descubrimiento y distribución, no de herramientas. Crear ahora es fácil. Conseguir visibilidad e ingresos sigue siendo difícil, y ahí es donde se concentra actualmente la mayor parte de nuestro trabajo.

Esa es la apuesta que estamos haciendo ahora mismo. Acabamos de lanzar un feed de reels al estilo de TikTok en cinevva.com/play. Clips verticales de quince segundos con gameplay real, sin tráileres ni metraje promocional. Si algo te llama la atención, con un toque ya estás jugando en el navegador. Sin descargas, sin instalaciones y sin tutoriales que se interpongan entre el juego y tú.

La razón por la que esto importa para los desarrolladores indie se reduce a unas cifras brutales. Steam Next Fest 2026 registró un número récord de participantes, lo que suena genial hasta que calculas el presupuesto de atención disponible por juego. La mayoría de las demos obtuvieron menos de mil impresiones. El embudo de las páginas de la tienda ya estaba roto antes de que la IA lo empeorara. Una superficie de desplazamiento vertical en la que el propio gameplay es el anuncio reduce el ciclo de descubrimiento a un solo gesto. Pone a los desarrolladores en solitario frente a los jugadores del mismo modo que TikTok pone a músicos desconocidos frente a sus oyentes. Esa es la pieza que falta entre «cualquiera puede publicar» y «cualquiera puede triunfar».

Si quieres leer la entrevista original completa, está aquí. Volver a leerla fue útil. La mayor parte de lo que dijimos en voz alta en 2022 resultó ser una hoja de ruta viable, solo que con plazos más rápidos de lo que imaginábamos.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Durante doce partes construimos un motor de terreno que se podía contemplar. Sobrevolarlo. Admirar cómo no se abrían las uniones. Esta vez queríamos tocarlo.

El objetivo parecía sencillo: permitir que un jugador esculpiera el terreno con un pincel, en tiempo real, sin romper ninguno de los sistemas que habíamos tardado 24 spikes en construir. Hicieron falta tres intentos, dos errores que parecían fallos de renderizado pero que en realidad eran fallos del modelo de datos, y un replanteamiento fundamental de cómo debían funcionar los datos del terreno.

Tres intentos fallidos

Se suponía que el Spike 25 iba a ser el fácil. La base de código de producción ya tenía un trazador de rayos que detectaba las mallas del terreno. La herramienta de colocación lo usa para soltar objetos. Una herramienta de pincel sigue el mismo patrón, solo que modifica valores del mapa de alturas en lugar de instanciar un prefab. Sencillo.

Primer intento: lo construí directamente en el código TypeScript de producción de world/client/. Un nuevo terrain-brush.ts, modificaciones en chunk.ts, cambios en el protocolo y actualizaciones de componentes Vue. Al cabo de una hora tenía un pincel que más o menos funcionaba, pero los límites entre chunks mostraban discontinuidades visibles en las normales. No podía saber si el error estaba en el código del pincel, en el cosido de chunks existente o en alguna interacción con el bucle de renderizado completo. Esa es exactamente la situación que la metodología de spikes pretende evitar. Me había saltado la regla y pagué por ello de inmediato. Revertí todos los cambios.

Segundo intento: un spike independiente, pero recurrí a Three.js 0.170.0 y WebGL. El código de producción usa WebGL, así que parecía lo natural. Pero los Spikes 13-24 ya habían migrado todos a WebGPU. Crear un spike de pincel con WebGL demostraría que funcionaba con el renderizador antiguo, no con aquel hacia el que estamos migrando. Dirección equivocada. Empecé de nuevo.

Tercer intento: WebGPU, WebGPURenderer, shader de cómputo para generar vértices y la misma pila tecnológica que el Spike 22. Esta vez la arquitectura era correcta. Cinco operaciones de pincel funcionando: elevar, bajar, suavizar, aplanar y añadir ruido. P95 del ciclo del pincel por debajo de 4 ms en un M1.

Y el error de las uniones seguía ahí.

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

El error de las uniones que se negaba a morir

La solución habitual para calcular normales entre chunks es solapar los bordes: cada chunk almacena un anillo adicional de datos de sus vecinos para que el cálculo de la normal en el límite pueda muestrear ambos lados. Lo implementé. Copié los datos de los bordes vecinos en un búfer ampliado. Las uniones seguían abriéndose.

Me sumergí en las matemáticas. En el límite entre el chunk A (cx=-1) y el chunk B (cx=0), ambos chunks deben calcular la misma normal en el vértice compartido. El shader del chunk A muestreaba mix(own_col31, own_col32, 0.85). El del chunk B muestreaba mix(neighbor_edge, own_col0, 0.85). Son rutas de interpolación bilineal distintas a través de datos diferentes. Incluso con datos de borde correctos, los dos chunks calculan normales distintas para el mismo punto.

Fue entonces cuando comprendí que copiar el borde no era el verdadero error. El verdadero error estaba en el modelo de datos.

Todos los spikes del 1 al 24 usaban una función matemática procedimental llamada height_at(). Le pasabas coordenadas del mundo y devolvía una altura. Limpia, global y sin estado. El pincel no podía modificar una función matemática, así que había añadido encima un búfer de displacement. El terreno era ahora height_at(x,z) + displacement[i]. El shader de GPU contenía 30 líneas de funciones de ruido para el terreno base, además del código de interpolación bilineal para la capa de desplazamiento. El pincel de aplanado tenía que restar height_at() para averiguar qué valor de desplazamiento produciría la altura objetivo. Dos sistemas superpuestos, calculando cosas distintas con estrategias de muestreo diferentes.

Nada de esto es propio de un juego real. En producción, el terreno creado se representa mediante datos muestreados almacenados en búferes. La función procedimental era un sustituto práctico de los primeros spikes. Había cumplido su propósito. Ahora estaba provocando errores activamente.

La eliminé.

Ahora cada chunk posee un heightmap Float32Array con valores de altura reales. Al crearlo, se rellena con ruido procedimental. Después, la función de ruido no vuelve a llamarse. El pincel modifica directamente las alturas almacenadas. El shader de GPU lee de un único búfer mediante una única función: hm_at(i,j). Las normales usan diferencias centrales alineadas con la cuadrícula sobre los mismos datos. Sin ambigüedad en la interpolación bilineal. Sin incompatibilidad entre dos sistemas. El shader pasó de 90 líneas a 40.

Las uniones se arreglaron solas. Ahora, en un borde compartido, ambos chunks leen los mismos valores discretos de altura de sus respectivos búferes, con los puntos interiores correctos del vecino en el solapamiento del borde. Los mismos datos de entrada producen las mismas normales.

Esta no fue una lección sobre pinceles. Fue una lección sobre arquitectura de datos que el pincel sacó a la luz.

La malla que explotó

El Spike 26 era el equivalente volumétrico. Modificar con un pincel un volumen SDF de 64 al cubo y volver a generar la malla con marching cubes. La misma pregunta que en el Spike 25, pero en 3D.

La primera vez que lo ejecuté, la malla explotó. Largas púas salían disparadas en todas direcciones, como un erizo de mar teniendo un mal día.

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

La tabla de casos de MC que había generado tenía 3840 entradas en vez de 4096. La tabla completa es de $256\text{casos}\times 16\text{posiciones}=4096$, pero yo tenía $256\times 15=3840$: faltaban dieciséis filas a partir del caso 112. Todas las consultas posteriores a ese índice estaban desplazadas, por lo que el número de caso ya no coincidía con los datos de triangulación. Cuando marching cubes lee una entrada incorrecta, crea aristas cuyos dos extremos están en el mismo lado de la superficie. En una arista que realmente cruza la superficie, el parámetro de interpolación

queda dentro de $[0,1]$ porque $v_a$ y $v_b$ tienen signos opuestos. En una arista falsa tienen el mismo signo, por lo que $v_b-v_a$ está cerca de cero o cambia de signo y $t$ sale disparado fuera de $[0,1]$, colocando el vértice muy lejos del volumen. Multiplica eso por unos cientos de celdas incorrectas y obtendrás un erizo.

La solución fue absurdamente sencilla: copiar byte por byte la tabla probada del Spike 12. Lección aprendida. Nunca regeneres una tabla de consulta cuando ya existe una copia probada.

El segundo error era más sutil. Se suponía que el pincel de suavizado debía suavizar las formas del terreno. En cambio, creaba pliegues pronunciados. El problema era que yo atraía todos los valores SDF hacia cero, es decir, hacia la isosuperficie. Parece que eso debería suavizar las cosas, pero en realidad colapsa el campo de distancias. Los vóxeles por encima y por debajo de la superficie se precipitan hacia cero, aplanándolo todo dentro del radio del pincel. En el límite, los vóxeles suavizados se encuentran con los no suavizados formando un escalón abrupto. El pincel de «suavizado» era un generador de pliegues.

La solución fue aplicar un suavizado laplaciano adecuado. En lugar de atraer cada valor hacia cero, hay que llevarlo hacia el promedio de sus 6 vecinos directos:

El término entre paréntesis es un laplaciano discreto y $\lambda \in (0,1]$ es la intensidad del suavizado. Esto promedia la geometría cercana y suaviza la forma de la superficie, a la vez que preserva el gradiente del campo de distancias en lugar de colapsarlo.

Todo a la vez

El Spike 27 era la prueba de integración. Había que tomar la canalización completa del Spike 24 —parches de mapa de alturas, chunks MC, uniones Transvoxel y LOD con geomorfismo— y combinarla con el modelo de datos muestreados del Spike 25 y ambos tipos de pincel.

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

Lo primero que hice fue arrancar height_at() de todos los shaders. Los tres shaders de cómputo —relleno de SDF, parche de mapa de alturas y unión Transvoxel— ahora enlazan el mismo búfer de GPU de mapa de alturas de 129x129 y usan la misma función de interpolación bilineal hm_sample() mediante un preámbulo WGSL compartido. Una fuente de datos, múltiples consumidores. Las funciones de ruido procedimental que habían vivido en todos los shaders desde el Spike 1 desaparecieron.

Entonces empezaron los problemas interesantes.

Cuando un pincel SDF bloquea un chunk en modo MC, la unión Transvoxel entre ese chunk y su vecino de mapa de alturas debe muestrear el volumen SDF, no el mapa de alturas. Amplié el shader de uniones con enlaces adicionales a búferes de almacenamiento e indicadores MC por chunk. Había que gestionar cuatro combinaciones de límites: HM-HM, HM-MC, MC-HM y MC-MC.

El LOD era otro rompecabezas. En spikes anteriores, cambiar un chunk MC a un LOD inferior implicaba volver a rellenar el SDF con una resolución más baja. Lo sustituí por un muestreo basado en el paso: los datos SDF permanecen a resolución completa, con 65 puntos de cuadrícula. El shader MC calcula un paso a partir de la relación entre el tamaño de la cuadrícula y el número de celdas. En LOD0, el paso es 1. En LOD1, el paso es 2 y se muestrea un vóxel de cada dos. Los chunks pueden cambiar libremente de LOD sin tocar sus datos SDF.

La solución más satisfactoria fue la creación dinámica de chunks verticales. Si esculpes hacia arriba más allá de la parte superior de un chunk, aparece encima un nuevo chunk exclusivo de MC cuyo SDF se inicializa a partir de la cara limítrofe del chunk inferior. Si esculpes hacia abajo, ocurre lo mismo. El mundo crece para adaptarse a las modificaciones.

El último escollo fue que el pincel de mapa de alturas no hacía absolutamente nada en los chunks bloqueados en MC. El pincel HM modifica heightmapCPU y vuelve a subirlo. Los chunks MC ya no leen del mapa de alturas porque su SDF se rellenó a partir de él y después divergió. Añadí syncHeightmapToSdf(): después de cambiar el mapa de alturas, se vuelven a derivar las columnas SDF de todos los chunks MC dentro del radio del pincel y se suben los nuevos valores. Ahora ambos tipos de pincel funcionan en ambos tipos de chunk.

Lo que aprendimos realmente

Se suponía que los spikes de pinceles debían responder a una pregunta de rendimiento: ¿puede ejecutarse el esculpido sin superar el presupuesto por fotograma? Sí puede. Esa fue la parte fácil.

La parte difícil fue descubrir que 24 spikes usando height_at() como verdad del terreno habían creado una dependencia invisible que se rompió en cuanto intentamos editar algo. La función procedimental era limpia, global y sin estado, justo hasta que dejó de representar el terreno.

Estas son las reglas que anotamos y que no olvidaremos:

1. La altura del terreno procede de datos muestreados. Los chunks son propietarios de sus búferes.
2. La generación procedimental rellena los datos iniciales. No es la fuente de verdad en tiempo de ejecución.
3. El pincel modifica directamente los datos del chunk. Sin capas de desplazamiento.
4. Las normales proceden de los mismos datos mediante diferencias centrales alineadas con la cuadrícula.
5. El solapamiento de bordes —1 celda del interior del vecino— permite calcular las normales entre chunks.
6. Nunca regeneres una tabla de consulta cuando ya existe una copia probada.

En la parte 14 dejamos de esculpir geometría de depuración y empezamos a hacer que parezca y se sienta como un lugar real.

Tecnología mencionada en este capítulo

Arquitectura de mapas de alturas muestreados. El terreno se almacena como datos propios de cada chunk, en lugar de evaluarse mediante una función procedimental en tiempo de ejecución. Cada chunk contiene un Float32Array con valores de altura reales. El ruido procedimental rellena los datos iniciales al crearlo y después la función no vuelve a llamarse. Esto elimina la incompatibilidad entre el terreno matemático y las capas de edición, simplifica las operaciones del pincel —se editan directamente los valores almacenados— y hace que el shader de GPU sea trivialmente sencillo: leer del búfer y calcular las normales mediante diferencias centrales alineadas con la cuadrícula. Para un mundo abierto con streaming, el enfoque estándar es que cada chunk sea propietario de sus datos y tenga un solapamiento de 1 celda procedente de sus vecinos. Consulta nuestra guía de generación de paisajes.

Operaciones de pincel SDF. Modificación de un campo de distancias con signo para esculpir el terreno. Sumar —inflar— utiliza una atenuación smooth-step alrededor de una esfera. Restar —excavar— usa la misma forma negada. Suavizar usa un promedio laplaciano: se leen los 6 vecinos directos, se calcula su media y se lleva el valor hacia ella. El enfoque ingenuo de atraer los valores hacia cero colapsa el campo de distancias y crea bordes pronunciados. El suavizado laplaciano preserva el gradiente del campo a la vez que suaviza las formas. Consulta la representación de terreno mediante SDF.

Transvoxel con fuentes de datos mixtas. Las celdas de transición situadas en el límite entre un chunk MC y uno de mapa de alturas necesitan muestrear datos diferentes en cada lado. El shader de uniones incluye indicadores por chunk y enlaces a búferes para gestionar las cuatro combinaciones: HM-HM, HM-MC, MC-HM y MC-MC. Cuando un lado está bloqueado en MC, el shader interpola trilinealmente el búfer SDF en lugar de muestrear el mapa de alturas. LOD basado en pasos para marching cubes. Los datos SDF se almacenan a resolución completa independientemente del nivel de LOD actual del chunk. El shader de MC calcula un paso de muestreo a partir de la proporción entre los puntos de la cuadrícula SDF y las celdas de MC. A resolución completa, el paso es 1; a media resolución, es 2. Esto desacopla los datos SDF de los cambios de LOD, por lo que los chunks pueden cambiar libremente de LOD sin tener que reconstruir el SDF.

Parte 13 de 14. Anterior: Parte 12 - Anillos, niebla del cielo y lo que volveríamos a hacer Siguiente: Parte 14 - El mundo cobra vida Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Después de la parte 13 ya podíamos esculpir. Elevar el terreno, excavar cuevas y suavizar acantilados, todo en tiempo real y manteniendo intactas las uniones. Pero el mundo parecía una demo técnica. Sombreado plano con colores de depuración, superposiciones de malla y geometría gris con colores de LOD para distinguir los chunks. Podías editarlo. No podías sentirlo.

Tres spikes cambiaron eso. No cambiamos la arquitectura. Usamos exactamente el mismo pipeline, los mismos búferes y el mismo cosido de uniones de la parte 13. Solo añadimos las capas que hacen que un terreno se sienta como un lugar: superficies que responden a su forma, vida que crece sobre ellas y un cuerpo que las recorre.

La diferencia entre «funciona técnicamente» y «quiero quedarme aquí» resultó ser sorprendentemente pequeña.

Esculpe un acantilado y observa cómo se convierte en roca

El spike 28 planteaba una pregunta concreta: ¿puede ejecutarse un material de cuatro capas con mapeado triplanar sobre terreno generado mediante cómputo sin agotar el presupuesto por fotograma? La respuesta fue sí, pero lo interesante fue lo que ocurrió después.

Abrir el spike 28 en una pestaña nueva ↗ · Ver el código fuente

Cuatro texturas procedurales —hierba, roca, arena y nieve— generadas a partir de ruido FBM al iniciar. Sin archivos externos ni pipeline de recursos, solo matemáticas y una DataTexture. Los pesos de los materiales proceden de la propia superficie: la pendiente y la altitud. Las zonas planas por debajo de la línea de árboles reciben hierba. Las caras empinadas reciben roca. Las zonas bajas reciben arena. Las cumbres altas reciben nieve. Cada peso bruto se obtiene mediante un smoothstep aplicado a la pendiente y la altitud; después, se normalizan por fragmento para que $\sum _i{w}_i=1$ y el color final sea simplemente la mezcla ponderada $\sum _i{w}_i{c}_i$. La normalización evita que la superficie quede demasiado oscura o sobreexpuesta donde se solapan los biomas. El mapeado triplanar se encarga de la proyección UV para los chunks de MC, cuyas caras no tienen coordenadas UV significativas.

El momento que nos convenció: elevas el terreno con el pincel para crear un acantilado empinado y la textura de roca aparece sobre la nueva cara en el mismo fotograma. Vuelves a aplanarlo y la hierba recupera la superficie. El material no sabe nada del pincel. Solo lee la posición en el mundo y la normal de la superficie, los mismos datos a partir de los cuales se construyó la geometría. El bucle de retroalimentación visual al esculpir es instantáneo y no depende de ningún script específico.

El spike 8 probó hace mes y medio el coste del material del terreno con una malla estática en WebGL. El spike 28 demuestra que funciona sobre terreno dinámico generado mediante cómputo, con todo el pipeline de esculpido ejecutándose por debajo. Lo habíamos contemplado en el presupuesto, pero verlo mantenerse a 60 fps con todo en ejecución siguió siendo un alivio.

80 000 matas de hierba y el techo de una cueva

En el spike 29 fue donde nuestros instintos de desarrollo de videojuegos tomaron el control.

Abrir el spike 29 en una pestaña nueva ↗ · Ver el código fuente

Queríamos la hierba de Breath of the Wild. No el número de polígonos, sino la sensación. Hierba que cubriera los lugares adecuados, se moviera con el viento y te diera ganas de correr entre ella.

Cada mata de hierba consta de tres quads que se cruzan con ángulos de 60 grados y tienen cuatro segmentos verticales para poder doblarse. Es una forma de cruz que parece volumétrica desde cualquier ángulo sin recurrir a trucos con billboards. Un InstancedMesh por chunk, 80 000 matas repartidas por el mundo y unos 2,4 millones de vértices de hierba en total.

La colocación es la parte importante. La CPU recorre una cuadrícula con variaciones aleatorias sobre cada chunk y evalúa la misma lógica de pendiente y altitud que utiliza el shader de materiales de la GPU. Donde el sistema de materiales dice «hierba», crece hierba. Donde predominan la roca o la arena, la densidad cae a cero. La transición es suave porque los pesos smoothstep subyacentes producen gradientes continuos en los límites de los biomas. No percibes ninguna frontera porque no la hay.

Después hicimos algo que no estaba seguro de que fuera a funcionar: hierba sobre superficies SDF. La función de dispersión recorre cada columna del volumen SDF y busca cruces por cero entre vóxeles adyacentes. Donde el SDF pasa de negativo a positivo, hay una superficie. La normal de la superficie es simplemente el gradiente normalizado del campo, $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$, calculado a partir de las diferencias entre vóxeles, y la pendiente es $\arccos (\hat{n}\cdot \hat{y})$, el ángulo respecto a la vertical. Si es lo bastante suave, se coloca hierba.

Excava una cueva con el pincel SDF en el spike 27. Vuelve al spike 29 y habrá hierba creciendo sobre la parte superior del techo de la cueva. El código de dispersión no sabe qué es una cueva. Solo ve una superficie con la pendiente adecuada a la altitud adecuada. Ese es el tipo de comportamiento emergente que hace tan satisfactorio construir sistemas de mundo abierto.

El viento es una onda sinusoidal en el shader de vértices TSL, modulada por la coordenada V de la brizna para que las puntas se balanceen y las raíces permanezcan plantadas. Pulsa V para alternar entre viento suave, fuerte y desactivado. El viento actúa simultáneamente sobre las 80 000 matas sin ningún coste para la CPU porque se ejecuta por completo en el shader de vértices.

En el spike 7 probamos 50 000 instancias de hierba y nos preocupaba alcanzar el límite. El spike 29 ejecuta 80 000 sobre el terreno generado mediante cómputo, el cosido de uniones, el texturizado multimaterial y los pinceles. Agruparlas en menos llamadas de dibujo de InstancedMesh sigue siendo más importante que reducir el número de vértices por brizna. La lección del spike 7 se mantuvo.

Algo que dejamos para más adelante: la hierba no se actualiza cuando esculpes debajo de ella. Las matrices de las instancias se fijan al dispersarlas. Si transformas una colina en un valle, la hierba flota en el aire hasta que pulsas G para volver a dispersarla. Es suficiente para un spike. En producción habrá que volver a dispersar la vegetación de los chunks modificados.

El primer paso

El spike 30 es al que no dejo de volver.

Abrir el spike 30 en una pestaña nueva ↗ · Ver el código fuente

Sin biblioteca de físicas. Una cápsula personalizada con un paso de tiempo fijo de 120 Hz. El código de producción utiliza Rapier en un web worker —el spike 2 demostró que la latencia es aceptable—, pero este spike tenía que validar las propias consultas de colisión. ¿Puede un personaje caminar sobre terreno de mapa de alturas, pasar a terreno SDF esculpido y no caer a través de él?

El núcleo es una función llamada terrainQuery(x, y, z). Comprueba si la posición está dentro de un chunk bloqueado en MC. Si es así, interpola trilinealmente la copia SDF de la CPU y devuelve el gradiente como normal de la superficie. En caso contrario, consulta el mapa de alturas y calcula la normal mediante diferencias centrales. El personaje no sabe sobre qué sistema de terreno se encuentra. Solo pregunta dónde está el suelo y obtiene una respuesta.

La colisión con SDF era la parte que esperaba que resultara difícil. Siete puntos de sondeo alrededor de la cápsula: inferior, central, superior y cuatro desplazamientos cardinales. Un punto de sondeo en la posición $\mathbf{x}$ está penetrando siempre que $\varphi (\mathbf{x})<r$, con una profundidad de penetración $p=r-\varphi (\mathbf{x})$, y la dirección de expulsión es el gradiente del campo $\hat{n}=\frac{\mathrm{\nabla }\varphi }{\Vert \mathrm{\nabla }\varphi \Vert }$. Para impedir que la cápsula vuelva a entrar en la superficie, se proyecta la velocidad para cancelar su componente hacia el interior:

Esto deja únicamente la componente que se desliza a lo largo de la superficie. No es un motor de físicas. Son consultas geométricas y una respuesta sencilla. Pero gestiona cuevas, salientes y túneles esculpidos sin ningún código específico para cada forma. Entras en una cueva que excavaste diez segundos antes y la cápsula sigue con exactitud el contorno del techo.

El modelo de movimiento comenzó siendo práctico y acabó siendo divertido. Caminar, correr, esprintar, saltar y deslizarse por pendientes superiores a 45 grados. Después añadí un parapente al estilo BotW y el spike se convirtió en algo que no quería cerrar.

Pulsa Espacio mientras estás en el aire. La gravedad baja de -30 a -4. La velocidad de caída se limita a -3. Una malla con forma de ala delta se despliega desde la cápsula mediante interpolación de escala. Gira a la izquierda y el ala se inclina. La orientación de la cápsula se alinea automáticamente con el vector de velocidad, por lo que siempre miras en la dirección en la que avanzas. Suelta Espacio para caer. Toca el suelo y vuelves a correr.

La cámara se aleja y adopta una vista en tercera persona —pulsa P para alternarla—. Sigue al jugador desde atrás con suavizado de guiñada. Un ray marching desde el jugador hasta la cámara comprueba el terreno en 20 pasos. Si vuelas hacia el interior de una cueva, el brazo de la cámara se acorta suavemente en lugar de atravesar la roca. Al salir por el otro lado, vuelve a extenderse.

Este es el momento que hizo que el spike mereciera la pena: esculpe un acantilado alto con el pincel del mapa de alturas. Cambia a la cámara en tercera persona. Corre hasta el borde. Salta. Despliega el planeador. Gira a la izquierda sobre el terreno que acabas de esculpir, con la hierba que cultivaste en el spike 29 ondeando debajo, la textura de roca del spike 28 sobre la cara del acantilado y las uniones de Transvoxel manteniéndose en cada límite entre chunks. Aterriza al otro lado. Todo funcionando en conjunto dentro de una sola pestaña del navegador.

Esculpir bajo tus propios pies

Había algo sobre lo que no estaba seguro: ¿qué ocurre cuando esculpes el terreno sobre el que está el personaje? Los cambios del mapa de alturas se propagan de inmediato a través de terrainQuery() porque lee directamente el búfer de la CPU. Los cambios del SDF se propagan a través de la copia SDF de la CPU. La cápsula resuelve la penetración en el siguiente tick de físicas, que a 120 Hz ocurre en menos de $\frac{1}{120}\approx 8.3$ ms.

Simplemente funciona. Eleva el suelo bajo el jugador y este sube con él. Excava el suelo y cae. Sin tratamiento especial. Las físicas se ejecutan con suficiente rapidez para que los cambios de terreno de un solo fotograma nunca produzcan penetraciones grandes. Fue un feliz accidente de haber elegido 120 Hz para el paso de tiempo. Lo elegimos para conseguir un movimiento fluido y, de paso, hizo que editar el terreno fuera seguro sin ningún coste adicional.

30 spikes después

Comenzamos esta serie con un mapa de alturas plano y 500 cubos. Ahora tenemos terreno esculpido con cuevas volumétricas, cosido de uniones mediante Transvoxel, texturizado multimaterial que responde a la forma de la superficie, 80 000 matas de hierba meciéndose con el viento y un personaje que camina, esprinta, salta y planea sobre todo ello.

Nada de esto está todavía en producción. El código de world/client/ sigue ejecutándose en WebGL con chunks sencillos de mapas de alturas. Todo lo creado en estos 30 spikes vive en páginas HTML independientes. El siguiente paso es la integración: migrar a WebGPURenderer, conectar la política híbrida HM/MC con el gestor de chunks y vincular los sistemas de pinceles y materiales con el multijugador.

Pero el sistema de renderizado ya no es el riesgo. Las preguntas abiertas tienen que ver con el flujo de datos: persistencia de las ediciones, sincronización de los trazos de pincel por red y esculpido colaborativo. Lo que ocurre entre los jugadores, no entre los triángulos.

Si has seguido esta serie desde la parte 1, gracias por acompañarnos durante las partes más complicadas. Si acabas de descubrirla, vuelve a la parte 1. Las lecciones están en los caminos equivocados.

Tecnología mencionada en este capítulo

TSL (Three Shading Language). El sistema de shaders basado en nodos de Three.js para el renderizador WebGPU. Los materiales se componen a partir de nodos (positionWorld, normalWorld, smoothstep, triplanarTexture) mediante composición de funciones en JavaScript. El grafo de shaders se compila a WGSL en tiempo de ejecución. TSL sustituye al ShaderMaterial de GLSL puro en los destinos WebGPU y permite la interoperabilidad entre las funciones estándar de los materiales de Three.js —luces, sombras y niebla— y la lógica personalizada por fragmento.

Mapeado triplanar. Una técnica de proyección de texturas que muestrea una textura tres veces —planos XY, XZ e YZ— y mezcla los resultados según la dirección de la normal de la superficie. Esto elimina el estiramiento UV en geometrías de malla arbitrarias, algo esencial para la salida de marching cubes, donde los triángulos no tienen coordenadas UV significativas. TSL proporciona triplanarTexture() como nodo integrado.

Vegetación instanciada con briznas de quads cruzados. Cada mata de hierba consta de tres quads que se cruzan con ángulos de 60 grados, lo que crea una apariencia volumétrica desde cualquier dirección. Los cuatro segmentos verticales de cada quad permiten una flexión suave para animar el viento. Todo el campo se renderiza como un único InstancedMesh por chunk. Se reserva un 25 % de capacidad adicional para que las nuevas instancias puedan ocupar los espacios reservados cuando se edite el terreno, sin tener que reasignar el búfer de la GPU. Consulta nuestra guía de generación de paisajes sobre vegetación. Colisión entre cápsula y SDF. Colisión del personaje con terreno volumétrico sin un motor de física. Se comprueba la cápsula en varios puntos respecto al SDF. Cuando el valor del campo es menor que el radio de la cápsula, el gradiente proporciona la normal hacia el exterior y la diferencia determina la profundidad de penetración. Esto permite manejar cuevas, salientes y túneles sin código específico para cada forma. Consulta colisiones con terreno SDF.

Controlador de personaje con paso de tiempo fijo. La física se actualiza a 120 Hz independientemente de la velocidad de fotogramas, acumulando tiempo real y consumiéndolo en pasos de tamaño fijo. Un número máximo de subpasos evita la espiral de la muerte en fotogramas lentos. El ajuste al suelo mantiene la cápsula adherida durante el desplazamiento por pendientes. El paso de tiempo fijo garantiza un comportamiento determinista para futuras repeticiones multijugador.

Parte 14 de 29. Anterior: Parte 13 - El esculpido del terreno y la muerte de la función matemática Siguiente: Parte 15 - Sustituye la base y luego sincronízala Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Las primeras catorce partes cubrieron los experimentos del 1 al 30. Esa etapa terminó con un sistema de terreno que podía esculpirse en tiempo real, además de un personaje capaz de caminar, planear y caer sobre él. Esta parte retoma la serie en el experimento 31, y lo primero que tuvimos que decidir no fue una cuestión técnica. Fue qué hacer con todo aquel código experimental.

La decisión de «sustituir, no portar»

Teníamos 30 archivos HTML independientes, cada uno dedicado a demostrar un concepto aislado, y ninguna integración. El world/client/ de producción seguía usando la pila antigua: WebGL, un mapa de alturas sencillo, un controlador de personaje de 75 líneas y un protocolo MessagePack con nueve tipos de mensajes. Sin edición, sin WebGPU, sin materiales y sin vegetación.

El plan obvio era portar los resultados de los experimentos a ese código de producción uno por uno. Lo descartamos. El experimento 30 ya tenía mejores terrenos, físicas, materiales, vegetación y cámara que los que jamás tuvo world/client/. Portarlo todo al antiguo código WebGL habría significado luchar contra él en cada paso. Así que decidimos sustituir la implementación del mundo por el experimento más logrado y seguir construyendo a partir de ahí. El experimento 30 se convirtió en la nueva base y world/client/ pasó a ser código muerto.

Eso replanteó el trabajo restante. Para pasar de una «gran demostración técnica para un jugador» a un «producto» necesitábamos multijugador, persistencia, streaming de un mundo infinito y colocación de objetos. La sincronización multijugador del terreno fue lo primero, porque es lo que obliga a definir la arquitectura. La pregunta que resuelve es fácil de formular y costosa de responder mal: cuando el jugador A esculpe, ¿qué se envía realmente por la red?

Repetición de parámetros del pincel, no sincronización de píxeles

Abrir el experimento 31 en una pestaña nueva ↗ · Ver código fuente

Antes de escribir una sola línea de código de red, rastreamos con exactitud qué hace una pincelada. El pincel del mapa de alturas recorre un radio alrededor del cursor dentro de un Float32Array en la CPU, aplica una atenuación smoothstep y suma, resta, suaviza o aplana. El pincel SDF hace lo mismo en 3D sobre una esfera de vóxeles. Ambas rutas son operaciones matemáticas puras con arrays en la CPU. No hay cómputo en la GPU dentro del bucle, ni aleatoriedad, ni operaciones de coma flotante no deterministas. El mismo array de entrada más los mismos parámetros produce la misma salida en todas las máquinas.

Ese es todo el truco. No enviamos el terreno editado. Enviamos los parámetros del pincel, 56 bytes por ciclo de pincelada, y cada cliente repite la misma función determinista. El protocolo de sincronización tiene cuatro tipos de mensajes: detección de pares, el mensaje del pincel {op, wx, wy, wz, radius, strength, flattenTarget} y un mensaje de posición del jugador a 20 Hz.

Para el experimento prescindimos por completo del servidor y usamos BroadcastChannel, la API del navegador para enviar mensajes entre pestañas del mismo origen. Abres dos pestañas y se comunican sin ninguna infraestructura. Eso permite aislar la cuestión de la sincronización de la latencia, la autenticación y la conexión con Durable Objects. Si la repetición de parámetros converge entre pestañas, también convergerá mediante WebSocket.

El único punto en el que la repetición puede divergir son las operaciones que dependen del orden. Elevar y rebajar son conmutativas, por lo que val + strength * falloff produce el mismo resultado sin importar quién lo aplicó primero. Suavizar y aplanar leen valores vecinos, de modo que dos clientes que suavicen exactamente el mismo lugar en el mismo instante pueden desviarse fracciones de milímetro por ciclo. En la práctica eso nunca ocurre, y la solución para producción ya es evidente: dirigir las ediciones a través del DO, dejar que asigne un número de secuencia monotónico, aplicarlas de forma optimista en el cliente y corregir el orden si la secuencia autoritativa no coincide. Es concurrencia optimista clásica, y de todos modos el DO constituye un punto de serialización natural.

La cápsula del otro jugador que no dejaba de desaparecer

Las ediciones se sincronizaron al primer intento. La cápsula del jugador remoto, no. Parpadeaba y desaparecía en la otra pestaña, y tuvimos que corregir tres errores distintos para conseguir que permaneciera visible.

La cápsula aparecía en el origen del mundo, enterrado bajo el terreno, porque el mensaje join llega antes que cualquier dato de posición. Solución: comenzar con ella oculta y mostrarla al recibir la primera actualización de posición. La emisión de la posición estaba dentro del bucle de renderizado, y Chrome limita requestAnimationFrame en las pestañas sin foco, por lo que la comprobación de inactividad de la otra pestaña eliminaba al jugador y el siguiente mensaje volvía a crearlo. Solución: trasladar la emisión a un setInterval, que no se limita en las pestañas visibles. Además, el tiempo de espera de 5 segundos era demasiado agresivo y cualquier pausa del recolector de basura lo activaba. Solución: aumentarlo a 30 segundos y confiar en el mensaje leave para los cierres normales.

Persistencia e incorporación tardía con el mismo formato

Integramos la persistencia en el mismo experimento en lugar de crear uno nuevo, porque el formato de serialización es idéntico tanto si el destino es IndexedDB como si es otra pestaña. Una instantánea contiene el mapa de alturas completo (un Float32Array de 129×129, unos 66 KB), únicamente los fragmentos SDF editados (cada uno de ${65}^3$, unos 1,1 MB) y la lista de identificadores de fragmentos fijados al modo marching cubes. Un guardado con antirrebote escribe en IndexedDB dos segundos después de la última edición. Al cargar, el terreno procedimental se genera de forma síncrona y luego el estado guardado lo sobrescribe antes del primer fotograma significativo. La incorporación tardía reutiliza exactamente los mismos bytes: cuando se une una pestaña nueva, una pestaña existente con ediciones serializa su estado y lo envía específicamente al recién llegado, y la montaña que esculpiste cinco minutos antes aparece en su pantalla.

La primera prueba de persistencia reveló un interesante error de orden. La hierba se distribuye de forma síncrona durante la inicialización usando las alturas procedimentales, pero la restauración desde IndexedDB es asíncrona y después sobrescribe el mapa de alturas, lo que deja todas las briznas flotando o hundidas. La solución es una pasada de refreshAllGrass() que vuelve a muestrear la altura bajo cada instancia y oculta cualquier brizna que ahora esté en una pendiente o altitud inadecuada. La misma función sirve tanto para la carga como para la incorporación tardía.

La odisea de las pendientes

El terreno esculpido es más accidentado que la suave base procedimental, y dejó al descubierto tres errores de físicas que el terreno antiguo nunca pudo revelar. Al caminar cuesta arriba en línea recta, la cápsula se deslizaba lateralmente. La causa era una proyección de la velocidad destinada a mantener el movimiento tangente al suelo, pero escrita utilizando únicamente los componentes horizontales de la normal. En una pendiente diagonal con normal $(-0.3,0.9,-0.3)$, caminar hacia el norte introducía de la nada una velocidad lateral. El ajuste al suelo ya mantiene al jugador sobre la superficie, así que simplemente eliminamos la proyección.

La deriva persistía por una segunda causa. Las sondas de colisión SDF empujan el cuerpo hacia fuera a lo largo del gradiente según la profundidad de penetración. En cualquier pendiente, el gradiente tiene componentes horizontales, por lo que una penetración de 0,1 m en una pendiente de 15° empuja unos 0,026 m hacia un lado en cada paso, y a 120 Hz eso supone aproximadamente 3 m/s de deriva invisible. Solución: dividir la respuesta según la pendiente. En suelo transitable (${\text{grad}}_y$ por encima del umbral transitable), el empuje es exclusivamente vertical. En paredes y acantilados se mantiene el empuje 3D completo, porque ahí es precisamente donde quieres que el personaje sea desviado. También elevamos el límite transitable de $\cos 45°$ a $\cos 60°$ para que las colinas creadas con el pincel se puedan escalar como en Breath of the Wild.

El tercer error inmovilizaba la cápsula en los límites entre fragmentos, porque las sondas de colisión muestreaban el SDF de un único fragmento y obtenían el valor centinela de «muy adentro del aire» cuando una sonda pasaba al fragmento vecino. La solución fue sdfSampleWorld(wx, wy, wz) y sdfGradientWorld(...), que encuentran el fragmento correcto para cualquier posición del mundo y recurren a una estimación de distancia basada en el mapa de alturas cuando no existe ningún SDF. La transición entre las colisiones SDF y las del mapa de alturas ahora es continua.

El agua completa el mundo

Abrir el experimento 32 en una pestaña nueva ↗ · Ver código fuente

Hasta este punto, todos los experimentos trataban de «tierra por encima del agua». El experimento 32 añadió un océano y, con él, una nueva acción de movimiento. Fijamos el nivel del agua en 22 dentro de un terreno que abarca aproximadamente de 8 a 58. Esto inunda los valles bajos, deja playas en la costa y conserva mucha tierra firme para jugar.

La superficie es un MeshStandardNodeMaterial construido con TSL, el mismo enfoque basado en nodos que utiliza el terreno. Tres ondas sinusoidales superpuestas de distintas frecuencias desplazan los vértices, y la normal de la superficie se obtiene a partir de las derivadas analíticas del coseno de esas ondas, en lugar de las normales de la malla. El color pasa de un turquesa de aguas poco profundas a un verde azulado oscuro en las zonas profundas mediante una estimación de profundidad $(\text{level}-y+\text{wave})\times 0.12$ limitada a $[0,1]$; la espuma aumenta cuando esa estimación se acerca a cero en la costa, y el alfa sigue la profundidad para que el agua poco profunda parezca transparente y la profunda, casi opaca.

La natación utiliza un resorte de flotabilidad. El jugador entra en modo natación cuando los pies descienden por debajo del nivel del agua y el centro del cuerpo está a menos de la mitad de la altura de la cápsula con respecto a la superficie. Un resorte tira del cuerpo hacia un objetivo situado justo debajo de la superficie y, con una constante de flotabilidad de 12 frente a una amortiguación del agua de 4, el jugador flota de manera estable con la cabeza fuera, sin oscilaciones. La velocidad de nado es inferior a la de caminar, con una aceleración y una resistencia que transmiten sensación de flotación; saltar cerca de la superficie te impulsa hacia fuera al 60 % de la velocidad normal de salto, y la entrada limita la velocidad descendente a -5 m/s para evitar que te hundas de golpe. Las colisiones con el terreno siguen funcionando bajo el agua, de modo que puedes caminar por el lecho del lago donde este se eleva por encima del objetivo de natación. El indicador de natación se incluye en la emisión de posición para que los demás jugadores te vean nadar, y una superposición HTML con degradado tiñe la vista cuando la cámara se sumerge bajo la superficie.

Tecnología mencionada en este capítulo

Repetición determinista de parámetros del pincel. En lugar de transmitir el terreno editado, cada cliente envía únicamente los parámetros del pincel y repite la misma función en la CPU. Esto funciona porque tanto los pinceles del mapa de alturas como los SDF realizan operaciones matemáticas puras con Float32Array, sin aleatoriedad ni no determinismo de la GPU, por lo que entradas idénticas producen resultados idénticos bit a bit en todas partes. La carga útil es de 56 bytes por ciclo de pincelada. Las operaciones conmutativas (elevar y rebajar) convergen sin importar el orden, mientras que las operaciones que leen valores vecinos (suavizar y aplanar) necesitan un punto de serialización para garantizar la convergencia, algo que el Durable Object de producción proporciona mediante números de secuencia monotónicos.

BroadcastChannel como sustituto de WebSocket. Una API del navegador para enviar mensajes entre pestañas del mismo origen sin ningún servidor. Aquí se usa para probar el protocolo de sincronización de forma aislada de la latencia de red y la autenticación. El formato de serialización (un mapa de alturas Float32Array sin procesar, más los fragmentos SDF editados y los identificadores de los fragmentos fijados a MC) utiliza los mismos bytes para la persistencia en IndexedDB y la transferencia de estado al incorporarse tarde, de modo que un único formato cubre tres tareas.

Respuesta de colisión SDF dividida según la pendiente. Cuando una sonda de la cápsula penetra en terreno volumétrico, la solución ingenua empuja el cuerpo hacia fuera siguiendo el gradiente SDF y según la profundidad de penetración. En las pendientes, ese gradiente tiene componentes horizontales que introducen deriva lateral. Dividir la respuesta para que las superficies transitables (${\text{grad}}_y$ por encima del umbral) reciban un empuje exclusivamente vertical, mientras que las superficies empinadas mantienen el empuje 3D completo más la proyección de velocidad, elimina la deriva sin perder la colisión con las paredes. Consulta colisiones en terrenos SDF.

Agua TSL con normales de onda analíticas. El océano utiliza un material de nodos cuyos vértices son desplazados por la suma de tres ondas sinusoidales. En lugar de volver a calcular las normales de la malla tras el desplazamiento, la normal de la superficie se obtiene analíticamente a partir de las derivadas del coseno de las funciones de onda, lo que resulta más barato y evita los artefactos de las normales por diferencias finitas en una cuadrícula de baja resolución. El color según la profundidad, la espuma de la costa y la transparencia según la profundidad parten de una única estimación de profundidad.

Natación mediante resorte de flotabilidad. Las físicas de natación modelan el cuerpo como un resorte amortiguado atraído hacia un objetivo situado justo debajo de la superficie. Con una constante de flotabilidad de 12 y una amortiguación de 4, el jugador se estabiliza en la superficie sin oscilar. Unas constantes de movimiento diferenciadas —menor velocidad, aceleración flotante y gran resistencia— hacen que nadar se sienta distinto de caminar, mientras que la colisión existente entre la cápsula y el terreno sigue funcionando bajo el agua.

Parte 15 de 29. Anterior: Parte 14 - El mundo cobra vida Siguiente: Parte 16 - Estructura para un mundo que no deja de crecer Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Basada en el flujo de trabajo de boceto a vídeo y a 3D, y en Kali la Gatita (Cubcoats). Para licencias, el blog o presentaciones a socios.

Para compartir como PDF: Abre esta página y, en el navegador, selecciona Archivo → Imprimir → Guardar como PDF.

Árbol Dorado — Ficha completa

Eslogan: Un mundo que crece contigo. Visítalo, riégalo y observa. Sin niveles. Sin presión.

En qué consiste

Un mundo tranquilo y coleccionable que evoluciona en tiempo real. Una «temporada» compartida (por ejemplo, Isla de Primavera): una única isla 3D por la que los niños pueden caminar, como en la demo jugable de Kali. No hay niveles ni puntuaciones tradicionales. El progreso se refleja en cosas como a tu árbol le ha crecido una rama nueva, has visto 12 momentos o alguien ha regado tu semilla.

En cada visita, el niño puede: regar una planta, dejar un deseo (texto o emoji), encontrar un personaje oculto de Cubcoats o ver un «momento» de 30 segundos (por ejemplo, Kali bajo el árbol dorado). Cada semana se publican nuevos momentos y pequeños fragmentos narrativos (formato episódico). Idioma ambiental opcional: «Hoy Kali ha dicho: [una frase en EN y ZH]».

El aprendizaje y el crecimiento son sutiles: los temas (la bondad, la paciencia, volver a intentarlo) están presentes en la escritura y el arte, no en lecciones. La experiencia se siente como un juguete o un lugar compartido, no como la escuela.

Bucle principal

1. Visita la isla (desde el navegador o la aplicación).
2. Realiza una acción sencilla por visita: regar, pedir un deseo, encontrar un personaje o ver un momento.
3. Observa cómo cambia el mundo con el paso de los días y las semanas (flores nuevas, nuevas poses de los personajes y nuevos clips breves).
4. Comparte una semilla con un amigo o «visita la isla de un amigo» para que el crecimiento se sienta como una experiencia social.

Cómo utiliza el flujo de trabajo y los personajes del artículo

• Mundo 3D jugable: El mismo flujo de trabajo que en la demo de Kali: pose en T → Generador de Modelos 3D → rigging → Cinevva Engine. La isla y los personajes se pueden explorar en tercera persona, sin presión.
• Árbol dorado: Procede directamente del artículo (el paso «del miedo a la esperanza» de Kali y el árbol dorado mágico). El árbol es el centro emocional y visual de la temporada.
• «Momentos» breves: Producidos como el vídeo corto vertical del artículo: fotograma inicial + fotograma final + prompt de movimiento → Generador de Vídeo (Kling 3.0 Pro), 9:16, ~15 s. Cada entrega semanal incluye un pequeño fragmento narrativo.
• PI de Cubcoats: Kali y los otros siete personajes, el mundo de la isla y el estilo artístico cálido y redondeado. Encaja con un relanzamiento centrado en licencias (2026) mediante un producto digital y episódico.

Por qué puede hacerse viral

• Acceso sencillo: Un solo enlace, sin un proceso de incorporación pesado. «Envía una semilla a un amigo» es una acción fácil de compartir.
• Clips tranquilos y bonitos: Los momentos breves funcionan por sí solos y se pueden compartir (en redes sociales: «mira estos 15 segundos»). Tienen potencial para convertirse en memes de forma positiva.
• Formato episódico: «¿Qué hay de nuevo esta semana?» fomenta las visitas recurrentes y la conversación.
• Sutil: Los padres ven una experiencia «tranquila, creativa, sin anuncios y sin estrés»; los niños adquieren rutinas, paciencia y una agradable sensación de sorpresa sin recibir enseñanzas explícitas.

Posible enfoque para el blog de Cinevva

«Llevamos a Kali de un boceto a un vídeo y, después, a un personaje con el que puedes recorrer un mundo. Árbol Dorado es el siguiente paso: un mundo que crece en tiempo real, donde los niños pueden visitarlo, regarlo y ver momentos breves, sin niveles ni presión. El mismo flujo de trabajo. Un formato nuevo».

La Isla de las Palabras de Kali — Resumen

Idea principal: La isla de Cubcoats está dividida en zonas de personajes (el bosque de Kali, la playa de otro personaje). Los niños ayudan a los personajes mediante tareas breves que requieren comprender y expresarse en EN/ZH. Progresión = «Semillas → Brotes → Árboles → Árbol Dorado» (la siguiente zona se desbloquea cuando el árbol de la zona está completo). Recorrido diario de «faroles», tarjetas de frases coleccionables, barras de «ánimo» de los personajes y panel opcional para padres. Al completar una zona, se desbloquean momentos narrativos breves (con el estilo de fotograma inicial/final). Flujo de trabajo: El mismo flujo de trabajo 3D + vídeo para los personajes y los momentos emotivos.

Cubcoats: Historias de la Isla — Resumen

Idea principal: Narrativas episódicas en las que los niños eligen distintas ramas (¿qué dice Kali?, ¿adónde va?). La actividad principal consiste en remezclar: elegir un personaje, un lugar y 2–3 momentos narrativos → generar un «episodio» breve (guion + elementos visuales sencillos o, más adelante, un vídeo corto generado con IA). El aprendizaje es sutil (vocabulario y patrones presentes en los diálogos y las elecciones). Componente social: comparte tu episodio, juega la versión de otra persona y valórala como «amable / divertida / sorprendente». Flujo de trabajo: La misma apariencia de los personajes + el flujo de vídeo de dos fotogramas para los «momentos» generados por los usuarios; 3D para mantener la coherencia de los personajes y del mundo.

Herramientas de Cinevva mencionadas: Generador de Imágenes, Generador de Vídeo (Kling 3.0 Pro), Generador de Modelos 3D, rigging automático y Cinevva Engine. Refleja el flujo de trabajo descrito en «Del boceto al vídeo y al 3D jugable» (2026-03-04).

Por Mariana Muntean, CEO de Cinevva

El equipo de Cinevva acaba de publicar uno de los diarios de ingeniería más transparentes de los últimos tiempos en el desarrollo de videojuegos: una serie de 12 partes que documenta nuestro intento de crear un mundo abierto multijugador que se ejecute íntegramente en el navegador. Sin descargas. Sin tienda de aplicaciones. Solo una URL.

El proyecto abarcó 24 experimentos técnicos que llamamos «spikes»: prototipos breves y específicos, cada uno diseñado para responder una pregunta arriesgada. Todos los spikes se publicaron con código fuente funcional que puedes abrir y ejecutar ahora mismo en tu navegador. La serie fue escrita por Oleg Sidorkin, CTO y cofundador de Cinevva, y se lee menos como marketing y más como un diario de campo desde la primera línea de lo que los navegadores pueden hacer realmente en 2026.

Lo que hace que valga la pena leer la serie —aunque nunca tengas previsto crear sistemas de terreno— es el método que hay detrás. Es un caso práctico sobre cómo reducir el riesgo de un proyecto ambicioso antes de comprometer recursos costosos.

Empezar primero por la pregunta más difícil

La mayoría de los proyectos de mundo abierto fracasan siguiendo una secuencia predecible. Primero tienes un concepto precioso. Después, una escena bonita. Luego descubres que ya habías agotado el presupuesto por fotograma antes incluso de que existiera la jugabilidad.

Nuestro equipo invirtió el orden. El primer spike era feo a propósito: una malla de terreno de 512 metros, 500 objetos instanciados, ruido de altura procedural, un plano de agua y niebla. Sin sombras ni pase de embellecimiento. La única pregunta era si un navegador podía mantener una tasa de fotogramas estable mientras la cámara se desplazaba por el entorno.

Podía. Y ese «sí» estableció lo que Oleg denomina un «contrato de referencia»: un coste medido de una escena mínima que servía como referencia y frente al cual cada función posterior debía justificar su existencia. Si un efecto nuevo se veía genial pero hacía saltar por los aires el presupuesto por fotograma, no se publicaba. Al menos, todavía no.

Ese tipo de disciplina parece obvio. En la práctica, es poco frecuente en entornos de prototipado acelerado donde todo el mundo está entusiasmado con el siguiente logro visual.

La apuesta por las físicas

El segundo experimento abordó un debate arquitectónico que divide a quienes desarrollan juegos para navegador: ¿deben ejecutarse las físicas en el hilo principal, donde es más sencillo, o en un Web Worker, donde no pueden bloquear el renderizado?

Sobre el papel, ejecutar las físicas en un worker es una solución más limpia. En la práctica, preocupa la latencia. Cada evento de entrada debe cruzar dos veces el límite de mensajería: una para llegar al worker y otra para devolver el resultado. Si ese viaje de ida y vuelta es demasiado lento, pulsar una tecla y ver cómo se mueve el personaje se sentirá pesado.

El equipo integró el motor de físicas Rapier —compilado de Rust a WebAssembly— en un worker dedicado, conectó el canal de mensajes y realizó mediciones. La sobrecarga era insignificante. Los controles seguían respondiendo de inmediato. Sin embargo, tuvimos cuidado de señalar que habíamos validado un escenario específico, no una regla universal. Cuando más adelante cambiaran la carga de la GPU y la complejidad del streaming, habría que volver a comprobar las suposiciones.

Los spikes aburridos que salvaron el proyecto

La tercera parte de la serie no incluye capturas de pantalla. Trata sobre tres experimentos poco glamurosos, pero con consecuencias a nivel de producto.

El primero comprobó si los Durable Objects de Cloudflare podían gestionar emisiones de posición en tiempo real con frecuencias de actualización propias de un juego: la columna vertebral del multijugador. Si hubiera fallado, toda la arquitectura de red habría necesitado una fragmentación temprana en lugar de asignar cada isla a una única instancia.

El segundo validó un perfil de calidad para móviles: no un ajuste de escritorio con otro nombre, sino una ruta de renderizado explícita y de bajo coste basada en la misma línea base de terreno. La pregunta era si el mundo podía seguir siendo legible y reactivo bajo las limitaciones de las GPU móviles sin tener que reescribir el renderizador.

El tercero evaluó si los scripts de comportamiento generados por IA para los flujos de trabajo de los creadores serían lo bastante fiables para usarlos en producción.

Ninguno produjo vídeos espectaculares. Los tres fijaron límites estrictos que dieron forma a todas las decisiones arquitectónicas posteriores. Oleg escribe que estos «spikes poco vistosos cambiaron la arquitectura más rápido que los spikes visuales».

Streaming: donde los proyectos bonitos se desmoronan

Puedes ocultar muchas cosas en una imagen estática. No puedes ocultar un tirón de 40 milisegundos al cruzar el límite de un chunk mientras corres.

El equipo probó el streaming antes de crear terreno avanzado, separando deliberadamente las distintas cuestiones. El Spike 6 validó la carga de chunks vecinos con contenido sencillo. Solo después de obtener esa señal clara, el Spike 11 introdujo el streaming de mapas de altura comprimidos con refinamiento progresivo: primero cargaba el terreno con una resolución de 17 muestras, después con 33 y, por último, con la cuadrícula completa de 65 muestras.

La secuencia importó más de lo que esperábamos. Si hubiéramos empezado directamente con chunks de altura comprimidos, cada tirón habría sido ambiguo. ¿Era un problema de decodificación, un bloqueo al subir texturas o un problema al actualizar la geometría? Probar primero el streaming sencillo eliminó toda una categoría de incertidumbre.

De ahí surgió una lección práctica: hay que medir directamente los bloqueos de subida, no inferirlos a partir de los FPS medios. Los promedios ocultan los picos en los tiempos de fotograma, y esos picos son lo que los jugadores realmente perciben.

Las guerras por el presupuesto visual

Tres experimentos distintos atacaron los costes de renderizado de forma aislada, en vez de agruparlos. La densidad de la vegetación y su animación por el viento. Materiales de terreno multicapa con mapeado triplanar para las paredes de los acantilados. Mapas de sombras en cascada bajo una carga de terreno realista.

El spike de vegetación reveló que agrupar las instancias en menos mallas importaba más que reducir la cantidad de polígonos de cada brizna. El spike de materiales determinó que la proyección triplanar sobre superficies verticales justificaba su coste de GPU, pero añadir una quinta capa de mezcla de texturas no. El spike de sombras concluyó que tres cascadas con una resolución de 1024 proporcionaban sombras de contacto aceptables sin superar los 2 milisegundos de tiempo de GPU.

El equipo adoptó una regla tajante: una función solo avanza si puede justificar su coste con datos medidos del tiempo de fotograma. Esa restricción, fijada desde el principio, simplificó considerablemente las decisiones arquitectónicas posteriores en torno al terreno volumétrico y los clipmaps.

El giro que cambió la trayectoria del proyecto

Antes del Spike 10, nuestro modelo mental era «un mundo más grande implica más geometría». Después del Spike 10, pasó a ser «presupuesto de geometría constante y actualización de anillos centrados en la cámara».

Los clipmaps de geometría —anillos concéntricos de terreno centrados en la cámara, cada vez menos detallados— permitían mantener aproximadamente constante la cantidad de triángulos, sin importar la distancia de dibujado. El truco práctico consistía en aplicar geomorphing en los límites de los anillos: mezclar suavemente las alturas de los vértices en el shader para que la transición entre niveles de resolución fuera invisible durante el movimiento.

La metodología de pruebas nos enseñó una lección sutil. Los clipmaps se ven bien en las capturas de pantalla. Sus artefactos solo aparecen durante un movimiento sostenido de la cámara a través de los límites de los anillos. El equipo dedicó tiempo a realizar recorridos a velocidad constante y observar si aparecía ruido temporal. «Las capturas de pantalla mentían», escribe Oleg. «El movimiento decía la verdad».

Adentrarse bajo tierra

Los mapas de altura no pueden representar cuevas. Almacenan un único valor de elevación por cada punto de una cuadrícula. En cuanto necesitas túneles, salientes o paredes de roca excavadas, necesitas terreno volumétrico.

El Spike 12 implementó marching cubes en la GPU mediante shaders de cómputo de WebGPU, extrayendo mallas triangulares de un campo de distancia con signo tridimensional. Cuatro chunks de 64³ se ejecutaban simultáneamente, con actualizaciones de la malla en cada fotograma a partir de modificaciones animadas del SDF. El shader de cómputo se encargaba de todo —evaluar el campo, clasificar las celdas y emitir los vértices— sin ninguna lectura de vuelta en la CPU.

El reto no era conseguir que funcionara. Era lograr que funcionara junto con todo lo demás. La integración con el grafo de escena de Three.js, la gestión del ciclo de vida de los búferes —los búferes de WebGPU no pueden redimensionarse— y el manejo de fences para evitar destruir recursos de GPU que aún estaban en uso: la serie dedica dos partes completas a lo que llamamos «robustecimiento incremental», el proceso poco glamuroso de añadir una capacidad cada vez y comprobar que la capa anterior sigue funcionando después de cada incorporación.

La pesadilla de las uniones

La sección técnicamente más angustiosa de la serie abarca las partes 9 a 11 y explica qué ocurre cuando se encuentran chunks de terreno con resoluciones diferentes.

Cuando un chunk de alta resolución se encuentra junto a uno de baja resolución, sus mallas generadas de forma independiente no se alinean en el límite. El resultado son grietas visibles, bordes parpadeantes y uniones en T por las que se filtra la luz. El algoritmo Transvoxel lo resuelve con celdas de transición especiales que salvan las diferencias de resolución, pero implementarlo correctamente en todas las configuraciones de chunks, con un orden de orientación coherente, una gestión adecuada de los búferes y rangos de dibujado precisos, requirió seis experimentos distintos.

La historia de depuración más memorable del equipo: pasamos dos días persiguiendo un artefacto en una unión que atribuíamos a la lógica de transición. El verdadero culpable eran datos obsoletos. El shader de cómputo de la GPU escribía N vértices en un búfer, pero la llamada de dibujado seguía configurada para renderizar N+M vértices del fotograma anterior. Esos vértices adicionales contenían basura que producía triángulos parpadeantes, finos como cuchillas. La solución fue una sola línea: limitar el rango de dibujado al número de vértices activos indicado por el contador atómico.

«Los errores de renderizado suelen hacerse pasar por errores de generación de mallas», observa Oleg. «La geometría había sido correcta todo el tiempo».

Del caos a la gobernanza

Después de la batalla con las uniones, el equipo sustituyó el comportamiento improvisado de los chunks por un sistema explícito de políticas. A partir de entonces, una función central decidía el nivel de LOD de cada chunk, el modo de renderizado —mapa de altura o marching cubes— y qué caras necesitaban celdas de transición. Los anillos de distancia determinaban el LOD base. Una restricción de adyacencia garantizaba que dos chunks vecinos no difirieran en más de un nivel de resolución. Un mapa de bits de ediciones mantenía los chunks volumétricos en modo marching cubes independientemente de la distancia si contenían modificaciones de creadores.

Las superposiciones de depuración codificadas por colores —verde para los chunks de mapa de altura, azul para los de marching cubes y naranja para las caras de transición— convirtieron «vi un error en algún lugar cerca de esa cresta» en «el error aparece en la posición (142, 12, -67), mirando hacia el noroeste».

«La política no redujo la complejidad», escribe Oleg. «Organizó la complejidad».

El resultado final

El último spike combinó anillos de clipmap, niebla celeste por fragmento —muestreando el color real del skybox en la dirección de cada fragmento de terreno— y la conexión de módulos de Three.js en una demostración unificada. El resultado es un sistema de terreno que superpone edición volumétrica en el campo cercano, chunks de mapas de altura a media distancia y anillos de clipmap en la lejanía, bajo una capa de políticas que gobierna el modo, el LOD y las transiciones.

La serie concluye con varias lecciones que Oleg afirma que repetiría en cualquier proyecto futuro:

• Empieza con spikes de riesgo antes de trabajar en funciones. Resuelve las preguntas del tipo «¿podemos hacer esto siquiera?» antes de invertir en pipelines de contenido.
• Congela líneas base que sabes que funcionan antes de dar grandes saltos de integración. El día dedicado a establecer un punto de control limpio ahorra varios días posteriores buscando regresiones mediante bisección.
• Impón políticas y observabilidad antes de emprender maratones de optimización. Las condiciones identificadas y acompañadas de reglas de activación siempre superan a los errores misteriosos.
• Haz pruebas en movimiento, no con capturas de pantalla. Los saltos, el parpadeo y los tirones del streaming se esconden en las imágenes estáticas.
• Mide el tiempo de fotograma de cada función, no los FPS medios. Los promedios ocultan los picos que los usuarios perciben realmente.
• Publica las partes desordenadas. Los caminos equivocados, la búsqueda de fantasmas y los dos días culpando al sistema incorrecto. Esas son las partes de las que la gente puede aprender de verdad.

Por qué esto importa más allá de Cinevva

La serie es importante por tres motivos que trascienden el pipeline de terreno de una sola empresa.

En primer lugar, demuestra que los shaders de cómputo de WebGPU, las físicas con WebAssembly y los Durable Objects desplegados en el edge han cruzado un umbral. En 2026, un mundo abierto multijugador con terreno volumétrico, edición en tiempo real y LOD por streaming es arquitectónicamente viable en una pestaña del navegador. Hace dos años no lo era.

En segundo lugar, la metodología de spikes —experimentos pequeños y específicos, cada uno de los cuales responde una pregunta arriesgada mediante resultados funcionales y medibles— ofrece un modelo para cualquier equipo que intente hacer algo que podría no funcionar. La disciplina de medir antes de comprometerse, establecer líneas base antes de integrar e identificar los casos límite antes de optimizar se aplica mucho más allá de los sistemas de terreno.

En tercer lugar, la transparencia radical es precisamente el objetivo. Publicar el código fuente de los 24 experimentos, incluidos los callejones sin salida y los desvíos de depuración de dos días, convierte esto en algo más que un blog técnico. Es un cuaderno público de ingeniería que trata al lector como a un colega y no como a un cliente. La serie completa está disponible en nuestra guía de la serie, con todos los prototipos ejecutándose en vivo en el navegador.

Este artículo se publicó originalmente en Medium.

Por Oleg Sidorkin, CTO de Cinevva

Antes, llevar un personaje desde un boceto plano hasta un juego 3D requería un artista conceptual, un modelador 3D, un especialista en rigging, un animador y alguien que lo integrara todo en un motor. Queríamos comprobar qué parte de ese proceso podían resolver por sí solas las herramientas creativas de Cinevva. Esto es lo que descubrimos.

El personaje es Kali the Kitty, de Cubcoats, una marca infantil que vendió más de un millón de sudaderas con capucha y forma de peluche a través de Nordstrom, Amazon y Disney Store. Cubcoats cuenta con ocho personajes originales con personalidades definidas, un mundo insular ficticio y 14 patentes. La marca se relanzará en 2026 como una plataforma centrada en licencias, y queríamos mostrar cómo se ve esa propiedad intelectual cuando va más allá de los productos físicos: un corto vertical y un personaje 3D con rig que puedes controlar en un navegador. Todo lo que aparece a continuación es el resultado real de esa exploración.

Arrastra los visores 3D para rotar alrededor de los modelos. Desplázate por la tira de fotogramas para ver cómo avanza el corto vertical desde el primer fotograma hasta el último.

De una ilustración plana de libro a un personaje que puedes girar

Cubcoats ya contaba con preciosas ilustraciones 2D. La dirección artística de Mimi Chao dio a cada personaje un aspecto cálido, redondeado y dibujado a mano que funciona a la perfección tanto en sudaderas como en libros ilustrados. Pero el arte plano no sirve directamente para un flujo de trabajo 3D. Necesitábamos un personaje de alta fidelidad que pudiera utilizarse como referencia para la generación de vídeo, la creación de la malla y el rigging, siempre con el mismo rostro.

Empezamos introduciendo las ilustraciones originales del libro en nuestro Generador de imágenes y pidiéndole que produjera una versión renderizada en 3D del mismo personaje.

Se mantuvieron las proporciones, la personalidad quedó reflejada y el suave aspecto de dibujo animado en 3D proporcionó a todas las herramientas posteriores una referencia coherente. A partir de ahí, ajustamos la pose y el encuadre exactos hasta fijar una referencia principal.

La pose T es importante porque el rigging requiere que los brazos estén separados del torso. Si te la saltas, la herramienta de rigging automático fusiona los brazos con el cuerpo y no puede continuar. Generamos la pose T a partir del mismo diseño definitivo del personaje para que la silueta y las proporciones se mantuvieran coherentes en cada paso.

Escribe la historia antes de generar nada

Antes de utilizar las herramientas de vídeo, escribimos una escaleta en lenguaje sencillo. El rasgo de personalidad de Kali en el universo de Cubcoats es «Positiva». Es quien consigue que todo el mundo se sienta incluido y mantiene el optimismo cuando las cosas se ponen difíciles. Por eso construimos un arco de diez segundos en torno a esa idea:

Kali entra de noche en un bosque oscuro y brumoso mientras sostiene una pequeña linterna luminosa. Se asusta, se sienta sola y está a punto de rendirse. Entonces descubre detrás de ella un árbol mágico dorado que lo ilumina todo. Asombro, alegría y partículas doradas cayendo como lluvia. Del miedo a la esperanza en un instante.

Ese es todo el argumento. No tiene que ser complejo. Debe condensar un giro emocional en una única toma continua para que el fotograma inicial y el final puedan conectarse de verdad.

Dos fotogramas que enmarcan toda la historia

Generamos dos imágenes estáticas clave a partir de ese argumento mediante nuestro Generador de imágenes. Utilizamos una relación de aspecto vertical para adaptarlas al corto. Los prompts describen exactamente al mismo personaje en dos momentos diferentes.

Prompt del fotograma inicial:

Render 3D animado con estilo Pixar de Kali, una pequeña gatita rosa con grandes ojos oscuros y redondos, orejas rosas y puntiagudas, vientre rosa claro y un rostro redondo y alegre. Está de pie en el límite de un bosque oscuro y brumoso por la noche, sosteniendo una pequeña linterna luminosa con ambas patas. Tiene las orejas ligeramente agachadas y su expresión es nerviosa pero decidida. Iluminación cinematográfica con luz de luna azul y fría desde arriba y un resplandor naranja y cálido procedente de la linterna. Niebla densa entre los troncos oscuros de los árboles del fondo. Ángulo de cámara: plano medio, ligeramente contrapicado. Sin texto ni marca de agua.

Prompt del fotograma final:

Render 3D animado con estilo Pixar de Kali, una pequeña gatita rosa con grandes ojos oscuros y redondos, orejas rosas y puntiagudas y vientre rosa claro. Está de pie frente a un enorme árbol mágico cubierto de flores doradas y resplandecientes, con los brazos completamente extendidos y una enorme sonrisa de alegría. A su alrededor flotan pétalos dorados. El árbol irradia una luz dorada y cálida que ilumina todo el claro del bosque. Sobre ella puede verse el cielo nocturno estrellado. Ángulo de cámara: plano general ligeramente contrapicado, composición de revelación épica. Sin texto ni marca de agua.

Seedance interpola entre estos dos extremos. La descripción del personaje se mantiene idéntica en ambos prompts para que el modelo sepa que se trata del mismo personaje. Solo cambian la escena, la emoción y la cámara.

El vídeo quedó mejor de lo esperado

Cargamos ambos fotogramas en el Generador de vídeo de Cinevva, elegimos Seedance 1.5 Pro, configuramos una relación de aspecto de 9:16 y una duración de 15 segundos, escribimos el argumento en el prompt de movimiento y pulsamos Generar.

El clip interpola entre los dos extremos. El audio nativo se generó en el mismo proceso. Estos son algunos fotogramas extraídos a lo largo de la línea temporal.

De izquierda a derecha: progresión del corto vertical generado.

Usar un fotograma inicial y otro final fue el modo adecuado cuando queríamos conseguir una pose de cierre exacta. Para arcos emocionales más largos, una sola referencia combinada con un prompt funcionó bien con el modo de guion gráfico Kling 3.0 Pro del Generador de vídeo. Distintas configuraciones para distintos objetivos.

El mismo personaje, ahora en 3D

Aquí es donde se pone interesante. La imagen en pose T, perteneciente a la misma familia visual que las referencias del vídeo, se procesó con nuestro Generador de modelos 3D para crear un modelo 3D a partir de una imagen. No se trata de hacer que la malla del juego coincida píxel por píxel con el vídeo. Se trata de hacerla coincidir con el recuerdo del jugador. El personaje del juego debe transmitir la misma personalidad que el del vídeo. Y como fijamos una única identidad visual desde el principio, así fue.

El Generador de modelos 3D produce un archivo GLB con texturas. No está listo para incorporarlo directamente a un juego, pero es claramente Kali. La silueta coincidía. Los materiales se aproximaban bastante. Era suficiente para seguir adelante.

Arrastra estos modelos para girarlos

Resultado sin procesar del Generador de modelos 3D. Sin rig, solo una malla con texturas. A su lado, el mismo personaje después de aplicar rigging automático y una animación de caminar integrada.

Rigging y animación

El Generador de modelos 3D proporciona una malla. Para que esa malla pueda moverse, necesita un esqueleto y animaciones. Nuestra plataforma se encarga automáticamente del rigging: subes el GLB y recibes un modelo con rig y una biblioteca completa de animaciones. Ciclos de caminar, respiración en reposo, saltos y todo lo que necesita un personaje de videojuego.

La animación de caminar predeterminada parecía casi correcta, pero no del todo. Los brazos de Kali quedaban demasiado pegados al cuerpo y su cabeza se inclinaba en un ángulo ligeramente incorrecto. Ambas cosas tenían sentido para un humanoide genérico, pero no encajaban con una gatita de dibujos animados y formas redondeadas. Así que añadimos correcciones de huesos en tiempo de ejecución al código del juego: un desplazamiento en los hombros que empuja los brazos hacia fuera y una corrección de la rotación de la cabeza que elimina la inclinación. Pequeños ajustes, gran diferencia. Sin ellos, parecía rígida y robótica. Con ellos, volvía a parecer Kali.

Controlar al personaje en un navegador

Incorporamos el modelo con rig al motor de Cinevva. Cámara en tercera persona, movimiento con WASD, objetos coleccionables repartidos por el escenario y cámara orbital cuando el personaje está inactivo. Conseguir que la mezcla de animaciones funcionara correctamente requirió varias iteraciones: fundidos entre las animaciones de reposo y de caminar, normalización de la altura, corrección del eje frontal y ajuste de los desplazamientos de los huesos. La cámara en tercera persona detrás del personaje completa el recorrido desde el boceto hasta algo que puedes controlar.

Pruébalo. Usa WASD para moverte.

Lo que le diría a alguien que quisiera hacerlo mañana

Fija un único diseño del personaje antes de utilizar cualquier herramienta de generación. Cada minuto que dediques a perfeccionar esa referencia te ahorrará una hora persiguiendo la coherencia más adelante.

Escribe primero un argumento breve. Después, genera los fotogramas inicial y final con el Generador de imágenes. Mantén las imágenes de referencia dentro de los límites de tamaño de la API. Utiliza una pose T procedente del mismo sistema de diseño cuando la introduzcas en el Generador de modelos 3D.

Carga ambos fotogramas en el Generador de vídeo y deja que interpole entre ellos. Para la malla del juego, aplica rigging al modelo mediante la plataforma y ajusta los desplazamientos de los huesos en tiempo de ejecución si las animaciones predeterminadas no se adaptan del todo a las proporciones de tu personaje.

Hace dos años, este flujo de trabajo no existía. Habrías necesitado un equipo y un presupuesto. Ahora solo necesitas un boceto y las herramientas creativas de Cinevva. Creo que es un cambio importante en cuanto a quién puede dar vida a un personaje.

Herramientas de Cinevva utilizadas: Generador de imágenes, Generador de vídeo, Generador de modelos 3D, rigging automático y motor de Cinevva. Refleja el estado de las herramientas a principios de 2026.

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Estamos construyendo un mundo abierto multijugador que se ejecuta íntegramente en el navegador. Sin instalación, sin tienda de aplicaciones, solo una URL. El mayor riesgo inicial era evidente: ¿puede un navegador renderizar un mundo 3D persistente con una tasa de fotogramas jugable y, al mismo tiempo, dejar margen para la jugabilidad, la física y la red?

La mayoría de los proyectos de mundo abierto fracasan en un orden predecible. Primero tienes un buen concepto. Después, una escena bonita. Luego te das cuenta de que ya has agotado el presupuesto por fotograma antes de que exista la jugabilidad.

Queríamos resolver la cuestión del presupuesto de renderizado antes de invertir en cualquier otra cosa. Por eso, el Spike 1 se saltó el tráiler vistoso y fue directamente a las mediciones.

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

La configuración era sencilla a propósito. Una malla de terreno de 512 metros, altura procedural generada mediante varias capas de ruido sinusoidal con atenuación hacia los bordes de la isla, un plano de agua, niebla atmosférica y 500 objetos instanciados. Usamos WebGL puro con Three.js, mapeo de tonos ACES y sin sombras.

No nos importaba su aspecto. Nos importaba que la escena se mantuviera estable al mover la cámara por ella.

De este spike surgieron dos conclusiones que dieron forma a todo el proyecto.

En primer lugar, confirmamos que teníamos un margen real en equipos de escritorio si manteníamos una primera implementación disciplinada. Eso nos dio confianza para intentar más adelante una arquitectura de terreno más compleja.

En segundo lugar, establecimos un contrato de referencia. Cada spike posterior tenía que explicar su coste en relación con esta escena. Si una funcionalidad se veía bien, pero costaba demasiado, no avanzaba a la siguiente fase.

Esa disciplina basada en una referencia se volvió crucial más adelante, cuando nos encontramos con artefactos en las uniones, transiciones entre distintos niveles de LOD y mallado controlado por cómputo. Sin una referencia estable, todos los errores parecen más grandes de lo que son.

En la parte 2 pasamos del renderizado a la respuesta de los controles. La física en un worker suena muy bien en los documentos de arquitectura. Pero solo importa si el personaje sigue respondiendo de inmediato al pulsar una tecla.

Tecnología mencionada en este capítulo

Terreno basado en mapas de altura. Una cuadrícula 2D en la que cada celda almacena un único valor de elevación. La GPU desplaza una malla plana en el shader de vértices para crear la superficie del terreno. Los mapas de altura son compactos (un chunk de 65x65 ocupa unos 8 KB a 16 bits), están bien adaptados a la GPU y se renderizan con rapidez. Su limitación es que no pueden representar cuevas, salientes ni ninguna superficie que se pliegue sobre sí misma. Para obtener más información sobre las limitaciones de los mapas de altura y las alternativas posteriores, consulta nuestra guía de generación de paisajes.

Three.js. La biblioteca de renderizado que usamos durante todo este proyecto. Three.js abstrae WebGL 2 —y, posteriormente, WebGPU— mediante un grafo de escena con cámaras, luces, materiales y objetos geométricos. Proporciona InstancedMesh para renderizar muchas copias de una misma geometría en una sola llamada de dibujo, además de descarte por frustum, materiales PBR y posprocesamiento. Consulta Three.js en GitHub. Para saber cómo encaja Three.js en la pila tecnológica de un mundo abierto para navegador, consulta nuestra guía de tecnologías 3D para el navegador.

InstancedMesh. Una funcionalidad de Three.js que renderiza N copias de una misma geometría con una sola llamada de dibujo, cada una con una posición, rotación y escala diferentes. Las transformaciones de cada instancia se almacenan en un búfer de atributos matriciales. Así renderizamos 500 objetos en el Spike 1 sin realizar 500 llamadas de dibujo independientes. Para vegetación a gran escala, el descarte de instancias controlado por la GPU lleva este enfoque aún más lejos. Consulta nuestra guía de paisajes sobre el descarte de vegetación mediante la GPU.

Presupuesto por fotograma. A 60 fps, cada fotograma dispone de $\frac{1000\text{ms}}{60}\approx 16.7$ ms para todo: lógica de JavaScript, física, renderizado y composición. Un spike de «comprobación de presupuesto» mide cuánto consume una escena de referencia, de modo que el margen restante para todo lo que se añada después sea $t_{\text{features}}=16.7-t_{\text{baseline}}$. Si la escena de referencia ya consume 12 ms, solo quedan unos 4,7 ms para la jugabilidad, la física y la red en conjunto. Este enfoque procede del desarrollo de mundos abiertos AAA, donde GTA V, Skyrim y Elden Ring emplean técnicas agresivas de LOD y streaming para mantenerse dentro de presupuestos por fotograma fijos.

Parte 1 de 12.
Siguiente: Parte 2: Física en un worker y el temor al retardo de entrada
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Si desarrollas multijugador para navegador durante suficiente tiempo, tarde o temprano surge este debate.

«Ejecutar las físicas en un worker ofrece una arquitectura limpia. Ejecutarlas en el hilo principal parece más seguro».

Ambas afirmaciones pueden ser ciertas. Lo importante es cómo se sienten los controles y cuál es la latencia con entradas reales.

Creamos el Spike 2 para responder a esa cuestión con mediciones, no con opiniones.

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

Reutilizamos el terreno del Spike 1 e integramos Rapier en un worker de módulo dedicado. Enviábamos el estado de entrada al worker en cada fotograma, ejecutábamos allí el paso de simulación y devolvíamos la posición autoritativa al renderizador.

Las métricas clave fueron la latencia entre la entrada y el movimiento visible, así como el tiempo de cada paso de físicas. También observamos si aparecían tirones durante el movimiento normal, las aceleraciones al esprintar y la cadencia de los saltos.

El resultado fue mejor de lo esperado. Con la estructura y la cadencia de nuestros mensajes, el límite entre hilos no fue el factor dominante de la latencia. Los controles seguían respondiendo de inmediato, que era lo único que les importaría a los jugadores.

Uno de los desafíos de esta fase fue el riesgo de interpretar mal los resultados. Tras un resultado satisfactorio, los equipos suelen generalizar en exceso y dar por zanjada para siempre la cuestión arquitectónica. No es así. Solo validamos un escenario concreto y un perfil de hardware. Los spikes posteriores aún debían volver a comprobar esas suposiciones cuando cambiara la carga sobre la GPU y el streaming.

Este spike también mejoró nuestro proceso. Empezamos a mostrar de forma predeterminada la telemetría de tiempos en el HUD de los spikes interactivos. Eso hizo que las conversaciones del equipo pasaran de «algo no se siente bien» a «esta ruta añadió 1,2 ms».

En la parte 3 abordamos los experimentos menos vistosos que evitaron costosas sorpresas más adelante: carga de difusión, limitaciones de los dispositivos móviles y fiabilidad de la generación de comportamientos.

Tecnología mencionada en este capítulo

Rapier. Un motor de físicas escrito en Rust que se compila a WebAssembly para utilizarse en el navegador. Gestiona cuerpos rígidos, colisionadores, articulaciones, controladores de personajes y lanzamiento de rayos con un rendimiento entre 2 y 3 veces superior al código nativo. Para los mundos abiertos, Rapier proporciona controladores para los personajes de los jugadores (caminar sobre el terreno, subir escalones y deslizarse por pendientes), colisiones de objetos, lanzamiento de rayos para las interacciones y volúmenes de activación. Consulta la documentación de Rapier y nuestra guía tecnológica de 3D para navegador sobre físicas.

Web Workers. Hilos del navegador que ejecutan JavaScript (o Wasm) fuera del hilo principal. Ejecutar la simulación de físicas en un worker significa que una llamada pesada a world.step() no bloquea el renderizado. El hilo principal envía el estado de entrada al worker en cada fotograma mediante postMessage y recibe a cambio las posiciones autoritativas. La penalización de latencia corresponde a los dos saltos de los mensajes (aproximadamente entre 0,1 y 0,5 ms cada uno en equipos de escritorio). La ventaja es que el hilo de renderizado nunca se bloquea al detectar colisiones. Los objetos transferibles (transferencia de ArrayBuffer) eliminan el coste de las copias para matrices de posiciones grandes.

WebAssembly (Wasm). Un formato de instrucciones binarias que se ejecuta en los navegadores a una velocidad cercana a la nativa. Rapier, Havok y Recast se compilan a Wasm. En Rapier-Wasm, el paso de físicas suele tardar entre 0,5 y 2 ms para unos cientos de cuerpos, frente a los 5-15 ms de una implementación equivalente en JavaScript. Los módulos Wasm se cargan como archivos .wasm obtenidos junto con el código de enlace de JavaScript. Consulta la especificación de WebAssembly.

Latencia entre la entrada y la imagen. El tiempo transcurrido entre una pulsación de tecla y el cambio visual resultante en pantalla. Para que el movimiento se perciba como «inmediato», debe mantenerse por debajo de unos 80 ms. En una configuración con las físicas ejecutándose en un worker, los tiempos de la cadena se suman:

Evento keydown (hilo principal), postMessage al worker y de vuelta ($2t_{\text{msg}}$), paso de físicas, aplicación de la nueva posición por parte del renderizador y, por último, la siguiente sincronización vertical. Cada término es pequeño por sí solo (aproximadamente entre 0,1 y 0,5 ms por salto de mensaje en equipos de escritorio), pero se acumulan; por eso medimos $L$ directamente en lugar de confiar en el diagrama de arquitectura.

Parte 2 de 12.
Anterior: Parte 1: Empezamos intentando romperlo
Siguiente: Parte 3: Los spikes poco vistosos que nos salvaron
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

¿Es tu primera vez aquí? Consulta la guía de la serie. Explica qué es una prueba técnica y enlaza todas las partes.

Esta parte tiene menos capturas de pantalla llamativas y más garantías arquitectónicas.

Después de las pruebas 1 y 2, realizamos tres comprobaciones de riesgo que parecían pequeñas, pero tuvieron un impacto a nivel de producto.

La primera fue la distribución de difusiones con Durable Objects. Probamos la distribución de posiciones entre múltiples clientes con frecuencias de actualización similares a las de un juego y medimos la distribución de la latencia, el uso de CPU por actualización y la integridad de la entrega. Si hubiera fallado, habríamos adoptado desde el principio una arquitectura fragmentada, en lugar de asignar cada isla a una única instancia.

La segunda fue la validación de las limitaciones móviles. No se trataba de un ajuste predefinido para escritorio rebautizado como móvil, sino de un perfil explícito de bajo coste basado en el mismo terreno de referencia.

Abrir el perfil móvil en una pestaña nueva ↗ · Ver el código fuente

Redujimos la densidad de segmentos, el número de objetos, la presión sobre la resolución de renderizado y el alcance de la niebla. La pregunta era sencilla: ¿puede este mundo seguir siendo legible y ágil bajo las limitaciones propias de los dispositivos móviles sin tener que reescribir todo el renderizador?

La tercera fue la fiabilidad de la generación de comportamientos para los flujos de trabajo de los creadores. Evaluamos la tasa de JSON válido, la corrección semántica respecto a las primitivas esperadas y la latencia de respuesta. Si hubiera fallado, habríamos pasado a una creación de comportamientos estrictamente basada en formularios.

La idea clave de este capítulo es que estas pruebas poco vistosas cambiaron la arquitectura más rápido que las pruebas visuales. Establecieron límites firmes para la topología de red, las promesas en móviles y la experiencia de usuario de las herramientas.

En la parte 4 volvemos al trabajo visible sobre el terreno y probamos el comportamiento de la carga progresiva durante el movimiento, no solo mediante capturas de pantalla de cargas estáticas.

Tecnología mencionada en este capítulo

Cloudflare Durable Objects. Instancias sin servidor con estado, desplegadas en el edge, con persistencia integrada y compatibilidad con WebSocket. Cada Durable Object mantiene el estado autoritativo de un fragmento —o chunk— del mundo. Los jugadores se conectan mediante WebSocket y reciben difusiones de posición de otros jugadores del mismo fragmento. Cuando un jugador se desplaza a un chunk adyacente, se conecta al Durable Object de ese chunk. Los Durable Objects guardan automáticamente el estado en disco y pueden escalar hasta miles de instancias simultáneas. Consulta la documentación de Cloudflare Durable Objects y nuestra guía de tecnología 3D para navegador sobre redes multijugador.

Fragmentación espacial. División del mundo entre instancias de servidor según la región geográfica. Cada fragmento controla un área rectangular de la cuadrícula del mundo. A medida que cambia la densidad de jugadores, los fragmentos pueden dividirse o fusionarse. Los jugadores próximos al límite de un fragmento ven el contenido de ambos mediante consultas de visibilidad entre fragmentos. Así es como EVE Online gestiona a miles de jugadores en un único universo.

Distribución de difusiones mediante WebSocket. Distribución de actualizaciones de posición en tiempo real desde un servidor a numerosos clientes conectados. El ancho de banda descendente por cliente aumenta linealmente con la cantidad de jugadores visibles:

Con frecuencias de actualización propias de un juego (20-30 Hz), cada jugador genera $b_{\text{player}}\approx 800$ bytes/segundo de datos de posición, por lo que tener 200 jugadores visibles consume $200\times 800=160$ KB/s por cliente. El coste para el servidor de un enfoque ingenuo de todos contra todos es aún peor, pues crece como $N^2$. Precisamente por eso, el filtrado por relevancia —la gestión espacial de áreas de interés— limita $N_{\text{visible}}$ antes de enviar los datos a cada conexión dentro del tiempo disponible por actualización. Consulta nuestra guía sobre redes para conocer las ventajas y desventajas de la compresión delta y de las distintas frecuencias de actualización.

Limitaciones del renderizado móvil. Las GPU móviles ofrecen entre 1/5 y 1/10 del rendimiento de las GPU de escritorio, tienen un límite de memoria de aproximadamente 1 GB —frente a 2-4 GB en equipos de escritorio— y reducen su rendimiento por temperatura bajo cargas prolongadas. Un perfil de calidad móvil reduce la densidad de segmentos, el número de objetos, la resolución de renderizado, la distancia de dibujado y la calidad de las sombras. El objetivo no es igualar la calidad de escritorio, sino mantener la legibilidad y la capacidad de respuesta. Consulta las cifras de rendimiento 3D en el navegador para ver pruebas de rendimiento con GPU reales.

Parte 3 de 12.
Anterior: Parte 2 - La física en un worker y el temor al retardo de entrada
Siguiente: Parte 4 - Carga progresiva antes que terrenos sofisticados
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

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

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

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

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

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

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

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

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

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

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

Tecnología mencionada en este capítulo

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

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

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

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

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

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Este fue el capítulo en el que la ambición visual se encontró con la aritmética.

Dividimos el coste de renderizado en spikes independientes porque los resultados combinados son difíciles de diagnosticar. Si activas todo a la vez, solo descubres que el fotograma tarda demasiado. No descubres qué función se ha comido el presupuesto.

El spike 7 se centró en la densidad de la vegetación y el coste de la animación. El enfoque consistía en dispersarla en tiempo de ejecución a partir de mapas de densidad de 32x32 por fragmento de terreno, que alimentaban grandes conjuntos de InstancedMesh. Cada brizna de hierba y grupo de arbustos recibía viento en el sombreador de vértices, controlado mediante una textura de ruido en desplazamiento. La cifra clave que vigilábamos no era el número de triángulos, sino la sobrecarga de las llamadas de dibujado y el rendimiento de vértices en GPU de gama media. Descubrimos que agrupar las instancias en menos mallas importaba más que reducir el número de polígonos de cada brizna.

Abrir el spike 7 en una pestaña nueva ↗ · Ver el código fuente

El spike 8 llevó más lejos la complejidad de los materiales del terreno. Mezcla multicapa ponderada según el ángulo de la pendiente y la altitud, proyección triplanar opcional para las paredes de los acantilados y mapas de normales por capa. El sombreador realizaba splatting en función de la pendiente con cuatro capas de texturas, cada una de las cuales requería una muestra difusa y otra de normales. Eso supone $4\times 2=8$ lecturas de textura por fragmento antes de añadir cualquier iluminación, y la cifra aumenta linealmente con el número de capas, por lo que una quinta capa implica 10 lecturas por píxel. Hicimos perfiles específicamente en GPU integradas de Intel para determinar el mínimo. La conclusión fue que la proyección triplanar en superficies verticales justificaba su coste, pero añadir una quinta capa de splat no.

Abrir el spike 8 en una pestaña nueva ↗ · Ver el código fuente

El spike 9 se centró en el coste de los mapas de sombras en cascada con una carga realista de terreno y objetos. La referencia inicial era CSM con tres cascadas. Hicimos pruebas específicamente con el sol en posiciones de ángulo bajo, porque es ahí donde la presión sobre las cascadas alcanza su punto máximo. La cascada lejana cubre una enorme sección del frustum, y el detalle de las sombras viene determinado por la densidad de téxeles, $\rho \approx \frac{R^2}{A}$ (un mapa de sombras de resolución $R$ extendido sobre un área de terreno $A$). Un único mapa para toda la distancia de visión hace que $A$ sea enorme y que $\rho$ se desplome. Las cascadas solucionan esto dividiendo el frustum para que cada sección tenga su propio mapa de $R\times R$ sobre un $A$ pequeño, lo que mantiene $\rho$ aproximadamente constante desde las zonas cercanas hasta las lejanas. Medimos la diferencia de tiempo de GPU entre dos y cuatro cascadas, y después entre resoluciones de mapa de sombras de 1024 y 2048. El resultado fue que tres cascadas a 1024 nos proporcionaban sombras de contacto aceptables cerca de la cámara sin superar los 2 ms de tiempo de GPU en nuestro hardware objetivo.

Abrir el spike 9 en una pestaña nueva ↗ · Ver el código fuente

Lo difícil de esta fase fue mantener la disciplina de producto. Algunos efectos se veían excelentes y, aun así, tuvimos que limitarlos porque consumían una parte excesiva del presupuesto por fotograma en relación con su impacto visual.

Nuestra regla pasó a ser sencilla. Una función solo sigue adelante si puede justificar su coste con datos medidos de tiempo por fotograma.

Parece obvio. No es habitual en ciclos de prototipado rápido, donde todo el mundo está entusiasmado con la siguiente mejora visual. Aplicar esta regla desde el principio simplificó mucho las decisiones arquitectónicas posteriores sobre clipmaps y zonas volumétricas, porque ya conocíamos el coste individual de cada función que competía por los mismos 16 ms.

En la parte 6 llegamos al primer gran cambio de rumbo en la arquitectura del terreno con los clipmaps de geometría.

Tecnología mencionada en este capítulo

InstancedMesh y vegetación en la GPU. InstancedMesh de Three.js renderiza N copias de la misma geometría con una sola llamada de dibujado. Para la vegetación, un mapa de densidad (32x32 por fragmento) controla la dispersión en tiempo de ejecución de briznas de hierba y grupos de arbustos en búferes de instancias. La animación del viento se ejecuta en el sombreador de vértices mediante una textura de ruido en desplazamiento. A gran escala, ComputeInstanceCulling de WebGPU elimina las instancias que están fuera de pantalla o demasiado lejos antes de la rasterización, e IndirectBatchedMesh empaqueta varios tipos de vegetación en un único búfer que se dibuja mediante multi-draw indirecto. Consulta nuestra guía de paisajes sobre el culling de vegetación en la GPU.

Mapeado triplanar. Las texturas con mapeado UV estándar se estiran en pendientes pronunciadas porque las coordenadas UV se comprimen. El mapeado triplanar proyecta las texturas a lo largo de los tres ejes (X, Y, Z) y las mezcla según la normal de la superficie. Las paredes de los acantilados reciben la proyección X o Z (sin estiramiento) y el terreno llano recibe la proyección Y. La mezcla es suave y automática, sin necesidad de desplegar las UV. Para terrenos PBR, se aplican los mismos pesos de mezcla a los canales de albedo, normales, rugosidad y oclusión ambiental. Consulta los detalles del mapeado triplanar.

Splatting de materiales basado en la pendiente y la altitud. En lugar de usar mapas de splat pintados a mano, los materiales se asignan mediante procedimientos en el sombreador de fragmentos según las propiedades del terreno. El terreno llano a baja altitud recibe hierba; las pendientes pronunciadas, roca; las zonas de gran altitud, nieve (solo en superficies lo bastante planas como para que se acumule); y las zonas cercanas al nivel del mar, arena. Las transiciones usan smoothstep para lograr una mezcla suave. En nuestra implementación, cada fragmento de terreno evalúa cuatro capas de texturas con muestras difusas y de normales por capa, lo que da como resultado ocho lecturas de textura por fragmento antes de la iluminación. Consulta la asignación de materiales según la pendiente y la altitud.

Mapas de sombras en cascada (CSM). CSM divide el frustum de visión de la cámara en 3-4 intervalos de distancia (cascadas). Cada cascada renderiza un mapa de sombras desde la perspectiva del sol con una resolución adaptada a su distancia. Las cascadas cercanas reciben sombras de alta resolución (sombras de contacto detalladas bajo árboles y edificios), mientras que las lejanas reciben una resolución menor (amplias sombras de montañas). El sombreador del terreno toma muestras de todas las cascadas y selecciona la adecuada para cada fragmento. Coste de rendimiento: 3-4 cascadas a 1024x1024 añaden unos 0,5-1 ms para renderizar los mapas de sombras, más unos 0,2-0,3 ms para el muestreo. Consulta sombras para terrenos.

Parte 5 de 12.
Anterior: Parte 4 - Streaming antes que terrenos sofisticados
Siguiente: Parte 6 - Los clipmaps cambiaron el rumbo
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Antes del Spike 10, nuestro modelo mental seguía siendo «un mundo más grande implica más geometría». Después del Spike 10, pasó a ser «un presupuesto de geometría constante con actualizaciones de anillos centrados en la cámara». Ese cambio alteró la trayectoria del proyecto.

La idea en la que se basan los clipmaps de geometría es sencilla. El terreno se renderiza como un conjunto de anillos concéntricos centrados en la cámara. El anillo más interno tiene la mayor densidad de vértices. Cada anillo exterior $k$ duplica el espaciado entre vértices, $s_k=s_0\cdot 2^k$, por lo que cubre $4\times$ el área de terreno del anillo situado en su interior.

Esa duplicación es el verdadero truco. La distancia de visión crece geométricamente con el número de anillos, $d_{\text{view}}\approx s_0\cdot 2^L$, mientras que el coste en vértices solo crece de forma lineal:

para $L$ anillos de $N\times N$ vértices cada uno. Duplicar la distancia visible cuesta un anillo más, no cuatro veces más geometría. El número de triángulos se mantiene aproximadamente constante sin importar el tamaño del mundo, porque siempre se renderizan los mismos $L$ anillos con la misma resolución.

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

El truco práctico fue aplicar geomorfismo en los límites de los anillos. Cuando un vértice pasa de un anillo de LOD al siguiente, su altura debe mezclarse suavemente entre la muestra de alta resolución y la de baja resolución. De lo contrario, aparecen saltos visibles cada vez que la cámara se mueve y los anillos cambian de posición. Lo resolvimos con un factor de mezcla basado en la distancia del vértice al borde del anillo, interpolando la altura en el shader de vértices:

donde $d$ es la distancia del vértice a la cámara. Dentro del anillo ($d\le d_{\text{near}}$), el vértice utiliza su altura a resolución completa; cuando alcanza el siguiente anillo ($d\ge d_{\text{far}}$), ya ha migrado a la altura de baja resolución que utilizará ese anillo, por lo que no queda ningún salto por producirse.

Una lección sutil surgió durante las pruebas de movimiento de la cámara. Es fácil evaluar los clipmaps en capturas estáticas y pasar por alto los artefactos de transición. Dedicamos tiempo a realizar recorridos a velocidad constante a través de los límites de los anillos y a observar si aparecía ruido temporal. Las capturas mentían. El movimiento decía la verdad.

Este spike también nos proporcionó un límite arquitectónico claro. Con el tiempo, el terreno del campo cercano podía volverse dinámico y costoso, con edición volumétrica, materiales más complejos e interacción física. El terreno del campo lejano podía seguir siendo estable, predecible y barato. Esa separación se convirtió en la columna vertebral de todas las decisiones arquitectónicas a partir de ese momento.

Si estás evaluando los clipmaps para tu propio proyecto, prueba bucles de estrés, no escenas bonitas. Los recorridos largos, los cambios de altitud de la cámara y los cruces repetidos de límites son los que revelan los problemas reales.

En la parte 7 añadimos mallado volumétrico y pasamos de «el terreno como superficie» a «el terreno como volumen editable». Fue entonces cuando este proyecto dejó de ser un renderizador y empezó a convertirse en un editor de mundos.

Tecnología mencionada en este capítulo

Clipmaps de geometría. Presentados por Losasso y Hoppe en SIGGRAPH 2004 (artículo), los clipmaps de geometría renderizan el terreno como anillos cuadrados concéntricos centrados en la cámara. Cada anillo cubre el doble de área que el anterior con la mitad de resolución de vértices. El número total de vértices es constante: aproximadamente $N^2\cdot L$. Con $N=256$ y $L=8$ niveles, eso equivale a ${256}^2\times 8\approx \mathrm{524,000}$ vértices, independientemente del tamaño del mundo. La CPU actualiza los datos del mapa de alturas de cada anillo a medida que se mueve la cámara. El shader de vértices lee la altura de una textura y desplaza la cuadrícula plana. Consulta nuestra guía de paisajes sobre clipmaps de geometría y GPU Gems 2, capítulo 2.

Geomorfismo. El mayor artefacto visual del LOD de terreno son los saltos: los vértices cambian bruscamente cuando una sección pasa a otro nivel de LOD. El geomorfismo los elimina mezclando las posiciones de los vértices entre niveles de LOD a lo largo de una zona de transición. Cada vértice almacena tanto su altura del LOD actual como su altura del LOD de menor resolución. Un factor de transformación basado en la distancia a la cámara interpola suavemente entre ambas: morphedHeight = mix(fineLodHeight, coarseLodHeight, smoothstep(lodNear, lodFar, distance)). La zona de transición suele ocupar el 20 % exterior de cada anillo. A velocidades normales de cámara, la transición es invisible. Consulta los detalles sobre el geomorfismo.

CDLOD (clipmaps adaptativos con quadtree). Una mejora de los clipmaps de anillos fijos propuesta por Strugar (2014, artículo). En lugar de usar anillos concéntricos con resolución uniforme, CDLOD utiliza un quadtree que se adapta a la complejidad del terreno. Las zonas planas utilizan nodos de baja resolución, mientras que las zonas con mucho detalle —acantilados o crestas— reciben subdivisiones más finas. Esto es importante para los mundos creados por usuarios, donde la complejidad puede variar enormemente entre distintos chunks. Consulta CDLOD en nuestra guía de paisajes.

Parte 6 de 12.
Anterior: Parte 5: Presupuestando los elementos vistosos
Siguiente: Parte 7: Marching cubes y las primeras cuevas de verdad
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Los mapas de altura son estupendos hasta que necesitas voladizos.

En cuanto quieres túneles excavados, salientes rocosos flotantes o techos de cuevas, una pipeline basada exclusivamente en campos de altura empieza a limitarte. Un mapa de altura almacena un valor Y por cada coordenada XZ. Es físicamente incapaz de representar cualquier superficie que se pliegue sobre sí misma. Necesitábamos una representación volumétrica.

El Spike 12 implementó marching cubes en la GPU mediante shaders de cómputo de WebGPU. El algoritmo evalúa un campo de distancia con signo (SDF) sobre una cuadrícula 3D y extrae una malla de triángulos en la superficie donde se cruza el valor cero. Cada celda tiene 8 vértices, y cada uno está dentro o fuera de la superficie, lo que da $2^8=256$ patrones de signos posibles. Una tabla de consulta asigna cada patrón a un conjunto de triángulos. Los vértices se sitúan sobre las aristas de la celda en el punto donde el campo cruza el cero. Para una arista entre los vértices $a$ y $b$, con valores de campo $f_a$ y $f_b$, la interpolación lineal coloca el vértice en

que es la fracción del recorrido a lo largo de la arista donde el campo alcanza el valor cero. Como $f_a$ y $f_b$ tienen signos opuestos en una arista que cruza la superficie, $t$ siempre se encuentra en $[0,1]$. Ejecutamos este proceso simultáneamente en cuatro chunks activos de ${64}^3$ y probamos ediciones animadas del SDF con regeneración de la malla en cada fotograma.

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

El primer logro fue ganar confianza en la propia pipeline de cómputo. Una sola llamada podía evaluar el SDF, clasificar las celdas y emitir vértices en un búfer de la GPU sin ninguna lectura de vuelta por parte de la CPU. El segundo logro fue descubrir lo rápido que «funciona» se convierte en una búsqueda de artefactos. Los triángulos ausentes rara vez se debían a un problema teórico de marching cubes. Solían deberse a discrepancias en los índices de la tabla, rangos de dibujo incorrectos que leían más allá del número de vértices activos o interacciones en casos límite cerca de las fronteras de los chunks, donde no estaban disponibles las muestras del SDF vecino.

Este spike nos obligó a pensar en zonas. Cerca de la cámara, quieres libertad volumétrica para que los jugadores puedan tallar, excavar y ver cuevas. Lejos de la cámara, quieres la eficiencia de los clipmaps, donde un mapa de altura plano resulta más barato y perfectamente adecuado. Esa dualidad se convirtió en la columna vertebral de la arquitectura que seguimos perfeccionando a partir del Spike 13.

Uno de mis momentos favoritos durante la depuración fue activar la vista de estructura alámbrica mientras se ejecutaban las ediciones. Ver cómo la topología se formaba y se disolvía en tiempo real hacía que las concesiones de calidad fueran evidentes de inmediato. Podías ver dónde la densidad de vértices era suficiente, dónde se volvía demasiado baja y exactamente dónde las transiciones de LOD acabarían necesitando compatibilidad con Transvoxel para evitar grietas.

En la parte 8 abordamos el reto de la integración. Mantener las mallas generadas directamente mediante cómputo y la lógica del grafo de escena de Three.js dentro de una única pipeline de renderizado estable fue más difícil de lo que sugería la demo aislada.

Tecnología mencionada en este capítulo

Marching cubes. Un algoritmo para extraer una malla de triángulos de un campo escalar 3D (Lorensen y Cline, 1987). Cada celda de una cuadrícula 3D regular se clasifica muestreando el campo en sus 8 vértices. El patrón de signos produce un índice de caso (0-255), y una tabla de consulta asigna cada caso a un conjunto de triángulos. Los vértices se colocan sobre las aristas de la cuadrícula interpolando entre sus dos extremos. El algoritmo es altamente paralelizable, ya que cada celda se procesa de forma independiente, lo que lo hace ideal para el cómputo en la GPU. Consulta nuestra guía sobre paisajes acerca de los SDF y marching cubes.

Campos de distancia con signo (SDF). Una representación volumétrica que almacena, en cada punto del espacio 3D, la distancia con signo hasta la superficie más cercana. Los valores positivos están fuera, los negativos están dentro y el cruce por cero constituye la superficie. Los SDF pueden representar formas 3D arbitrarias: cuevas, arcos, voladizos y geometría flotante que los mapas de altura no pueden expresar. La edición se realiza de forma natural mediante operaciones de conjuntos sobre el campo. Añadir material (la unión de dos formas) se expresa como $d=min(d_1,d_2)$; eliminarlo (excavar), como $d=max(d_1,-d_2)$, con la forma de sustracción negada; y una mezcla suave utiliza un mínimo suavizado como

donde $k$ controla el radio de mezcla. Cuando $k\to 0$, la expresión vuelve a convertirse en un $min$ estricto. Consulta la representación de terrenos mediante SDF.

Shaders de cómputo de WebGPU. Programas de GPU que ejecutan cálculos de propósito general sin estar ligados a la pipeline de rasterización. Un shader de cómputo lanza grupos de trabajo compuestos por hilos que se ejecutan en paralelo. Para marching cubes, cada hilo procesa una celda de la cuadrícula: muestrea el SDF, clasifica la celda, consulta la triangulación, interpola los vértices de las aristas y los añade a un búfer de malla mediante contadores atómicos. No se necesita ninguna lectura de vuelta por parte de la CPU, porque el búfer de salida se utiliza directamente como datos de vértices para el renderizado. El proyecto webgpu-marching-cubes de Will Usher demuestra el procesamiento en tiempo real de una cuadrícula de 256^3 en el navegador. Consulta nuestra guía sobre paisajes acerca del LOD controlado mediante WebGPU.

Arquitectura híbrida de mapa de altura + SDF. El enfoque práctico para crear terrenos en el navegador: los mapas de altura cubren todo el mundo (son baratos y compactos), mientras que los volúmenes SDF solo existen en los chunks que necesitan cuevas, voladizos o elementos tallados por el creador (entre el 5 y el 10 % de los chunks). Cerca de la cámara, la libertad volumétrica permite tallar y crear cuevas. A lo lejos, los mapas de altura proporcionan un terreno plano eficiente. Consulta la representación híbrida del terreno.

Parte 7 de 12.
Anterior: Parte 6 - Los clipmaps cambiaron el rumbo
Siguiente: Parte 8 - Integración sin perder nuestra base de referencia
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

¿Es tu primera vez aquí? Consulta la guía de la serie. Explica qué es un spike y contiene enlaces a todas las partes.

La integración es el momento en que los proyectos se vuelven caóticos. Tienes piezas que funcionan de forma aislada. Las conectas y, de repente, parece que cada error podría estar en cualquier parte.

Los spikes 13 y 14 fueron nuestra respuesta a esa trampa. El spike 13 estableció una base limpia de Three.js con WebGPU. Solo un renderizador, una escena, una cámara y una malla sencilla. Sin terreno, sin cómputo y sin efectos. Confirmamos que el backend WebGPU de Three.js se inicializaba correctamente, que el bucle de renderizado era estable y que los materiales de nodos de TSL (Three.js Shading Language) funcionaban como esperábamos. Solo después de superar ese punto de control empezamos a añadir capas.

Abrir el spike 13 en una pestaña nueva ↗ · Ver el código fuente

El spike 14 consistió en un refuerzo incremental. Añadimos una capacidad cada vez: primero los controles de cámara, después la iluminación, luego la malla generada por cómputo mediante el pipeline de marching cubes y, por último, las conexiones de búfer necesarias para enviar la salida de la GPU directamente a los atributos de geometría de Three.js. Después de cada incorporación, verificamos que la capa anterior siguiera comportándose correctamente.

Abrir el spike 14 en una pestaña nueva ↗ · Ver el código fuente

Eso suena lento. Lo fue durante exactamente un día, y poco después nos ahorró varios días cuando la lógica de costuras y el cambio de políticas se complicaron.

La categoría concreta de error que justificó esta disciplina fueron los artefactos finísimos. Eran fragmentos delgados que parecían indicar una geometría dañada, pero que en realidad se debían a datos obsoletos. El shader de cómputo escribía N vértices en un búfer, pero la llamada de dibujado seguía configurada para renderizar N+M vértices del fotograma anterior. Esos vértices adicionales contenían basura de la ejecución anterior. El resultado visual eran triángulos parpadeantes y finos como cuchillas que aparecían y desaparecían de forma impredecible.

Ese tipo de error no se vence con intuición. Se vence mediante cambios controlados que permiten saber exactamente qué ha cambiado entre el último estado funcional y el estado actual con errores.

La integración de WebGPU también nos enseñó mucho sobre el ciclo de vida de los búferes. Los búferes de GPU en WebGPU son inmutables una vez asignados para un uso específico. Si necesitas cambiar el tamaño de un búfer de vértices porque ha crecido la salida de marching cubes, tienes que crear uno nuevo y actualizar el enlace. No existe realloc. Gestionar correctamente ese ciclo de vida y destruir los búferes antiguos sin entrar en conflicto con el trabajo de la GPU aún en curso requirió una gestión explícita de fences que no existe en WebGL.

En la parte 9 pasamos al trabajo con costuras de Transvoxel. Ese capítulo comienza deliberadamente con un armazón básico. Para entonces ya habíamos interiorizado por completo la lección: precipitar la integración genera misterios, mientras que una preparación controlada genera problemas que se pueden depurar.

Tecnología mencionada en este capítulo

WebGPU. El sucesor de WebGL, que ofrece acceso de bajo nivel a la GPU desde el navegador mediante shaders de cómputo y renderizado indirecto. Las dos funciones esenciales de WebGPU para los mundos abiertos son las siguientes: los shaders de cómputo permiten generar terreno, colocar vegetación y realizar el descarte desde la GPU; el renderizado indirecto permite que la GPU decida qué dibujar a partir de la salida del cómputo, eliminando los cuellos de botella de la CPU en escenas densas. Está disponible en Chrome, Edge y Firefox para equipos de escritorio. Consulta WebGPU como clave para mejorar el rendimiento.

Three.js Shading Language (TSL). El sistema de shaders basado en nodos de Three.js, que sustituye el código GLSL/WGSL sin procesar por expresiones de JavaScript componibles. Los nodos de TSL como texture(), positionWorld, smoothstep() y fog() crean en tiempo de ejecución un grafo de shaders que se compila para el backend correspondiente (GLSL de WebGL o WGSL de WebGPU). TSL permite escribir una vez la lógica de los materiales y utilizarla con ambos renderizadores. El grafo de nodos se evalúa en cada fotograma, por lo que los uniformes dinámicos y las bifurcaciones condicionales funcionan de manera natural.

Ciclo de vida de los búferes de GPU en WebGPU. Los búferes de WebGPU se crean con indicadores de uso específicos (VERTEX, STORAGE, COPY_DST, etc.) y no se puede cambiar su tamaño después de crearlos. Si una ejecución de marching cubes produce más vértices de los que caben en el búfer, debes crear uno nuevo, actualizar el enlace y destruir el anterior. Destruir un búfer al que todavía hace referencia un comando de GPU en curso provoca errores. La gestión explícita de fences (mediante device.queue.onSubmittedWorkDone()) garantiza que el búfer antiguo no se destruya hasta que la GPU haya terminado de utilizarlo. Esta disciplina del ciclo de vida no existe en WebGL, donde el controlador gestiona la memoria de forma implícita.

Refuerzo incremental. Una disciplina de integración que consiste en establecer una base de referencia cuyo correcto funcionamiento esté confirmado, añadir una capacidad cada vez y verificar que la capa anterior siga funcionando después de cada incorporación. Este enfoque es más lento durante un día, pero ahorra días en la depuración posterior, porque cada regresión puede rastrearse hasta un cambio concreto y controlado. El patrón de establecer primero una base y después avanzar de forma incremental es habitual en el desarrollo de mundos abiertos AAA, donde los sistemas se integran en un orden específico para gestionar el riesgo.

Parte 8 de 12.
Anterior: Parte 7: Marching cubes y las primeras cuevas reales
Siguiente: Parte 9: Transvoxel comenzó con un armazón básico
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Las uniones son donde la confianza va a morir.

Todo puede parecer estable hasta que se encuentran dos resoluciones. Un chunk con LOD 0 está junto a otro con LOD 1. Sus mallas se generan de forma independiente. En el límite compartido, las posiciones de los vértices no coinciden porque el chunk de menor resolución tiene la mitad de densidad de cuadrícula. El resultado son grietas visibles, uniones en T y bordes que parpadean.

El algoritmo Transvoxel resuelve este problema generando celdas de transición especiales a lo largo de la cara limítrofe entre dos chunks con resoluciones diferentes. Estas celdas toman muestras simultáneamente de las cuadrículas de alta y baja resolución y producen triángulos que cosen ambas superficies. El algoritmo utiliza sus propias tablas de consulta, independientes de las tablas normales de marching cubes, con 512 casos de celdas de transición.

A esas alturas ya acumulábamos suficientes cicatrices de integración como para saber que no debíamos apresurar la implementación.

El Spike 15 tenía una sola misión: construir un banco de pruebas de uniones en el que pudiéramos confiar antes de tocar el algoritmo completo. Preparamos un entorno controlado donde dos chunks con datos SDF conocidos estaban uno junto al otro a distintas resoluciones, con controles de visualización para activar o desactivar de forma independiente la malla principal, la malla de unión, la vista alámbrica y las normales.

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

Una vez estabilizado el banco de pruebas, el Spike 16 validó la generación de celdas de transición basada en tablas sobre una sola cara. Elegimos una cara alineada con un eje (el límite +X), implementamos la evaluación de celdas de transición únicamente para esa cara y comparamos el resultado con los datos de referencia del artículo de Transvoxel.

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

Probamos una cara cada vez de forma deliberada, porque el cableado de las tablas de transición presenta muchos modos de fallo independientes. El cálculo del índice de caso depende de tomar muestras de los vértices correctos de ambas cuadrículas. La indexación de vértices dentro de una celda de transición utiliza un esquema de numeración distinto al de las celdas normales de marching cubes. El orden de orientación debe ser coherente con el de la malla principal o el descarte de caras posteriores se comerá los triángulos de unión. Si pruebas las seis caras a la vez, todos los síntomas parecen aleatorios. Si pruebas exhaustivamente una sola cara, obtienes fallos significativos que puedes depurar.

Otro logro sutil de esta fase fue la inversión en herramientas. Desde el principio creamos controles de visibilidad, renderizado exclusivo de las uniones e indicadores LOD codificados por colores. En aquel momento, esos controles parecían trabajo adicional. Más adelante, cuando los casos extremos se complicaron, amortizaron con creces la inversión porque podíamos aislar exactamente qué celdas de unión se estaban comportando mal.

Al final de este capítulo no habíamos «terminado con las uniones». Estábamos en una posición desde la que podíamos razonar sobre sus errores en lugar de temerlos.

En la parte 10 comienza la verdadera montaña rusa. Esquinas con niveles LOD mezclados, inversiones de orientación, fantasmas por sobredibujado parcial y esos momentos en los que estás seguro de que el algoritmo es incorrecto, hasta que descubres que el error está en un rango de dibujo que lee más allá del número de vértices activos.

Tecnología mencionada en este capítulo

El algoritmo Transvoxel. Diseñado por Eric Lengyel (transvoxel.org), Transvoxel resuelve el problema más difícil del LOD en terrenos volumétricos: las uniones entre chunks con distintas resoluciones. Cuando un chunk de alta resolución está junto a otro de baja resolución, las mallas de marching cubes no se alinean en el límite y producen grietas visibles. Transvoxel inserta celdas de transición especiales a lo largo de las caras limítrofes que salvan la diferencia de resolución mediante triángulos adicionales que coinciden con ambos lados. El algoritmo utiliza sus propias tablas de consulta, independientes de las de marching cubes normal, con 512 casos de celdas de transición reducidos a 73 clases de equivalencia. Está libre de patentes y se ha utilizado en juegos publicados (Space Engineers, Astroneer). Consulta nuestra guía sobre paisajes dedicada a Transvoxel.

Celdas de transición. Celdas especiales generadas en la cara situada entre dos niveles LOD. A diferencia de las celdas normales de marching cubes, que toman muestras de 8 esquinas de una sola cuadrícula, las celdas de transición toman muestras simultáneamente de las cuadrículas de alta y baja resolución. La cara de alta resolución tiene $3\times 3=9$ puntos de muestra, mientras que la de baja resolución tiene $2\times 2=4$. Esas 9 muestras son las que dan al algoritmo sus $2^9=512$ casos brutos, que se reducen a 73 triangulaciones distintas al eliminar rotaciones y reflexiones equivalentes. La clasificación y triangulación de las celdas utiliza tablas específicas que producen triángulos conectando vértices de ambas resoluciones. El esquema de numeración de vértices es distinto al de las celdas normales de MC, lo que constituye una fuente habitual de errores de implementación.

Uniones de transición LOD. El límite entre dos resoluciones de malla donde la falta de correspondencia topológica causa artefactos visuales. Sin cosido, un chunk con LOD 0 (cuadrícula de 1 m) junto a otro con LOD 1 (cuadrícula de 2 m) produce uniones en T: la malla fina tiene vértices a lo largo del límite que la malla gruesa no comparte, lo que provoca grietas por las que se filtra la luz. Transvoxel, el geomorphing y la geometría de faldón son tres enfoques para corregir estas uniones. Para terrenos volumétricos, Transvoxel es la solución estándar porque el geomorphing solo funciona con mapas de alturas. Consulta LOD para terrenos volumétricos.

Parte 9 de 12.
Anterior: Parte 8 - Integración sin perder nuestra base de referencia
Siguiente: Parte 10 - Caos en las uniones y el combate final contra las esquinas
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Si las partes anteriores parecían metódicas, este capítulo se sintió como un combate.

Los spikes del 17 al 22 fueron nuestra era de los casos límite. Marching cubes con LOD dual, costuras en los límites entre mapas de alturas y MC, chunks de esquina con resoluciones mixtas donde confluyen tres o cuatro niveles de LOD, generación de costuras en la GPU y comportamiento del modo de respaldo. Cada spike abordó una situación de fallo específica que habíamos encontrado o previsto.

El spike 17 probó marching cubes duales con dos niveles de LOD activos simultáneamente. El reto era que los chunks vecinos de un mismo chunk podían tener resoluciones distintas en caras diferentes. La lógica de celdas de transición del spike 16 funcionaba para una cara cada vez, pero cuando un chunk necesitaba celdas de transición en varias caras, la gestión del búfer de vértices se complicaba. Había que generar y añadir las celdas de transición de cada cara sin sobrescribir las demás.

Abrir el spike 19 en una pestaña nueva ↗ · Ver código fuente

El primer villano recurrente fue el orden de orientación de los vértices. Varias veces creímos tener problemas de topología y después descubrimos que eran problemas de orientación. El descarte de caras posteriores se estaba comiendo triángulos válidos de las costuras porque su orientación estaba invertida respecto a la malla principal. La misma causa raíz producía síntomas visuales distintos según el ángulo de la cámara. La solución fue imponer una convención de orientación coherente en el código que emite las celdas de transición y verificarla con un control para activar materiales de doble cara.

El segundo villano fue la falsa confianza que producía una corrección parcial. Una costura podía parecer perfecta desde un ángulo de cámara y romperse cuando los chunks de mayor y menor resolución intercambiaban sus roles de LOD. La celda de transición es asimétrica. Muestrea de forma distinta el lado de alta resolución y el de baja resolución. Si la lógica que determina «qué lado es de alta resolución» está invertida en una configuración, solo se ve el error cuando la cámara se mueve a una posición concreta.

Después llegó una de nuestras recuperaciones favoritas. Estábamos persiguiendo un artefacto de corte en las costuras de las teselas del mapa de alturas y culpábamos a la lógica de transición. Perdimos dos días con ello. El verdadero culpable era el sobredibujado obsoleto. La geometría de mayor resolución de un fotograma anterior seguía en la cola del búfer después de que el chunk pasara a un LOD inferior. El rango de dibujado seguía configurado con el recuento de vértices anterior, que era mayor. En cuanto limitamos el rango de dibujado al recuento de vértices activos indicado por el contador atómico del shader de cómputo, el «misterioso problema de las costuras» desapareció.

Fue un excelente recordatorio de que los errores de renderizado suelen hacerse pasar por errores de generación de mallas. La geometría había sido correcta todo el tiempo. La llamada de dibujado simplemente estaba leyendo más allá del final de los datos válidos.

Para el spike 22 ya estábamos probando un respaldo híbrido en el que los chunks podían pasar de marching cubes al modo de mapa de alturas bajo determinadas condiciones, como cuando el chunk no contenía ediciones volumétricas y estaba lo bastante lejos de la cámara. Esto nos ofreció una vía más práctica que una política de todo o nada. Los chunks editados del campo cercano usan MC para conservar la libertad volumétrica. Los chunks no editados del campo lejano usan mapas de alturas para mejorar la eficiencia.

Abrir el spike 22 en una pestaña nueva ↗ · Ver código fuente

Este capítulo fue la caída pronunciada de la montaña rusa. Frustrante y productivo al mismo tiempo. Muchas de las correcciones individuales fueron pequeñas, a veces una sola línea que cambiaba un operador de comparación o un desplazamiento. Pero el conocimiento que aportaron sobre la interacción entre las transiciones de LOD, la gestión de búferes y los rangos de dibujado no fue pequeño en absoluto.

En la parte 11 abordamos la capa de estabilización que llegó después del caos: modos de chunk basados en políticas y la transición de corregir errores de forma reactiva a definir reglas explícitas para el sistema.

Tecnología mencionada en este capítulo

Marching cubes con LOD dual. Ejecución de marching cubes con dos niveles de resolución simultáneos, con celdas de transición que unen el límite. El reto es que los chunks vecinos de un mismo chunk pueden tener resoluciones distintas en caras diferentes, lo que requiere generar celdas de transición independientes para cada cara. Las celdas de transición de cada cara se añaden al búfer de vértices sin sobrescribir las demás. Los contadores atómicos registran el recuento total de vértices activos de todas las caras.

Orden de orientación de los vértices. El orden de los vértices dentro de cada triángulo determina qué lado es la cara «frontal». Se necesita una orientación coherente —normalmente en sentido antihorario al observarla desde fuera— para el descarte de caras posteriores. Cuando las celdas de transición emiten triángulos, su orientación debe coincidir con la convención de la malla principal. Invertirla hace que el descarte de caras posteriores elimine triángulos válidos de las costuras, lo que parece producir superficies ausentes desde determinados ángulos de cámara. Una técnica habitual de depuración consiste en activar side: THREE.DoubleSide en el material para confirmar si los artefactos se deben a problemas de orientación o a huecos topológicos reales.

Respaldo de mapa de alturas a MC. Un modo de chunk híbrido en el que los chunks lejanos o no editados usan terreno basado en mapas de alturas —barato, con una superficie sin volumen—, mientras que los chunks cercanos o editados usan marching cubes —volumétrico y compatible con cuevas—. La decisión de usar el respaldo depende de la distancia a la cámara y de si el chunk contiene ediciones SDF. La costura entre un chunk de mapa de alturas y uno de MC requiere su propia geometría de transición, similar a Transvoxel, pero conectando dos representaciones distintas en lugar de dos niveles de LOD. Consulta mapa de alturas híbrido + capas volumétricas.

Rango de dibujado y contadores atómicos. En la generación de mallas dirigida por la GPU, el shader de cómputo escribe vértices en un búfer e incrementa un contador atómico para registrar cuántos vértices se han emitido. La llamada de dibujado debe usar este contador como recuento de vértices, no la capacidad del búfer. Si el rango de dibujado no se limita al recuento activo, los vértices obsoletos de fotogramas anteriores —que aún permanecen en la cola del búfer— producen geometría fantasma: finas esquirlas y triángulos parpadeantes que parecen errores de topología, pero en realidad son artefactos de renderizado provocados por leer más allá de los datos válidos.

Parte 10 de 12.
Anterior: Parte 9 - Transvoxel comenzó con una estructura básica
Siguiente: Parte 11 - Modo basado en políticas, no un modo codificado de forma rígida
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, director de tecnología y cofundador de Cinevva

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

Después del capítulo sobre el caos de las uniones, teníamos que dejar de reaccionar y empezar a establecer reglas.

El Spike 23 sustituyó el comportamiento improvisado por reglas de política explícitas. En lugar de que los chunks hicieran lo que indicara su estado local, ahora un sistema central de políticas tomaba las decisiones. ¿Qué nivel de LOD recibe este chunk? ¿Se renderiza como mapa de alturas o mediante marching cubes? ¿Necesita celdas de transición y, de ser así, en qué caras? Las respuestas procedían de una función de políticas que evaluaba la distancia a la cámara, el historial de ediciones y los estados de resolución de los chunks vecinos.

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

La asignación de LOD basada en la distancia utilizaba anillos concéntricos alrededor de la cámara, de forma similar al concepto de clipmap, pero aplicado a la cuadrícula de chunks. Los chunks del anillo 0 reciben MC a resolución completa. Los del anillo 1 reciben MC a media resolución. Los del anillo 2 y posteriores usan el modo de mapa de alturas. La restricción de adyacencia era fundamental: para dos chunks vecinos cualesquiera exigimos que $|L_i-L_j|\le 1$. La relación de resolución a través de una cara es $2^{|L_i-L_j|}$, y las tablas de transición de Transvoxel solo están definidas para el caso 2:1 ($|L_i-L_j|=1$). Un salto de 2 niveles requeriría una transición 4:1 que las tablas no pueden representar, por lo que la política obliga al chunk con menor nivel de detalle a aumentar su resolución hasta que se cumpla la restricción.

La lógica de cambio entre HM y MC comprobaba el mapa de bits de ediciones de cada chunk. Si un chunk tenía alguna edición volumétrica —cuevas, túneles o esculpidos del terreno—, permanecía en modo MC independientemente de la distancia. Los chunks sin editar podían pasar al modo de mapa de alturas cuando se alejaban lo suficiente. Este enfoque híbrido nos proporcionaba libertad volumétrica donde importaba y eficiencia donde no.

Desde fuera, este spike parecía más pequeño que algunos de los anteriores. En la práctica, supuso una mejora importante en la calidad de vida durante el desarrollo.

Cuando el sistema puede explicar por qué un chunk ha cambiado de modo, se pierde menos tiempo haciendo conjeturas. Añadimos superposiciones codificadas por colores: verde para los chunks de mapa de alturas, azul para los chunks MC y naranja para las caras con transiciones activas. Cuando la visibilidad de las uniones dispone de controles de renderizado específicos, disminuye la ambigüedad de la depuración visual. Cuando los rangos de dibujo están vinculados explícitamente a los recuentos de vértices activos del sistema de políticas, los fantasmas de geometría obsoleta dejan de hacerte perder toda la tarde.

También rediseñamos el comportamiento de la cámara en este spike. Los spikes anteriores tenían controles de órbita sencillos, adecuados para capturas de pantalla pero inútiles para reproducir errores. El Spike 23 añadió una cámara de vuelo con WASD, velocidad configurable, opción para bloquear la altitud y lectura de la posición. Parece algo menor. Pero marcaba la diferencia entre «vi un error en algún lugar cerca de esa cresta» y «el error aparece en la posición (142, 12, -67), mirando hacia el noroeste».

La idea clave de este capítulo es que las políticas no redujeron la complejidad, sino que la organizaron. Seguía existiendo el mismo número de casos límite. Pero ahora cada caso límite tenía un nombre, una condición de activación y un lugar en el código donde se podía establecer un punto de interrupción. Es otro tipo de victoria, y es lo que determina si un sistema puede seguir evolucionando o si se derrumba bajo su propio peso.

Al terminar el Spike 23, teníamos una capa de comportamiento para el campo cercano lo bastante predecible como para conectarla a una estrategia de anillos de clipmap para el campo lejano sin temer constantemente errores derivados de su interacción.

En la parte 12 abordamos el Spike 24, donde las transiciones entre anillos, la niebla del skybox y la integración de shaders específica de cada versión de Three.js cierran este capítulo del proyecto.

Tecnologías mencionadas en este capítulo

Política de LOD basada en la distancia. Una función central que asigna a cada chunk un nivel de LOD y un modo de renderizado según su distancia a la cámara, el historial de ediciones y los estados de sus vecinos. Los anillos concéntricos de distancia determinan el LOD base: anillo 0 = MC a resolución completa, anillo 1 = MC a media resolución, anillo 2 o superior = modo de mapa de alturas. La función de políticas se ejecuta en cada fotograma a medida que se mueve la cámara y activa las transiciones de los chunks. Esto sustituye las decisiones improvisadas de cada chunk por un sistema de reglas predecible y fácil de depurar. Consulta la selección de LOD controlada por la GPU para ver el equivalente con shaders de cómputo.

Restricciones de adyacencia. El algoritmo Transvoxel solo admite relaciones de resolución 2:1. Si dos chunks vecinos difieren en más de un nivel de LOD —por ejemplo, LOD 0 junto a LOD 2—, las tablas de transición no pueden producir una geometría de unión válida. El sistema de políticas lo impide aumentando la resolución del chunk con menor nivel de detalle cuando la diferencia de LOD supera 1. Esta propagación de restricciones puede producirse en cascada: aumentar la resolución de un chunk puede obligar a hacer lo mismo con sus vecinos. La implementación consiste en una sencilla pasada iterativa que converge en 2 o 3 iteraciones para las configuraciones de cuadrícula habituales.

Mapa de bits de ediciones para seleccionar el modo. Cada chunk mantiene un mapa de bits que registra si contiene ediciones SDF volumétricas —cuevas, túneles o esculpidos—. Los chunks con alguna edición permanecen en modo marching cubes independientemente de la distancia, lo que conserva las modificaciones del creador. Los chunks sin editar pasan al modo de mapa de alturas cuando están lo bastante lejos de la cámara, lo que ahorra recursos de cómputo y memoria. El mapa de bits es un único indicador por chunk, pero puede ampliarse para registrar la densidad de las ediciones y tomar decisiones de modo más detalladas.

Superposiciones de visualización para depuración. Renderizado de chunks codificado por colores, donde verde = modo de mapa de alturas, azul = modo MC y naranja = caras con transiciones activas. Superposiciones por chunk con números de nivel de LOD, etiquetas de modo y controles para activar la visualización de la malla alámbrica. Son herramientas de desarrollo, no funcionalidades incluidas en el producto final, pero compensan su coste una y otra vez al depurar transiciones de LOD y artefactos en las uniones. Combinadas con una cámara de vuelo controlada mediante WASD que muestra la posición exacta en el mundo, convierten «vi un error en algún sitio» en «el error aparece en (142, 12, -67) con esta configuración de LOD».

Parte 11 de 12.
Anterior: Parte 10 - El caos de las uniones y el jefe final de las esquinas
Siguiente: Parte 12 - Anillos, niebla del cielo y lo que volveríamos a hacer
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

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

Se suponía que el prototipo 24 consistiría en «añadir anillos de clipmap al terreno». Acabó convirtiéndose en un gran final que abordó a la vez el renderizado, los shaders, la infraestructura de módulos y la integración visual.

La tarea principal del terreno era generar anillos concéntricos de clipmap en el shader de vértices. Cada anillo es una malla de cuadrícula plana centrada en la cámara, cuyos vértices se desplazan según las muestras del mapa de alturas. El anillo interior utiliza la resolución completa. Cada anillo posterior duplica el espaciado entre vértices y cubre un área mayor. La parte complicada es el límite entre anillos: cuando un anillo de alta resolución se encuentra con otro de baja resolución, los vértices del borde de la malla más detallada deben ajustarse al punto medio del borde de la malla más gruesa. Implementamos un morphing de bordes 2:1 detectando los vértices del límite —aquellos cuya coordenada de cuadrícula es impar a lo largo del borde del anillo— y ajustando su altura al punto medio de sus dos vecinos pares, $h=\frac{1}{2}(h_{\text{left}}+h_{\text{right}})$. Ese es exactamente el punto en el que se situaría el único borde del anillo grueso, de modo que los bordes fino y grueso describen la misma línea. Esto produce uniones estancas sin geometría de transición.

Abrir el prototipo 24 en una pestaña nueva ↗ · Ver el código fuente

Después llegó la integración de la niebla y el cielo. Queríamos que el terreno lejano se fundiera con el color real del cielo, no con una constante plana. Eso implicaba que el shader de niebla debía saber qué color tendría el cielo en la dirección de cada fragmento. Cargamos una textura HDR equirectangular para el skybox y la muestreamos en el shader de fragmentos mediante la dirección de visión desde la cámara hasta el fragmento, convertida a coordenadas UV equirectangulares a través del nodo equirectUV de TSL. El factor de niebla se basaba en la distancia y utilizaba positionView.z.negate() para obtener la profundidad en el espacio de la cámara, interpolada con smoothstep entre una distancia cercana y otra lejana.

El cableado de los módulos resultó ser más molesto que cualquier aspecto de la geometría. Actualizamos a Three.js 0.183.1, que había reorganizado las salidas de compilación. La importación three/tsl debía resolverse como three.tsl.js, y TSL importaba internamente three/webgpu como un especificador simple. Ambas correspondencias debían indicarse de forma explícita en el mapa de importaciones del HTML. Si faltaba cualquiera de ellas, aparecían errores crípticos como «does not provide an export» o «failed to resolve module specifier», sin ninguna indicación sobre qué correspondencia era incorrecta. Una vez añadidas las dos al mapa de importaciones, el grafo de shaders se cargó correctamente.

También tuvimos un problema de orientación del skybox: la textura se renderizaba al revés. La solución fue establecer flipY = true en la textura equirectangular, que es el valor predeterminado de Three.js para las texturas cargadas, pero que en nuestro código inicial estaba establecido como false.

La implementación original de la niebla muestreaba el cielo en una dirección casi constante, lo que producía una fina franja del color del horizonte en lugar de un gradiente natural. La solución fue calcular por píxel la dirección real en el espacio del mundo desde la cámara hasta el fragmento mediante positionWorld.sub(cameraPosition).normalize() y pasarla a equirectUV para consultar el color de la niebla. Así, los fragmentos del terreno se funden con el color del cielo que realmente tienen detrás, lo que se ve correctamente desde cualquier ángulo de cámara.

Por debajo de todas las correcciones individuales, el resultado principal se mantuvo. Ahora tenemos un sistema de terreno que combina edición volumétrica en el campo cercano —marching cubes con uniones Transvoxel—, fragmentos de mapas de alturas en el campo medio y anillos de clipmap en el campo lejano, todo ello gobernado por una capa de políticas que decide el modo, el LOD y el comportamiento de las transiciones.

Si tuviera que nombrar los patrones que repetiría en el próximo proyecto, serían estos:

Empezar con prototipos de riesgo antes de trabajar en funcionalidades. El prototipo 1 resolvió la pregunta «¿podemos renderizar siquiera con suficiente rapidez?» antes de que invirtiéramos en flujos de contenido.

Congelar líneas base que sepamos que funcionan antes de dar grandes saltos de integración. Los prototipos 13 y 14 nos ahorraron días de búsqueda por bisección de regresiones.

Imponer políticas y observabilidad antes de embarcarse en maratones de optimización. El prototipo 23 convirtió errores misteriosos en condiciones con nombre y reglas de activación.

Probar en movimiento, no mediante capturas de pantalla. Los saltos de los clipmaps, el parpadeo de las uniones y los tirones del streaming se ocultan en los fotogramas estáticos.

Medir el coste en tiempo de fotograma de cada funcionalidad, no los FPS medios. Los promedios ocultan los picos que los usuarios perciben de verdad.

Y publicar las partes caóticas. Los caminos equivocados, la búsqueda de fantasmas en búferes obsoletos, los dos días culpando a la lógica de transición cuando el rango de dibujo era incorrecto. Esas son las partes de las que la gente realmente puede aprender.

Comprobación con la realidad externa: los diarios de desarrollo de Vuntra City

Después de terminar esta serie, revisamos los diarios de desarrollo de @VuntraCity como comprobación de una implementación externa frente a nuestras propias suposiciones sobre los mundos abiertos. Es un proyecto nativo de UE5, no una plataforma para navegador, pero los patrones de sus sistemas se corresponden lo bastante bien como para que la comparación resulte útil.

La primera señal es que la velocidad de desplazamiento debe tratarse como un control del streaming, no solo como una cuestión de jugabilidad. En Vuntra City, el transporte de alta velocidad se encauza de forma intencionada por encima de la mayoría de los interiores, y el alcance del detalle se adapta a la velocidad de movimiento para evitar la creación y destrucción constante de elementos y los bloqueos (sistema de transporte, técnicas de rendimiento). Esto coincide con la dirección de nuestra capa de políticas: el modo de movimiento debe influir directamente en el radio de los fragmentos, la activación de interiores y el trabajo permitido por fotograma.

La segunda señal es la arquitectura. Sus mapas y su sistema de direcciones exigieron separar la topología del mundo de los objetos renderizados para poder ejecutar consultas globales sobre regiones no cargadas (mapas y direcciones). Es la misma separación que necesitamos en el navegador para la búsqueda en el mundo, el trazado de rutas de misiones, los análisis de moderación y la indexación de puntos de interés sin obligarnos a usar rutas de datos ligadas al renderizado.

La tercera señal es la división de la simulación por niveles. Su diseño para un millón de PNJ mantiene barato y global el estado aproximado de sus horarios, y solo destina el costoso presupuesto de comportamiento a los PNJ cercanos al jugador (resumen del millón de PNJ, análisis detallado del sistema). Esto refuerza nuestro propio modelo de simulación centrado en el área de interés, donde la fidelidad en el campo cercano y el determinismo en el campo lejano son aspectos independientes con presupuestos distintos.

Y la cuarta señal es la calidad del diseño, no la escala bruta. Sus mejores momentos de exploración surgen de distribuciones ponderadas, valores atípicos poco frecuentes y pistas diegéticas de navegación, en lugar de superposiciones constantes de la interfaz (notas sobre entornos procedurales, bucle sin minimapa). Para nosotros, esto recuerda que los sistemas técnicos deben ajustarse para producir variaciones que inviten al descubrimiento, no solo para maximizar el rendimiento.

Tecnologías mencionadas en este capítulo

Geometría de anillos de clipmap. Cada anillo es una malla de cuadrícula plana centrada en la cámara, cuyos vértices se desplazan según las muestras del mapa de alturas. El anillo interior utiliza la resolución completa. Cada anillo posterior duplica el espaciado entre vértices y cubre un área mayor. La parte complicada es el límite: cuando un anillo de alta resolución se encuentra con otro de baja resolución, los vértices del borde de la malla más detallada se ajustan al punto medio del borde de la malla más gruesa. La técnica tiene su origen en el artículo de Losasso y Hoppe para SIGGRAPH 2004 (PDF) y se explica con detalle en GPU Gems 2, capítulo 2. Consulta nuestra guía de paisajes sobre clipmaps geométricos.

Morphing de bordes 2:1. En el límite entre dos anillos de clipmap, el anillo más detallado tiene vértices en posiciones que el anillo más grueso no comparte. Se detectan los vértices del límite cuya coordenada de cuadrícula es impar a lo largo del borde del anillo y se interpola su altura entre los dos vértices pares vecinos. Esto produce uniones estancas sin necesidad de geometría de transición específica. La interpolación se ejecuta en el shader de vértices: morphedHeight = mix(heightLeft, heightRight, 0.5) para los vértices del límite, utilizando el mismo sistema de geomorphing descrito en nuestra guía.

Mapeo equirectangular del skybox. Una única imagen 2D que representa la esfera completa de direcciones del cielo mediante una proyección de longitud y latitud. El eje horizontal abarca de 0 a 360 grados y el vertical, de 0 a 180 grados. Una dirección de visión normalizada $\hat{d}=(d_x,d_y,d_z)$ se convierte en coordenadas UV a partir de su longitud y latitud:

En Three.js, establecer texture.mapping = EquirectangularReflectionMapping con SRGBColorSpace permite utilizarla como fondo de la escena. En TSL, equirectUV(direction) aplica esa misma conversión y transforma una dirección de visión 3D en las coordenadas UV 2D necesarias para muestrear la textura.

Color de niebla por fragmento obtenido del cielo. La niebla estándar mezcla los fragmentos con un único color constante. En una escena con un skybox detallado, esto resulta incorrecto porque el color del cielo varía según la dirección. La solución consiste en calcular por píxel la dirección en el espacio del mundo desde la cámara hasta el fragmento (positionWorld.sub(cameraPosition).normalize()) y muestrear el skybox en esa dirección para obtener el color de la niebla. Cada fragmento se desvanece hacia el color del cielo que realmente tiene detrás, lo que produce una mezcla correcta desde cualquier ángulo de cámara. El factor de niebla utiliza smoothstep(nearDist, farDist, viewDepth) con positionView.z.negate() para la profundidad en el espacio de la cámara.

Mapas de importaciones para módulos ES. Un mecanismo nativo del navegador (<script type="importmap">) que asigna especificadores simples de módulos —como three/tsl— a URL reales. Cuando Three.js 0.183.1 reorganizó sus salidas de compilación, three/tsl tuvo que resolverse como three.tsl.js, y TSL importaba internamente three/webgpu como un especificador simple. Ambas correspondencias debían indicarse de forma explícita en el mapa de importaciones; de lo contrario, el navegador producía errores como «does not provide an export» o «failed to resolve module specifier».

Lecturas adicionales

Para profundizar en las tecnologías utilizadas a lo largo de esta serie, consulta nuestras guías complementarias:

• Generación de paisajes con LOD dinámico y streaming para mundos abiertos en el navegador abarca mapas de alturas, SDF, marching cubes, Transvoxel, clipmaps geométricos, geomorphing, arquitectura de streaming, materiales de terreno y renderizado de vegetación.
• Tecnología 3D de mundos abiertos en el navegador para mundos multijugador creados por usuarios abarca plataformas de renderizado, WebGPU, físicas, redes, arquitectura multijugador y lecciones de Skyrim, The Witcher 3, Breath of the Wild y GTA V.

Gracias por acompañarnos en este recorrido de doce partes.

Parte 1: Empezamos intentando romperlo
Parte 2: Físicas en workers y el temor al retardo de entrada
Parte 3: Los prototipos poco vistosos que nos salvaron
Parte 4: Streaming antes que terrenos sofisticados
Parte 5: Presupuestar los elementos visuales
Parte 6: Los clipmaps cambiaron el rumbo
Parte 7: Marching cubes y las primeras cuevas de verdad
Parte 8: Integración sin perder nuestra línea base
Parte 9: Transvoxel comenzó con una estructura básica
Parte 10: El caos de las uniones y la batalla final de las esquinas
Parte 11: Modo basado en políticas, no codificado de forma rígida

Parte 12 de 14.
Anterior: Parte 11 - Modo basado en políticas, no codificado de forma rígida
Siguiente: Parte 13 - Esculpido del terreno y la muerte de la función matemática
Guía de la serie: /es/blog/2026-02-25-open-world-browser-series-guide

Por Oleg Sidorkin, CTO y cofundador de Cinevva

Esta página es el centro de navegación de la serie completa.

Si has llegado desde una parte al azar, empieza aquí.

Actualización de marzo de 2026: añadimos una comprobación externa de la implementación basada en los diarios de desarrollo de Vuntra City en la Parte 12 y ampliamos la guía técnica de mundos abiertos en el navegador complementaria con los mismos hallazgos.

Actualización de abril de 2026: las partes 13 y 14 cubren el esculpido del terreno (prototipos 25-27) y la capa visual y de jugabilidad: texturizado multimaterial, vegetación instanciada y un controlador de personaje con colisiones HM+SDF (prototipos 28-30).

Actualización de mayo de 2026: la serie llegó a 29 partes. Las partes 15-29 cubren la larga fase intermedia del desarrollo, el terreno y el agua multijugador, una refactorización de la estructura del código, animaciones y distribución mediante IA, impostores y paralaje, el búfer de visibilidad que no dio resultado, nubes y descarte de meshlets, avatares procesados por lotes y voz por proximidad, persistencia del mundo y viento en la GPU, personajes universales, tres enfoques para el agua, una isla procedural, hierba y oclusión, y un controlador de personaje conectable que funciona con cualquier cuerpo (prototipos 31-60).

Actualización de junio de 2026: la Parte 30 añade una cámara consciente de las colisiones, un brazo de cámara con resorte, un contrato de colisionador conectable y una sonda de distancia con signo que impide que la vista atraviese salientes y techos de cuevas, no solo colinas.

Qué significa «prototipo» en esta serie

Un prototipo es un experimento breve y enfocado.

Cada prototipo pone a prueba una cuestión arriesgada. Mantenemos un alcance reducido, medimos lo que importa y decidimos qué hacer a continuación. Considéralo un instrumento de aprendizaje, no una funcionalidad pulida.

En este proyecto, los prototipos son principalmente páginas independientes bajo /spikes/* que puedes ejecutar en vivo.

Lee la serie en orden

1. Parte 1: Empezamos intentando romperlo
2. Parte 2: Física en un worker y el temor al retardo de entrada
3. Parte 3: Los prototipos poco vistosos que nos salvaron
4. Parte 4: Streaming antes que terrenos sofisticados
5. Parte 5: Presupuestar los elementos visuales
6. Parte 6: Los clipmaps cambiaron la historia
7. Parte 7: Marching cubes y las primeras cuevas de verdad
8. Parte 8: Integración sin perder nuestra referencia inicial
9. Parte 9: Transvoxel comenzó con una estructura base
10. Parte 10: Caos en las uniones y la batalla final de las esquinas
11. Parte 11: Modo basado en políticas, no codificado de forma rígida
12. Parte 12: Anillos, niebla del cielo y lo que volveríamos a hacer
13. Parte 13: El esculpido del terreno y la muerte de la función matemática
14. Parte 14: El mundo cobra vida
15. Parte 15: Sustituir la base y después sincronizarla
16. Parte 16: Una estructura para un mundo que no deja de crecer
17. Parte 17: Animaciones que no necesitaron retargeting y una búsqueda de recursos en vivo
18. Parte 18: Un pincel de distribución que parece controlado por IA
19. Parte 19: El impostor que tiene que sobrevivir en un bosque
20. Parte 20: Simular profundidad en un plano
21. Parte 21: Un renderizador más rápido que no era más rápido
22. Parte 22: Nubes que puedes iluminar y un sistema de descarte que hay que alimentar
23. Parte 23: Cincuenta avatares y una voz en la sala
24. Parte 24: Guardar un mundo y crear viento visible
25. Parte 25: Un esqueleto para cualquier atuendo
26. Parte 26: Tres formas de crear agua
27. Parte 27: Una isla creada con ruido y un suelo que parece real
28. Parte 28: Hierba hasta el horizonte y un terreno que se oculta a sí mismo
29. Parte 29: Un controlador para cualquier cuerpo
30. Parte 30: Una cámara que respeta las paredes

Mapa de prototipos en vivo

Empieza por estos si quieres recorrer directamente la cronología técnica.

Prototipo 1 terreno e instanciación · código fuente
Prototipo 2 física en un worker · código fuente
El prototipo 3, una prueba de carga de difusión con Durable Objects, se ejecutó como un script de servicio, no como una página independiente
El prototipo 4 probó las restricciones de calidad en móviles mediante un parámetro de consulta del prototipo 1
El prototipo 5 probó la fiabilidad del comportamiento del LLM y se ejecutó como un script, no como una página independiente
Prototipo 6 carga e intercambio de chunks · código fuente
Prototipo 7 vegetación a partir de mapas de densidad · código fuente
Prototipo 8 coste del material del terreno · código fuente
Prototipo 9 presupuesto de sombras en cascada · código fuente
Prototipo 10 clipmaps y geomorfismo · código fuente
Prototipo 11 streaming de chunks de mapas de altura · código fuente
Prototipo 12 marching cubes con WebGPU · código fuente
Prototipo 13 referencia inicial de integración con WebGPU · código fuente
Prototipo 14 robustecimiento incremental · código fuente
Prototipo 15 estructura base para uniones · código fuente
Prototipo 16 primera cara de Transvoxel · código fuente
Prototipo 17 LOD dual de MC · código fuente
Prototipo 18 unión de mapas de altura · código fuente
Prototipo 19 esquina con resoluciones mixtas · código fuente
Prototipo 20 unión de esquina en la GPU · código fuente
Prototipo 21 unión de esquina MC en la GPU · código fuente
Prototipo 22 alternativa de MC a HM · código fuente
Prototipo 23 modos de chunks basados en políticas · código fuente
Prototipo 24 anillos de clipmap y niebla del cielo · código fuente
Prototipo 25 pincel de mapas de altura sobre datos muestreados · código fuente
Prototipo 26 pincel SDF mediante cómputo en la GPU · código fuente
Prototipo 27 integración de HM + MC + pincel · código fuente
Prototipo 28 texturizado multimaterial · código fuente
Prototipo 29 vegetación y hierba mediante shaders · código fuente
Prototipo 30 física del terreno y controlador de personaje · código fuente
Prototipo 31 sincronización de terreno multijugador · código fuente
Prototipo 32 agua y natación · código fuente
Prototipo 33 refactorización de la estructura del código · código fuente
Prototipo 34 creación dentro del mundo · código fuente
Prototipo 35 animaciones de combate y retargeting · código fuente
Prototipo 36 búsqueda en vivo de recursos de Poly Haven · código fuente
Prototipo 37 distribución de objetos asistida por IA · código fuente
Prototipo 38 impostores octaédricos · código fuente
Prototipo 39 mapeado de oclusión por paralaje · código fuente
Prototipo 40 renderizador con búfer de visibilidad · código fuente
Prototipo 41 impostores en un bosque · código fuente
Prototipo 42 corrección del parpadeo de los impostores · código fuente
Prototipo 43 atmósfera y nubes volumétricas · código fuente
Prototipo 44 descarte Hi-Z de meshlets · código fuente
Prototipo 45 skinning de avatares por lotes y sincronización de red · código fuente
Prototipo 46 chat de voz por proximidad · código fuente
Prototipo 47 persistencia del mundo con autoridad del servidor · código fuente
La integración del rig de avatares del prototipo 48 se reutilizó como código compartido en prototipos posteriores (sin página independiente)
Prototipo 49 viento en la GPU aplicado a objetos y follaje · código fuente
Prototipo 50 personajes universales y accesorios equipables · código fuente
Prototipo 51 agua con reflejos en espacio de pantalla · código fuente
Prototipo 52 agua con reflejos planares · código fuente
Prototipo 53 biblioteca de agua para producción · código fuente Spike 54 generación procedural de islas · código fuente
Spike 55 sombreado del terreno y disimulación del mosaico · código fuente
Spike 56 césped de quads cruzados en la GPU · código fuente
Spike 57 descarte por oclusión del terreno · código fuente
Spike 58 controlador de personaje intercambiable · código fuente
Spike 59 controlador con un avatar real · código fuente
Spike 60 animaciones poligonales de Synty · código fuente

Por Mariana Muntean, CEO de Cinevva

Creamos un juego en el que tu serpiente es la pala y los ladrillos contraatacan. Se publicó para web, móvil y PC. Nos llevó unos tres días entre dos personas. A ratos, sin jornadas agotadoras. Y es realmente divertido de jugar.

Esa última parte es a la que merece la pena prestar atención.

La mezcla que nadie pidió

Snake trata sobre crecer y tener conciencia espacial. Arkanoid trata sobre reflejos y predicción de ángulos. Provienen de filosofías de diseño completamente distintas, y mezclarlos suena como esa clase de propuesta que se rechaza amablemente.

Pero A Breaker Belt consigue que funcione. Eres una serpiente cósmica, un arco viviente de corriente de neón, ensamblado con vértebras de metal errante y seda de cometa, que se abre paso por un campo de asteroides formado por bloques rompibles. Tu cabeza es la pala. Tu cola, que no deja de crecer, es a la vez tu mejor arma y tu amenaza más constante. Los orbes rebotan contra tu cuerpo para destruir ladrillos, pero basta un giro equivocado hacia tu propia cola para que se acabe la partida.

Es la clase de experimento extraño entre géneros que normalmente muere antes de que nadie llegue a jugarlo, porque el coste de desarrollo necesario para averiguar si una idea peculiar funciona se ha medido tradicionalmente en meses. Aquí se midió en tardes.

Lo que realmente publicamos

El alcance es lo que hace que esto resulte interesante. No es un prototipo de una game jam con rectángulos provisionales y sin sonido.

El juego cuenta con 50 oleadas. Y no son 50 variaciones del mismo muro de ladrillos. Las formaciones evolucionan desde suaves arcos introductorios hasta anillos fortificados que exigen tiros angulados a través de aberturas laterales, para después convertirse en laberintos diagonales por capas con huecos de una sola casilla que requieren un control preciso. Los ladrillos explosivos hacen saltar por los aires a sus vecinos. Los ladrillos fantasma aparecen y desaparecen. Los ladrillos regenerativos se reparan después de romperlos, lo que te obliga a priorizar objetivos en lugar de barrer la pantalla de izquierda a derecha. Los ladrillos portal teletransportan tus orbes por la arena. Los pozos gravitatorios desvían tus disparos y los convierten en himnos lentos y curvos. Los emisores láser dibujan líneas rojas en el vacío. Los ladrillos miméticos parecen inofensivos hasta que deciden dejar de serlo. Al llegar a la oleada 15, navegas por algo que se parece menos a un rompecabezas y más a un sistema vivo que está aprendiendo tus hábitos.

La música no es un bucle. Es una banda sonora reactiva que evoluciona con la partida. El sistema subyacente reproduce una línea de bajo, un sintetizador principal, un pad, un bombo, una caja y un hi-hat en mi menor a 140 BPM y, a medida que se intensifica la acción, aparecen gradualmente capas adicionales de percusión y sintetizador. Cuando todo se calma entre oleadas, los pads ambientales toman el protagonismo. La música respira contigo. Un compositor dedicado tardaría semanas en ajustar ese grado de respuesta. Aquí formó parte del propio flujo creativo.

Los efectos de sonido no son muestras sacadas de un paquete gratuito. Cada ladrillo que se rompe, cada potenciador recogido, cada rebote de un orbe y cada colisión se sintetizan en tiempo real. Los contactos con la cabeza tienen un tono diferente a los contactos con la cola. Una reverberación cálida aporta la sensación espacial. El filtrado de paso bajo mantiene el sonido satisfactorio sin volverlo estridente. Cuando encadenas un combo, el audio te lo comunica antes que la pantalla.

Y luego está la narrativa. Cada oleada comienza con un fragmento narrativo interpretado por una voz generada mediante IA. El texto tiene una personalidad auténtica. Oleada uno: «Lo llaman el Cinturón Quebrador: una cinta de escombros artificiales que rodea la vieja estrella como una advertencia». En la oleada 38: «El Cinturón deja de parecer un muro y empieza a parecer una mente. No pone a prueba tus reflejos, sino tus hábitos. Rompes el hábito. El Cinturón se da cuenta». Son 50 capítulos de mitología cósmica que hacen que te importe por qué eres una serpiente que rompe ladrillos en el espacio.

Los fondos también evolucionan. Las primeras oleadas muestran tranquilos campos de estrellas índigo con una suave lluvia de meteoros. Hacia la mitad del juego aparecen franjas de auroras y nubes de nebulosa. En las fases finales se desata una Tormenta Iónica en toda regla, con intensos trazos cian sobre un espacio casi negro. A partir de la oleada 15, entras en territorio de Horizonte de Sucesos: un vacío profundo salpicado de filamentos de nebulosa que se mueven lentamente y un tenue efecto de lente gravitacional producido por agujeros negros. El juego comunica la progresión tanto mediante la atmósfera como mediante la dificultad.

Todo esto funciona con teclado, mando o pantalla táctil. Publicado para web, móvil y PC desde una única base de código. Sin compilaciones independientes. Sin adaptaciones entre plataformas.

El equipo que no hizo falta

Esta es la parte que debería hacer reflexionar a cualquier desarrollador de videojuegos.

Un juego con esta profundidad de contenido normalmente necesitaría un diseñador de juegos, un par de programadores, un artista 2D, un diseñador de sonido, un compositor musical, un diseñador de niveles, un guionista narrativo y control de calidad. Es decir, ocho o nueve personas. Incluso a un ritmo indie moderado, hablaríamos de entre tres y seis meses de trabajo coordinado. Reuniones diarias, tareas en Jira, procesos de recursos y depuración específica para cada plataforma.

Dos personas hicimos esto durante un fin de semana largo con Cinevva Engine.

El talento necesario no cambió. Lo que cambió fue la proporción entre la intención creativa y la sobrecarga de implementación. El tiempo se dedicó a decidir qué sensaciones debía transmitir el juego, no a pelearse con las herramientas para hacerlo realidad.

Por qué importa si creas cosas

La pregunta interesante no es si las herramientas de IA pueden ayudar a crear juegos más rápido. Eso ya está respondido. La pregunta interesante es qué ocurre con las ideas que antes eran demasiado arriesgadas como para intentarlas.

«Snake, pero tú eres la pala en una arena de Arkanoid» no es algo a lo que un productor dé luz verde. Algunos desarrolladores indie han probado variaciones de esta mezcla en itch.io (BreakSnake, SnakeOut, Snake Break), pero todos son pequeños experimentos de game jam. Esta fusión de géneros nunca había recibido un verdadero tratamiento de producción con música reactiva, narración por IA, docenas de tipos de ladrillos y 50 oleadas con un diseño de niveles de dificultad creciente. En el desarrollo tradicional, ese grado de acabado aplicado a un concepto arriesgado se descarta en una reunión antes de que nadie escriba una sola línea de código.

Cuando probar algo extraño cuesta una tarde en lugar del presupuesto de un trimestre, las ideas peculiares llegan a construirse. Algunas resultan ser realmente buenas. A Breaker Belt es una de ellas.

Juégalo. O crea el tuyo.

Puedes jugar a A Breaker Belt ahora mismo en web, móvil y PC. Si te inspira a crear algo, Cinevva Engine es gratuito. Describe lo que quieres, itera sobre el resultado y publícalo cuando esté listo. La música, los efectos de sonido, el arte y los modelos 3D están integrados.

Puede que tu extraña idea para un juego esté a solo tres días de existir.

Juega a A Breaker Belt | Crea tu propio juego | Explora los juegos de la comunidad

Relacionado:

• El vibe coding es la nueva game jam — cómo las herramientas de IA acortan la distancia entre la idea y el prototipo
• Game jams y hackatones — el formato de jam que hace posibles las mezclas más extrañas
• Comparativa de motores de juegos web — motores para publicar en web, móvil y PC

Por Mariana Muntean, CEO de Cinevva

La plataforma Cinevva cuenta con un generador de música para que los creadores de juegos puedan producir bandas sonoras y efectos de sonido sin quebraderos de cabeza con las licencias. Lo que ocurrió después no entraba en nuestros planes. La gente empezó a crear música porque quería crear música. No para juegos ni proyectos. Simplemente por hacer música.

Bella Bay creó más de 100 pistas en dos semanas

No exagero. Bella Bay, una de nuestras creadoras, generó más de 100 pistas en unas dos semanas. Al escucharlas en Cinevva Radio, se percibe la evolución. Las primeras pistas son experimentos. Las últimas suenan como el trabajo de alguien que ha encontrado su estilo. Ese tipo de aceleración creativa no ocurre cuando tienes que luchar contra tus herramientas. Ocurre cuando las herramientas dejan de interponerse.

Bella Bay no es una excepción por su motivación, sino por el volumen de su producción. En toda la plataforma, la gente empezó a tratar el generador de música no como una utilidad para crear recursos de juegos, sino como un instrumento creativo. Productores que experimentaban con géneros que nunca habían probado. Personas que refinaban un sonido una y otra vez hasta dar con el resultado que buscaban. Artistas que trabajaban desde su habitación y que nunca habían tenido acceso a un conjunto completo de herramientas de producción de repente lo tenían y se entregaron por completo.

Así que creamos una radio

Había que hacerlo.

Teníamos todas esas pistas guardadas en las cuentas de la gente, sin un espacio común. No había forma de descubrir lo que creaban los demás. Ni de encontrarse por casualidad con una pista capaz de cambiarte la tarde.

Cinevva Radio ya está en directo. Ocho emisoras. 362 pistas creadas por la comunidad, y la cifra aumenta cada día. Todas y cada una de las canciones fueron creadas por alguien de la plataforma. Entras y ya hay algo sonando. No tienes que buscar. No tienes que decidir. Solo tienes que escuchar.

Soundstage es nuestra emisora más grande. 111 pistas de música cinematográfica y épica. Sinceramente, no me lo esperaba. A la gente le encanta crear música dramática, al estilo de las bandas sonoras de cine.

Discovery reúne todo lo que no encaja claramente en un género. 78 pistas. Ritmos latinos junto a afrobeats, country y otras cosas imposibles de describir. Esta emisora es una locura.

Main Stage está dedicada al pop y a las pistas vocales. 56 temas con voz y letras completas. La gente escribe canciones de amor, de rupturas, música de alabanza y baladas. Algunas son realmente pegadizas.

Voltage es rock y metal. 53 pistas. Riffs de guitarra, energía punk, grunge y hard rock. Suelo escucharla mientras trabajo.

Lo-Fi Cafe es exactamente lo que parece. 25 pistas ambientales y relajadas para estudiar, trabajar o simplemente dejarse llevar.

Electric Dreams cuenta con 22 pistas electrónicas y de sintetizador. Synthwave, techno, EDM y drum and bass.

Ivory Tower está dedicada a la música clásica y orquestal. 10 pistas. Piezas para piano, arreglos de cuerda y composiciones sinfónicas. Es pequeña, pero sigue creciendo.

The Cipher es hip-hop y rap. Por ahora tiene 7 pistas. Es la emisora más reciente y todavía está encontrando su voz.

Lo que ves mientras escuchas

Cuando abres Cinevva Radio, accedes a una emisión en directo. No la veas tanto como una aplicación de listas de reproducción, sino como una emisora de radio de verdad. Las pistas suenan de forma continua. Puedes reaccionar en tiempo real, conversar con otros oyentes y ver quién creó cada pista.

Los creadores aparecen acreditados en pantalla mientras suena su pista: su nombre, su prompt y el género. Si escuchas algo que te gusta, sabes quién lo creó. Es contenido creado por la comunidad con una capa de descubrimiento por encima. No hay algoritmos que decidan qué merece la pena. No hay guardianes que controlen el acceso. Creas una pista, esta entra en la emisora correspondiente a su género y la gente la escucha.

Esto es más que una funcionalidad

Durante décadas, producir música requería software caro, años de formación y acceso a equipos que la mayoría de la gente no podía permitirse. Lo que estamos viendo es un tipo diferente de creador: personas que piensan mediante descripciones y sentimientos, en lugar de notas y compases.

«Jazz para una noche lluviosa con un piano roto» es una dirección creativa. La persona que escribió ese prompt tomó una decisión artística. Dirigió el ambiente, la instrumentación y el registro emocional. Simplemente no toca el piano.

No creo que eso reste validez a su obra. Creo que significa que la definición de «músico» se está ampliando. Y ver a alguien como Bella Bay pasar de cero a cien pistas en dos semanas me demuestra que el impulso creativo siempre estuvo ahí. Lo que faltaban eran las herramientas.

Próximos pasos

Estamos trabajando en perfiles de la comunidad donde los productores puedan mostrar su catálogo y conseguir seguidores. La página de listas ya muestra creaciones de la comunidad realizadas con todas las herramientas, y queremos llevar esa misma energía específicamente a la música.

Pero, por ahora, la radio ya está en directo. Ve a escucharla. Y si quieres crear tus propias pistas, puedes usar gratis el generador de música. Puede que tu pista acabe sonando en antena.

Escucha Cinevva Radio | Crea música | Explora las creaciones de la comunidad

Contenido relacionado:

• Modelos generativos de IA de código abierto de vanguardia — los modelos de IA para música y audio que funcionan entre bastidores
• Web Audio API para juegos — cómo crear audio interactivo en el navegador
• El vibe coding es la nueva game jam — cómo describir una intención se convierte en la principal aportación creativa

Por Mariana Muntean, CEO de Cinevva

La IA ha convertido la lógica pura y la capacidad de cálculo en algo prácticamente indiferenciado. Las habilidades que antes venerábamos —el cálculo mental, el reconocimiento de patrones, la capacidad de abrirse paso a través de algoritmos complejos— ahora las realiza la IA. Más rápido. Mejor. Sin cansarse. ¿Seguimos necesitando esos conocimientos? Por supuesto, pero las percepciones cambian. Ahora todos debemos adaptarnos a la nueva era: una era de interacción intuitiva y resultados.

Según Jensen Huang, CEO de NVIDIA, lo que importa ahora es la capacidad de percibir una «vibra» y anticiparse antes de que aparezcan los datos. La intersección entre los conocimientos técnicos y una profunda empatía. Esa comprensión intuitiva que el silicio no puede alcanzar.

Nunca había oído a nadie con su credibilidad decir algo que validara de forma tan directa toda la trayectoria de mi vida.

El SAT y el sistema que no estaba hecho para mí

Hace unos años hice el SAT y suspendí. No me enorgullece, pero tampoco volví a intentarlo. Había algo fundamentalmente equivocado en todo aquello, y no lograba quitarme esa sensación por mucho que la gente me dijera que simplemente estudiara más y volviera a presentarme.

Visto en retrospectiva, creo que tenía razón.

El SAT está diseñado para el sistema educativo estadounidense. Parece obvio, pero sus implicaciones son profundas. Los institutos estadounidenses preparan a los estudiantes para patrones, tipos de preguntas y formas concretas de plantear problemas. Desde la escuela primaria, los alumnos crecen inmersos en ese estilo de exámenes estandarizados. Cuando llegan al SAT, ya han interiorizado su ritmo.

Los estudiantes internacionales no tenemos esa ventaja. Venimos de sistemas con filosofías educativas diferentes. Las escuelas europeas suelen priorizar la profundidad sobre la amplitud, los exámenes de desarrollo sobre los tests de opción múltiple y las defensas orales sobre las hojas de respuestas. Los sistemas asiáticos tienen sus propios exámenes estandarizados, pero miden cosas distintas de maneras diferentes. Las tradiciones educativas de Sudamérica, África y Oriente Medio tienen cada una su propia lógica.

Cuando pones a un estudiante internacional ante el SAT, no evalúas únicamente sus conocimientos. Evalúas la rapidez con la que puede adaptarse a una cultura de evaluación extranjera mientras demuestra simultáneamente su dominio de los contenidos. Evalúas tanto su fluidez cultural como su capacidad académica.

Esperaban que me preparara durante un verano y sacara una nota excelente. Que aprendiera toda una cultura de evaluación, desaprendiera mis propios instintos educativos y rindiera a un nivel que impresionara a los responsables de admisiones estadounidenses. Todo en unos pocos meses.

Decidí no hacerlo.

Cuando eres joven, eres inteligente de maneras diferentes. De maneras intuitivas. Yo estaba abriéndome mi propio camino, aunque en aquel momento no pudiera explicar exactamente por qué. Algo dentro de mí sabía que aquel sistema no era para mí.

Seguir el hilo creativo en su lugar

Estudié desarrollo y diseño de videojuegos porque me encantaba la idea de utilizar la creatividad y los efectos visuales para construir mundos virtuales en los que la gente pudiera jugar e interactuar. Me fascinaba la intersección entre el arte y la tecnología, entre la narrativa y la interactividad.

Lo que descubrí me sorprendió.

Los juegos requieren una gran profundidad técnica. Simulaciones físicas, detección de colisiones, matemáticas vectoriales, cálculos de iluminación, optimización. Lo sabía cuando empecé. Las matemáticas y la ingeniería no son obstáculos para el desarrollo de videojuegos. Son parte de lo que hace que funcionen.

El problema era la brecha entre la visión creativa y la implementación. Los motores y las herramientas que dominaban el sector habían sido diseñados por ingenieros para ingenieros. Todo funcionaba con «si» y «entonces» y con esquemas basados en nodos. ¿Querías un efecto de vórtice? Aprende a programar shaders. ¿Una ambientación lumínica concreta? Sumérgete en grafos de materiales. ¿Un movimiento de personajes que se sienta bien? Pasa horas depurando el controlador del personaje o los parámetros físicos.

Si eres una persona visual, si piensas en colores intensos e imágenes en movimiento, si las ideas te llegan como escenas totalmente formadas, con sonido, textura y peso emocional, tenías que traducir todo eso al lenguaje técnico antes de poder construirlo. Ves un mundo en tu mente, con su iluminación, su atmósfera y la forma en que los personajes se mueven por el espacio. Después te sientas frente al ordenador y pasas las seis horas siguientes intentando averiguar por qué tu personaje atraviesa el suelo.

La base técnica importa. Pero las herramientas obligaban a los creadores a vivir inmersos en los detalles de implementación, en lugar de abstraer toda esa complejidad. Crear un juego debería sentirse como contar una historia o dirigir una película en la que la gente puede participar. Esa es la magia del medio. En cambio, parecía que tenías que superar un examen de ingeniería antes siquiera de poder empezar.

Los directores de cine no pasan años aprendiendo a utilizar motores de física antes de poder expresar su visión. Reciben un presupuesto y cuentan con un equipo que se encarga de la ejecución técnica. Pero en el desarrollo de videojuegos independientes rara vez tienes presupuesto. Lo que tienes es tiempo y acceso a herramientas. Y si eres una persona técnica, puedes crear un juego increíble. Pero solo si lo eres.

Así surgieron títulos como Limbo, creado por un equipo pequeño con una visión artística única y los conocimientos técnicos necesarios para ejecutarla. O Undertale, creado en gran medida por una sola persona que casualmente reunía la combinación adecuada de instinto creativo y capacidad de programación. O Stardew Valley, para el que Eric Barone pasó años aprendiendo por su cuenta de todo, desde pixel art y composición musical hasta programación en C#.

Estos juegos triunfaron contra todo pronóstico. Pero por cada Limbo hay millones de visiones creativas que murieron porque las herramientas exigían una fluidez técnica que sus creadores no podían aportar. Menos del 3 % de los desarrolladores de videojuegos independientes llegan a alcanzar un éxito significativo. ¿Cuántos juegos brillantes nunca llegaron a crearse porque sus autores chocaron contra un muro de «si» y «entonces» y se rindieron?

La barrera de entrada no era la creatividad. Era la exclusión técnica incorporada en las propias herramientas.

Crear lo que debería haber existido

Por eso, hace 5 años, empecé a crear algo diferente.

La propuesta era sencilla: el desarrollo de videojuegos debería estar al alcance de cualquiera que tuviera una visión creativa. No deberías necesitar un título en informática para expresarte mediante medios interactivos. Las herramientas deberían adaptarse a cómo piensan realmente las personas creativas, y no al revés.

Inversores de capital riesgo de Sequoia, Pear, Draper y decenas de otras firmas me dijeron que no funcionaría. Es B2C. No existe mercado. Los desarrolladores independientes no pagan por nada. No se puede simplificar el desarrollo de videojuegos sin sacrificar capacidades. Los jugadores quieren juegos complejos, y los juegos complejos requieren herramientas complejas. Millones de excusas disfrazadas de análisis de mercado.

La gente me decía que estaba loca. Tal vez lo estaba. Pero siempre volvía a la misma pregunta: ¿por qué los presupuestos multimillonarios deberían ser un requisito previo para la expresión creativa? Los directores de cine y los productores de videojuegos famosos tienen equipos y recursos. Todos los demás reciben un editor de código y una plegaria. Yo quería crear aquello que cerrara esa brecha. Describes lo que quieres y ocurre ante tus ojos. Cada parte de mí sabía que aquello era lo correcto. Lo sentía en cada célula de mi cuerpo.

Hoy, miles de personas utilizan Cinevva a diario para crear recursos 3D para videojuegos, juegos, música, niveles y experiencias. Los proyectos creados hasta ahora acumulan millones de visualizaciones. Y crecemos cada día. Una presentación de dos minutos en Sand Hill Road no es precisamente el formato ideal para decir: «Suspendí el SAT, pero confíen en mi intuición».

Lo que significa realmente la intuición

Huang no estaba planteando únicamente una cuestión filosófica. Estaba describiendo un cambio real en lo que constituye una inteligencia valiosa.

Durante décadas optimizamos las cosas equivocadas. Construimos sistemas educativos que premiaban la memorización y el cálculo. Diseñamos exámenes estandarizados que medían la capacidad de reconocer patrones en problemas vistos anteriormente. Contratamos a personas basándonos en credenciales que demostraban que podían sobrevivir a cuatro años de filtros académicos. La IA acaba de hacer que todo eso sea menos especial.

Lo que la IA no puede hacer, al menos por ahora, es percibir lo que falta. Sentir cuándo algo no encaja. Intuir lo que la gente necesita antes de que pueda expresarlo por sí misma. Leer el ambiente. Comprender un contexto que no está recogido en ningún conjunto de datos.

Invertí mi tiempo, mi experiencia de vida internacional, mi dinero y mis conocimientos intuitivos en crear Cinevva. Es una combinación difícil de obtener en la universidad. Difícil de evaluar en el SAT. Difícil de reflejar en cualquier sistema de credenciales diseñado antes de que la IA hiciera abundante la potencia cognitiva pura.

Hace dieciséis o veinte años, los informáticos decidían qué aspecto debían tener las herramientas y cómo debían funcionar. Las creaban para sí mismos, para personas que pensaban como ellos. Se esperaba que el resto nos adaptáramos. Esa era está terminando. Quienes darán forma a lo que viene serán quienes entiendan lo que realmente quieren los seres humanos. Quienes puedan sentir cuándo algo está mal y cuándo está bien. Quienes creen para las personas en lugar de hacerlo para lograr elegancia técnica.

Confié en algo dentro de mí que el sistema consideraba inútil. Y tenía razón.

Relacionado:

• El mercado laboral se está transformando: de las credenciales a las habilidades
• Cursos de desarrollo de videojuegos en línea — caminos centrados en las habilidades que eluden los filtros tradicionales
• Ahora todos quieren ser el motor de videojuegos con IA — el cambio del sector hacia herramientas que se adaptan a la forma de pensar de las personas

Por Oleg Sidorkin, director de tecnología de Cinevva

La IA en los videojuegos se convirtió en un auténtico campo de minas hacia mediados de 2024. Puestos de trabajo que desaparecen. Personas convencidas de que serán las siguientes. Cuestiones de derechos de autor que ni siquiera los abogados pueden desenredar. Debates estéticos interminables que vuelven una y otra vez al punto de partida. Steam ahogándose en contenido que nadie pidió. Y, por debajo de todo, esa inquietud persistente que ahora tiene cada creador: «¿De verdad estoy creando algo o solo... escribiendo prompts?».

Gestionamos una plataforma. Y al hacerlo, hay algo que se aprende rápido.

A nadie le gusta sentirse engañado.

Estas cifras nos sorprendieron

Pensábamos que la adopción de la IA crecería. Pero no así. Esta era la situación a finales de 2025:

Fuentes: análisis de Tom's Hardware / Totally Human Media, encuesta de desarrolladores de GDC 2025 e informe Unity 2025 Gaming Report

Qué ocurrió realmente para que los jugadores se volvieran tan escépticos

Esto no surgió de la nada. Hubo problemas reales. Y la gente los recuerda.

Los actores de voz descubrieron que los habían clonado el día del lanzamiento

Tomb Raider 4-6 Remastered salió con versiones generadas por IA de las interpretaciones de voz originales. Los actores se enteraron al mismo tiempo que todos los demás: el día del lanzamiento. Al final, la distribuidora eliminó esas voces mediante un parche tras aumentar la presión legal. ¿Aquella huelga de SAG-AFTRA que duró once meses? Este era exactamente el tipo de situación que la impulsaba.

«Basura de IA» se convirtió en una expresión habitual

Call of Duty: Black Ops 6 añadió discretamente una declaración sobre el uso de IA a su página de Steam. Después de que el juego ya hubiera salido. Los jugadores habían detectado cosas extrañas: fallos visuales dispersos por todas partes. Un personaje de una pantalla de carga tenía seis dedos. «Basura de IA» se convirtió en una forma abreviada de referirse a cualquier cosa que se ve... rara. Vacía. Como si a nadie le hubiera importado lo suficiente como para revisarla.

Desapareció una nominación a un premio

A Clair Obscur: Expedition 33 le retiraron su nominación a Juego del Año en los Indie Game Awards. Sin embargo, el juego publicado no usaba IA. El problema eran los recursos provisionales generados con IA durante el desarrollo: material interno que nunca llegó a los jugadores. Los recursos finales fueron creados íntegramente por personas. No importó. Siguieron semanas de discusiones sobre dónde debía trazarse exactamente la línea.

Equipos que nunca usaron IA tuvieron que demostrarlo

Tanto Chessplus como Peak fueron acusados de usar IA. Ninguno la había utilizado. Ambos estaban nominados a premios. Los dos equipos de desarrollo terminaron rebuscando entre capturas antiguas y archivos con capas solo para demostrar que su trabajo estaba hecho a mano. El equipo de Peak lo expresó mejor que nadie: «Puede que seamos basura, pero somos basura artesanal, de origen local y hecha por personas».

Los estudios tomaron direcciones completamente opuestas

SNK — Los moderadores de Discord abandonaron su puesto después de que aparecieran imágenes con aspecto de estar generadas por IA en un tráiler de Fatal Fury: City of the Wolves. Games Workshop — Prohibió por completo la IA en todas las propiedades de Warhammer. Larian Studios — Afirmó que solo usó IA para bocetos conceptuales muy preliminares de Baldur's Gate 3 y que no había nada generado con IA en el juego final. Tim Sweeney — Declaró que las etiquetas de IA de Steam no servían para nada y que debían eliminarse. Valve — Replicó que los desarrolladores que se quejan de las etiquetas de IA suelen temer que su trabajo parezca «hecho con poco esfuerzo».

Encontrar juegos se convirtió en un problema de confianza

Ahora se produce contenido más rápido de lo que nadie puede evaluarlo adecuadamente. Las preguntas han cambiado:

¿Qué estoy viendo exactamente? ¿Quién ha hecho esto? ¿Me arrepentiré del tiempo que le dedique? ¿Se corresponde algo de esto con lo que prometía el tráiler?

Probablemente no habrá una gran resolución. Ningún veredicto definitivo sobre la IA frente al trabajo humano.

Lo más probable es que veamos filtros, transparencia real y estructuras de incentivos que fomenten la honestidad.

Los pequeños estudios, atrapados en medio de todo esto

Los desarrolladores independientes han quedado en una posición extraña.

Las ventajas son realmente difíciles de ignorar: Se puede iterar más rápido. Los costes bajan cuando cuatro personas tienen que hacerlo todo. Ahora los desarrolladores en solitario pueden llegar a terminar sus proyectos. La localización deja de comerse todo el presupuesto.

Las desventajas son igual de reales: Resultados que parecen genéricos. Preocupaciones sobre los datos de entrenamiento y la propiedad intelectual que los abogados todavía no quieren abordar. Publicar sistemas que no se comprenden del todo: algunos lo llaman deuda de comprensión. Quedar agrupado con la avalancha de lanzamientos hechos con poco esfuerzo. Casi la mitad de los desarrolladores encuestados cree que la IA empeora los videojuegos en general.

El informe de Unity de 2025 afirma que el 79 % de los desarrolladores ve con buenos ojos las herramientas de IA. Parece bastante concluyente. La realidad es más complicada. Los equipos que lo hacen bien suelen usar la IA para las partes aburridas: tareas pesadas, borradores iniciales y labores tediosas de control de calidad. ¿La dirección creativa? Esa sigue en manos humanas.

La postura de Cinevva: neutral ante la IA, estricta con la honestidad

No rechazamos juegos por usar IA. Tampoco les damos un trato especial.

La regla es sencilla: si intervino la IA, hay que decirlo. Los jugadores deciden qué les importa. Así los filtros funcionan de verdad.

• Política sobre contenido generado por IA

Los filtros funcionan mejor que las discusiones

El debate sobre la IA en los videojuegos no alcanzará un consenso pronto. Probablemente nunca. Pero ¿las preferencias individuales? Esas sí están bastante claras.

Algunos jugadores buscan específicamente arte dirigido por personas. Textos escritos por una persona. Un trabajo artesanal visible.

A otros, sinceramente, no les importa. Si es divertido, es divertido.

Los filtros permiten que ambos grupos encuentren lo que buscan. Nadie tiene que ganar.

Los modelos de pago importan más que la opinión de cualquiera

Cuando los ingresos dependen del tiempo de juego en lugar de las ventas por unidad, se gana dinero de esta forma:

Captando rápido a los jugadores. Manteniendo su atención. Ofreciendo lo que prometía el marketing.

La calidad se convierte en el camino evidente. Cómo se creó el juego importa menos.

¿El tráiler promete demasiado? Los jugadores se marchan de inmediato. La retención se desploma. ¿Les muestras exactamente lo que van a recibir? Se quedan. El tiempo de juego aumenta. Llegan los ingresos. La propia economía pone las cosas en su sitio.

Lo que probablemente traerá 2026

Más normas — La Ley de IA de la UE sigue ampliándose. Las protecciones de la voz y la imagen en Estados Unidos están creciendo, especialmente después de SAG-AFTRA.

Herramientas especializadas — IA creada específicamente para equipos pequeños. Diseñada para que las personas mantengan el control.

Etiquetas más precisas — «Hecho con IA» es demasiado impreciso. Cabe esperar distinciones entre flujos de trabajo asistidos por IA y recursos finales generados por IA.

División del público — Algunos jugadores buscarán deliberadamente juegos creados mediante métodos tradicionales. Otros ni siquiera pensarán en ello. Ambos grupos son lo bastante grandes como para crear juegos para ellos.

Competencia entre plataformas — La forma en que las tiendas gestionen la transparencia y el descubrimiento se convertirá en un verdadero factor diferenciador.

Lo que realmente hace avanzar las cosas

Discutir no resolverá la cuestión de la IA. Lo que sí lo hará:

1. Los jugadores, eligiendo en función de lo que realmente les importa
2. Los creadores, siendo honestos sobre cómo trabajan
3. Las plataformas, creando herramientas que ayuden a ambos grupos a encontrarse

Esa es la economía pos-IA. No bandos enfrentados. La confianza manteniéndolo todo unido.

Relacionado:

• Política sobre contenido generado por IA
• Para creadores de juegos
• Preguntas frecuentes
• Modelos frontera de IA generativa de código abierto — los modelos concretos y cómo funcionan
• El código abierto tiene un problema de contaminación por IA — qué ocurre cuando los resultados de la IA inundan los proyectos de código abierto

Por Oleg Sidorkin, CTO de Cinevva

Vi a mi primo graduarse con honores en 2023. Tenía un grado en informática de una buena universidad pública y un expediente sólido. Pasó catorce meses solicitando empleos antes de conseguir uno. Mientras tanto, un amigo que dejó la universidad en segundo año para crear juegos independientes recibió tres ofertas en el plazo de un mes desde que decidió empezar a buscar.

Eso ya no es una anomalía. Es la norma.

Las cifras por fin confirman lo que veníamos percibiendo

En 2025, el 90 % de los responsables de RR. HH. afirmó contratar a personas sin el tradicional título universitario de cuatro años (Fortune). Una cuarta parte de las empresas estadounidenses eliminó por completo el requisito de tener un grado universitario (HR Dive). Y esta es la parte que duele si acabas de terminar de pagar tus préstamos estudiantiles: el 94 % de los empleadores afirma que las contrataciones basadas en habilidades rinden mejor que las basadas en títulos (Forbes).

Verizon afirma ahora que el 99 % de sus puestos no requiere un título universitario. Sergey Brin admitió que Google contrata a «muchísimas» personas sin grado universitario. IBM hizo que la mitad de sus vacantes en Estados Unidos no exigieran titulación mediante su programa «New Collar».

No es que las empresas estén siendo caritativas. Se dieron cuenta de que los títulos no permitían predecir quién sería realmente bueno en el trabajo.

Por qué se rompió el antiguo sistema

¿La respuesta sincera? Los títulos se convirtieron en un filtro fácil.

Cuando estás contratando y tienes 400 solicitudes, exigir un grado universitario reduce la pila a la mitad. No te dice quién puede hacer realmente el trabajo. Te dice quién tuvo el dinero, el tiempo y la estabilidad familiar necesarios para pasar cuatro años en las aulas. Esa correlación con la capacidad siempre fue más débil de lo que fingíamos.

Y ahora han ocurrido tres cosas a la vez:

Las habilidades evolucionaron demasiado rápido. Motores de videojuegos, herramientas de IA, frameworks web. Para cuando un comité académico aprueba un curso sobre algo, ese algo ya está obsoleto. Un grado de cuatro años te enseña teoría de hace cuatro años. En tecnología, eso es historia antigua.

Los portafolios se volvieron irrefutables. ¿Por qué intentar adivinar si alguien sabe programar cuando puedes mirar su GitHub? ¿Por qué preguntarte si puede publicar un juego cuando su página de itch.io tiene cinco proyectos terminados con reseñas de jugadores?

Las empresas se desesperaron. La escasez de talento es real. Excluir a todo el mundo que no tenga un título implica excluir a personas que podrían ser exactamente lo que necesitas. Algunos responsables de contratación lo descubrieron por las malas, tras ver cómo desarrolladores autodidactas superaban con creces a empleados con títulos.

La industria de los videojuegos lo vio venir

Creo que el sector de los videojuegos se ha adelantado a esta tendencia, y merece la pena entender por qué.

A los estudios nunca les importó demasiado dónde estudiaste. Les importaba lo que habías publicado. Un juego pulido creado durante una game jam de 48 horas le dice más a un responsable de contratación que cualquier grado de cuatro años en diseño de videojuegos. Demuestra que sabes terminar proyectos bajo presión. Demuestra que tomaste decisiones difíciles sobre el alcance. Demuestra que el juego es jugable, no solo teórico.

Si intentas abrirte camino en la industria de los videojuegos en 2026, esto es lo que realmente importa (Dice, CombineGR): dos o tres demos pulidas y jugables. Estudios de caso que expliquen qué hiciste y por qué. Pruebas de que terminas los proyectos. Dominio de al menos un motor importante, demostrado mediante proyectos reales.

Los responsables de contratación no buscan potencial. Buscan pruebas.

La parte incómoda de la que nadie habla

Hay algo que me frustró cuando profundicé en la investigación.

Un estudio de Harvard y Burning Glass descubrió que las empresas que eliminaban los requisitos de titulación a menudo no contrataban realmente a más candidatos sin título. El aumento fue de solo unos 3,5 puntos porcentuales (Forbes). La política cambió. Las prácticas de contratación se quedaron atrás.

Eso significa que, si sigues una vía no tradicional, todavía tienes que esforzarte más. La puerta está más abierta que antes, pero aún no entras en igualdad de condiciones. Tu portafolio tiene que ser irrefutable. Tus proyectos deben hablar más alto que los títulos de otra persona.

No es justo. Pero saberlo te ayuda a prepararte.

Lo que le diría a alguien que empieza ahora mismo

Si estás estudiando, no lo dejes. Pero entiende que el título por sí solo ya no es suficiente. Crea proyectos en paralelo. Participa en game jams. Obtén un Certificado Profesional de Google o una certificación de Unity. Considera el título como una credencial más entre varias, no como la credencial definitiva.

Si no estás estudiando una carrera, tienes un camino diferente, pero no necesariamente más difícil. Crea proyectos sin parar. Publícalos. Documenta todo. Tu GitHub, tu página de itch.io, tu sitio web personal. Esas son ahora tus credenciales.

En cualquier caso, practica cómo explicar tu trabajo. No solo qué creaste, sino por qué tomaste esas decisiones. Qué harías de otra manera. Qué aprendiste. Los entrevistadores recuerdan a quienes saben articular su forma de pensar.

Esto va más allá de la contratación

Lo que está ocurriendo no es solo un cambio en la forma en que las empresas cubren puestos. Es un cambio en lo que valoramos colectivamente.

Durante décadas, los títulos sirvieron como filtro. Caros y lentos de obtener, pero fáciles de interpretar. Si alguien tenía un título, podías dar ciertas cosas por sentadas. Era una señal, no una medida directa, pero era suficiente.

Esa señal se está desmoronando. La tecnología permite ver lo que alguien sabe hacer realmente. El trabajo remoto demostró que los resultados importan más que el lugar desde el que trabajas. La IA está haciendo que el conocimiento teórico sea menos valioso que la aplicación práctica.

Esto me parece realmente esperanzador, aunque la transición sea complicada. Antes la pregunta era: «¿Dónde estudiaste?». Ahora es: «¿Qué sabes crear?».

Esa es una pregunta mejor.

Fuentes

• Fortune: El 90 % de los responsables de RR. HH. contrata a personas sin títulos tradicionales
• Forbes: El 90 % de las empresas realiza mejores contrataciones basándose en las habilidades
• Forbes: Las empresas eliminan los requisitos de titulación, pero contratan a pocas personas sin título
• HR Dive: Los empleadores eliminan los requisitos de titulación
• Computerworld: Las empresas tecnológicas se alejan del requisito de tener estudios universitarios
• Dice: Aspirantes a diseñadores de videojuegos en 2025
• CombineGR: Perspectivas mundiales del empleo en videojuegos para 2025

Relacionado:

• Cómo triunfar en las game jams
• Cursos en línea de desarrollo de videojuegos — itinerarios de aprendizaje centrados en habilidades para todos los presupuestos
• Herramientas de programación con IA agéntica — las herramientas que están redefiniendo qué habilidades importan
• La mente intuitiva — por qué la intuición importa más que los títulos