En resumen: Estamos construyendo un sistema de agua para Unreal Engine con dos promesas: agua que se ve bien porque la luz, el color y la espuma se calculan físicamente (no se ajustan a mano por escena) y agua que se comporta: suelta cualquier mesh sobre la superficie y flota, se vuelca o se hunde correctamente, sin ninguna configuración. Está en desarrollo activo. Esta publicación explica qué cubre, cómo nos hacemos responsables con fotografías de referencia, por qué la flotabilidad es la parte difícil que todos se saltan, y dónde encaja junto al resto del kit.
El estándar a superar. Fíjate en lo que lo hace real: espuma nacida de olas que rompen, bruma comiendo los acantilados, estadística de cabrillas por todo el oleaje. Nada colocado a mano, todo física. Esa es la vara que hemos puesto.
¿Por qué otro sistema de agua?
La mayoría del agua de los juegos se ve genial en exactamente una condición de luz: la de la captura de la tienda. Mueve el sol, cambia a nublado, pon la cámara medio bajo la línea de agua, y se desmorona.
Hay un segundo fallo, más silencioso, que importa igual: casi todos los sistemas de agua tratan los objetos flotantes como algo secundario. Consigues una plantilla de barco, una página de instrucciones de aparejo de pontones, y el supuesto tácito de que nadie tirará nunca una caja al azar al mar. Los jugadores tiran cajas al mar constantemente.
Queríamos dos cosas que actualmente no coexisten en un solo paquete: un aspecto de calidad cinematográfica que sobreviva a cualquier iluminación, y un comportamiento físico que no requiera ninguna configuración. Ninguno se logra ajustando parámetros hasta que una captura se ve bonita, porque una captura es un solo fotograma bajo un solo sol, y en cuanto cualquiera cambia, el agua ajustada al gusto muestra sus costuras. Así que el cimiento del proyecto no es una lista de funciones. Es una prueba de aceptación con la que un humano no puede discutir: una fotografía.
Juzgada contra fotos, no contra el gusto
El desarrollo está bloqueado por fotografías de referencia con contratos fijos de cámara e iluminación: unidades de luz físicas, un tonemapper bloqueado y una métrica de diferencia perceptual que decide aprobado o suspenso, no el ánimo del día de un director de arte.
Dos referencias son canónicas, y se eligieron para ser opuestas:
- Un lago claro, cámara en la línea de agua. Mitad aire, mitad agua, un límite ondulado sin banda de artefacto; agua verdosa de tipo costero cuyo color se ahonda con la distancia; cáusticas en las rocas que coinciden con la superficie encima; troncos sumergidos que se doblan correctamente en la interfaz. Esta prueba la refracción, el cruce de la línea de agua y la absorción de color bajo el agua, todo a la vez.
- Una costa de tormenta bajo cielo totalmente cubierto. Sin sol, sin banda de destello: el mar debe leerse por el reflejo suave del cielo, un gris-verde desaturado, la estadística de cabrillas y la bruma sobre los acantilados. Una boya cabalga el oleaje con un periodo e inclinación creíbles; el comportamiento es parte de la aceptación, no solo la imagen fija.
La referencia nublada es deliberadamente una de las dos. El agua soleada favorece a todos los renderizadores de la Tierra: el destello especular oculta multitud de pecados. Quita el sol, y el agua tiene que llevar el cuadro solo con la rugosidad de los reflejos, el color y el movimiento. Esa es la prueba honesta, y es la que la mayoría de los sistemas evita en silencio. Un océano que solo se ve bien con sol no se publica.
El lado de la cámara se especifica tan estrictamente como el del agua, porque una comparación fotográfica solo es justa cuando la cámara no puede hacer trampa. Eso significa intensidades de luz físicas reales (un sol de mediodía en torno a 100 000 lux, no un deslizador de brillo arbitrario), una exposición fija, y una configuración fija de tonemapping y bloom por referencia. Cambia el tonemapper y cualquier agua puede hacerse coincidir con cualquier foto, que es exactamente por qué el tonemapper se clava primero.
Drop-a-Mesh: flotar sin los deberes
Arrastra cualquier mesh sobre un cuerpo de agua Numivo y se comporta correctamente de inmediato: el sistema construye un proxy de física automáticamente, calcula el volumen desplazado por fotograma a partir de la altura de ola real, y deriva flota-o-se-hunde de la densidad real.
Bajo el agua es un lugar, no un post-proceso. El color se absorbe con la profundidad, la luz se filtra en haces, y la interfaz de arriba debe cruzarse limpiamente: la referencia del lago existe para mantener los tres honestos a la vez.
Un tronco flota y rueda sobre su lado largo. Una caja se mece. Una estatua de piedra se hunde. Sin aparejo, sin colocación de pontones, sin scripts. Bajo el capó:
- la forma de colisión se voxeliza automáticamente (de forma asíncrona, y se cachea por asset para que solo ocurra una vez) para medir el volumen real del objeto;
- la flotabilidad se calcula físicamente cada fotograma a partir del volumen desplazado frente a la densidad del agua, y el agua dulce y el agua salada difieren de verdad (el agua salada es más densa, así que la misma caja flota más alto en el mar que en un lago);
- flota-o-se-hunde viene de la densidad, la masa dividida por el volumen del proxy: no hay una casilla «¿debería esto flotar?» por defecto, porque el defecto es la física;
- la estabilidad emerge de cómo se distribuye el volumen del proxy: las cajas con peso arriba vuelcan, los cascos lastrados en la quilla se enderezan, un tablón queda plano;
- los objetos flotantes se reacoplan a la superficie: ondas, estelas, un anillo de espuma en la línea de agua, y efectos de salpicadura al impacto.
Hay un pequeño panel en el actor para overrides (forzar flotar, forzar hundir, un deslizador de amortiguación, interruptores de estela y salpicadura), pero un override escala la física en vez de reemplazarla. Fuerza a flotar a un peñasco y aún se mece con el periodo correcto y deja la estela correcta; solo se comporta como si fuera más ligero. Esa distinción importa: los resultados forzados que ignoran el solucionador parecen props pegados a un plano, y los jugadores lo notan al instante.
El objetivo de diseño es rotundo, y es una demo que queremos poder hacer en vivo: alguien arrastra veinte props al azar al mar, y todo simplemente se comporta, sin abrir una sola ventana de ajustes primero. Si esa demo necesita un tutorial, la función fracasó.
Qué cubre
Agua cercana a la costa, océano abierto, bajo el agua y charcas de cueva son todos de primera clase: olas basadas en espectro con oleaje de fondo y mar cruzada separados, espuma de olas que de verdad rompen, cáusticas que impulsan los haces de luz submarinos, y estabilidad bajo efectos cinematográficos.
Detalles que importan si te importa el agua:
- Las olas vienen de espectros oceanográficos (los mismos modelos estadísticos usados para describir los mares reales), con dispersión direccional y oleaje de fondo controlable de forma independiente. Un estado del mar se convierte en una decisión meteorológica («tormenta en aumento, oleaje largo del oeste») en lugar de treinta deslizadores desconectados que empujas hasta que parece tormentoso.
- La espuma no es una máscara pintada. Se origina donde las olas realmente rompen, envejece con el tiempo y se estría bajo el viento. La espuma pintada es el delator más común del agua falsa, porque no se mueve con la física que se supone que representa.
- Bajo el agua es un lugar real. Absorción de color correcta por profundidad (el rojo se va primero, luego el verde, dejando el azul profundo que todos conocen de las grabaciones de buceo), haces de luz derivados del mismo campo cáustico que ilumina el fondo, y un cruce en la línea de agua sin la clásica banda de artefacto dura.
- Las charcas de cueva tienen su propio tratamiento (agua quieta o apenas móvil, perturbaciones de goteo, reflejos en la casi oscuridad), porque una charca interior en calma expone fallos distintos que el océano abierto.
- Las cinemáticas son criterios de aceptación, no algo secundario. La superficie debe mantenerse estable bajo profundidad de campo, desenfoque de movimiento y grano de película: sin fireflies especulares que solo aparecen una vez aplicado el grano, sin parpadeo que una cámara lenta convierta en estroboscopio.
Por qué la flotabilidad es la parte que todos se saltan
El aspecto puede fingirse con un buen shader, pero el comportamiento no: un flota-y-se-hunde convincente necesita una estimación de volumen en tiempo real y un solucionador estable, lo cual es genuinamente difícil, así que la mayoría de los sistemas publican un prefab de barco y paran.
La incómoda verdad de ingeniería es que un shader de agua bonito es un problema resuelto y un solucionador de flotabilidad general no lo es. Fingir el aspecto de una ola es un problema de textura y normales; hacer que un mesh arbitrario, nunca visto antes, se asiente correctamente en esa ola es un problema de física que tiene que correr a velocidad de fotogramas, sobrevivir a pasos de tiempo rápidos, y no explotar cuando una roca de mil triángulos se encuentra con un oleaje de tormenta. Esa brecha es por qué «agua» en la mayoría de los motores significa «un plano bonito con el que no puedes interactuar», y por qué la parte interactiva, cuando existe, es un barco creado a mano.
Cerrar esa brecha (hacer el comportamiento tan automático como el aspecto) es la razón de existir de este proyecto y la razón por la que exige disciplina de foto de referencia más un solucionador real en lugar de un fin de semana de trabajo de shader.
¿Cuándo puedes usarlo?
Está en desarrollo como extensión de Unreal Engine, con un despliegue por etapas: una vista previa flotante cinemática llega antes que el solucionador físico completo, para que las escenas puedan poblarse pronto. No anunciamos una fecha; las imágenes de referencia deciden cuándo está listo.
El escalonamiento es deliberado. Una vista previa cinemática (los objetos siguen la superficie de las olas sin simulación de fuerza completa) llega primero, para que los artistas puedan soltar meshes y poblar un mar mientras el pesado solucionador aún se endurece: sientes el resultado mucho antes de que la física sea definitiva. El solucionador completo, el auto-proxy y el panel completo siguen. El progreso y los hitos aparecen en la roadmap pública, no en una sorpresa del día de lanzamiento.
El kit junto al que se publicará (scatter, mesh blending, grids, medición) es gratis de probar hoy. Si quieres que te notifiquen en cuanto exista un build público de agua, el Discord enlazado desde el sitio es donde se anunciará primero, y donde se publicarán las comparaciones de aprobado/suspenso de las imágenes de referencia según ocurran.
Mini-FAQ
¿Requerirá las otras herramientas de Numivo? No, es una extensión de la misma familia, diseñada para valerse por sí sola. Comparte, eso sí, el mismo principio: los resultados se hornean a datos nativos del motor siempre que sea físicamente posible, para que poseas lo que haces.
¿Qué versiones de motor? Las versiones actuales de Unreal Engine 5. Los detalles aterrizan en la roadmap a medida que la extensión se acerca a un build público, en vez de prometerse ahora y revisarse después.
¿En qué se diferencia del agua integrada del motor? Los sistemas de agua integrados son fuertes en el aspecto y débiles en la interacción general: la flotabilidad suele ser un componente separado, ajustado a mano. Todo el sentido aquí es que el aspecto y el comportamiento vienen de un solo sistema físicamente fundamentado, con el bloqueo de la foto de referencia manteniendo el aspecto honesto a través de la iluminación.
¿Por qué anunciar antes del lanzamiento? Porque el método de la fotografía de referencia es en sí el punto. Preferimos mostrar la vara públicamente y ser medidos contra ella que revelar algo terminado que nadie pudiera escrutar. Esta publicación es esa vara, por escrito: exíginoslo.
