Stiamo costruendo un sistema d'acqua per Unreal Engine con due promesse: acqua che appare giusta perché luce, colore e schiuma sono calcolati fisicamente (non regolati a mano per scena) e acqua che si comporta: butta un mesh qualsiasi sulla superficie e galleggia, si ribalta o affonda correttamente, senza alcuna configurazione. È in sviluppo attivo. Questo post spiega cosa copre, come ci teniamo responsabili con fotografie di riferimento, perché la galleggiabilità è la parte difficile che tutti saltano, e dove si colloca accanto al resto del toolkit.
Lo standard da battere. Nota cosa lo rende reale: schiuma nata da onde che si infrangono, foschia che mangia le scogliere, la statistica delle creste bianche su tutta l'onda lunga: nulla piazzato a mano, tutto fisica. È l'asticella che abbiamo posto.
Perché un altro sistema d'acqua?
La maggior parte dell'acqua nei giochi appare fantastica in esattamente una condizione di luce: quella dello screenshot dello store. Sposta il sole, passa a coperto, metti la telecamera a metà sotto la linea d'acqua, e crolla.
C'è un secondo fallimento, più silenzioso, che conta altrettanto: quasi ogni sistema d'acqua tratta gli oggetti galleggianti come un ripensamento. Ottieni un template di barca, una pagina di istruzioni di rigging dei pontoni, e l'assunto tacito che nessuno getterà mai una cassa a caso in mare. I giocatori gettano casse in mare di continuo.
Volevamo due cose che attualmente non coesistono in un unico pacchetto: un aspetto di qualità cinematografica che sopravviva a qualsiasi illuminazione, e un comportamento fisico che non richieda alcuna configurazione. Nessuno dei due è raggiungibile ritoccando parametri finché uno screenshot appare bello, perché uno screenshot è un singolo fotogramma sotto un singolo sole, e nel momento in cui uno dei due cambia, l'acqua regolata a gusto mostra le sue cuciture. Quindi la base del progetto non è un elenco di funzioni. È un test di accettazione con cui un umano non può discutere: una fotografia.
Giudicata contro le foto, non contro il gusto
Lo sviluppo è vincolato da fotografie di riferimento con contratti fissi di telecamera e illuminazione: unità di luce fisiche, un tonemapper bloccato, e una metrica di differenza percettiva che decide superato o non superato, non l'umore del giorno di un art director.
Due riferimenti sono canonici, e sono stati scelti per essere opposti:
- Un lago limpido, telecamera nella linea d'acqua. Metà aria, metà acqua, un confine ondulato senza banda di artefatto; acqua verdastra di tipo costiero il cui colore si approfondisce con la distanza; caustiche sulle rocce che corrispondono alla superficie sopra; tronchi sommersi che si piegano correttamente all'interfaccia. Questo testa rifrazione, l'attraversamento della linea d'acqua e l'assorbimento del colore subacqueo, tutto in una volta.
- Una costa in tempesta sotto cielo completamente coperto. Niente sole, niente banda di scintillio: il mare deve leggersi attraverso la morbida riflessione del cielo, un grigio-verde desaturato, la statistica delle creste bianche e la foschia sulle scogliere. Una boa cavalca l'onda lunga con un periodo e un'inclinazione credibili; il comportamento fa parte dell'accettazione, non solo l'immagine ferma.
Il riferimento coperto è deliberatamente uno dei due. L'acqua soleggiata lusinga ogni renderer sulla Terra. Lo scintillio speculare nasconde una moltitudine di peccati. Togli il sole, e l'acqua deve reggere il fotogramma solo con la rugosità delle riflessioni, il colore e il movimento. Quello è il test onesto, ed è quello che la maggior parte dei sistemi evita in silenzio. Un oceano che appare bene solo al sole non viene pubblicato.
Il lato telecamera è specificato con lo stesso rigore del lato acqua, perché un confronto fotografico è equo solo quando la telecamera non può barare. Ciò significa vere intensità di luce fisiche (un sole di mezzogiorno intorno ai 100.000 lux, non uno slider di luminosità arbitrario), un'esposizione fissa, e una configurazione fissa di tonemapping e bloom per riferimento. Cambia il tonemapper e qualsiasi acqua può essere fatta corrispondere a qualsiasi foto, il che è esattamente il motivo per cui il tonemapper viene inchiodato per primo.
Drop-a-Mesh: galleggiare senza i compiti
Trascina un mesh qualsiasi su un corpo d'acqua Numivo e si comporta correttamente subito: il sistema costruisce automaticamente un proxy fisico, calcola il volume spostato per fotogramma dalla reale altezza dell'onda, e deriva galleggia-o-affonda dalla densità reale.
Sott'acqua è un luogo, non un post-process. Il colore assorbe con la profondità, la luce filtra in raggi, e l'interfaccia sopra deve essere attraversata in modo pulito. Il riferimento del lago esiste per tenere tutti e tre onesti in una volta.
Un tronco galleggia e rotola sul lato lungo. Una cassa ondeggia. Una statua di pietra affonda. Nessun rigging, nessun posizionamento di pontoni, nessuno script. Sotto il cofano:
- la forma di collisione è voxelizzata automaticamente (in modo asincrono, e messa in cache per asset così accade solo una volta) per misurare il volume reale dell'oggetto;
- la galleggiabilità è calcolata fisicamente a ogni fotogramma dal volume spostato contro la densità dell'acqua, e acqua dolce e salata differiscono davvero (l'acqua salata è più densa, quindi la stessa cassa cavalca più in alto in mare che in un lago);
- galleggia-o-affonda viene dalla densità, massa divisa per il volume del proxy; non c'è una casella "questo dovrebbe galleggiare?" come default, perché il default è la fisica;
- la stabilità emerge da come è distribuito il volume del proxy: le casse con peso in alto si capovolgono, gli scafi zavorrati sulla chiglia si raddrizzano, un'asse sta in piano;
- gli oggetti galleggianti si riaccoppiano alla superficie: increspature, scie, un anello di schiuma alla linea d'acqua, ed effetti di spruzzo all'impatto.
C'è un piccolo pannello sull'actor per gli override: forza galleggiamento, forza affondamento, uno slider di smorzamento, interruttori di scia e spruzzo. Ma un override scala la fisica invece di sostituirla. Forza il galleggiamento di un masso e ondeggia comunque con il periodo giusto e lascia la scia giusta; si comporta solo come se fosse più leggero. Questa distinzione conta: i risultati forzati che ignorano il solver sembrano props incollati a un piano, e i giocatori se ne accorgono all'istante.
L'obiettivo di design è schietto, ed è una demo che vogliamo poter eseguire dal vivo: qualcuno trascina venti props a caso in mare, e tutto si comporta semplicemente, senza aprire prima una singola finestra di impostazioni. Se quella demo ha bisogno di un tutorial, la funzione ha fallito.
Cosa copre
Acqua costiera, oceano aperto, sott'acqua e pozze di grotta sono tutti di prima classe: onde basate su spettro con onda lunga e mare incrociato separati, schiuma da onde che si infrangono davvero, caustiche che guidano i raggi di luce subacquei, e stabilità sotto effetti cinematografici.
Specifiche che contano se ti importa dell'acqua:
- Le onde vengono da spettri oceanografici (gli stessi modelli statistici usati per descrivere i mari reali), con dispersione direzionale e onda lunga controllabile indipendentemente. Uno stato del mare diventa una decisione meteo, tipo "tempesta in arrivo, onda lunga da ovest", invece di trenta slider slegati che spingi finché sembra in tempesta.
- La schiuma non è una maschera dipinta. Nasce dove le onde si infrangono davvero, invecchia nel tempo e si stria sotto il vento. La schiuma dipinta è la spia più comune dell'acqua finta, perché non si muove con la fisica che dovrebbe rappresentare.
- Sott'acqua è un luogo reale. Corretto assorbimento del colore per profondità (il rosso va per primo, poi il verde, lasciando il blu profondo che tutti conoscono dalle riprese subacquee), raggi di luce derivati dallo stesso campo caustico che illumina il fondo, e un attraversamento alla linea d'acqua senza la classica banda dura di artefatto.
- Le pozze di grotta ricevono il proprio trattamento: acqua ferma o appena mossa, disturbi di gocce, riflessi nel semibuio, perché una pozza interna calma espone difetti diversi dall'oceano aperto.
- Le cinematiche sono criteri di accettazione, non un ripensamento. La superficie deve restare stabile sotto profondità di campo, motion blur e grana della pellicola: niente fireflies speculari che appaiono solo una volta applicata la grana, niente scintillio che una telecamera lenta trasforma in stroboscopio.
Perché la galleggiabilità è la parte che tutti saltano
L'aspetto si può fingere con un buon shader, ma il comportamento no: un galleggia-e-affonda convincente ha bisogno di una stima del volume in tempo reale e di un solver stabile, cosa genuinamente difficile, quindi la maggior parte dei sistemi pubblica un prefab di barca e si ferma.
La scomoda verità ingegneristica è che un bel shader d'acqua è un problema risolto e un solver di galleggiabilità generale no. Fingere l'aspetto di un'onda è un problema di texture e normali; far sedere correttamente in quell'onda un mesh arbitrario, mai visto prima, è un problema di fisica che deve girare a frame rate, sopravvivere a passi temporali rapidi, e non esplodere quando una roccia da mille triangoli incontra un'onda lunga di tempesta. Quel divario è il motivo per cui "acqua" nella maggior parte dei motori significa "un bel piano con cui non puoi interagire", e perché la parte interattiva, quando esiste, è una barca creata a mano.
Colmare quel divario (rendere il comportamento automatico quanto l'aspetto) è la ragione per cui questo progetto esiste e la ragione per cui richiede disciplina di foto di riferimento più un vero solver invece di un weekend di lavoro su shader.
Quando potrai usarlo?
È in sviluppo come estensione di Unreal Engine, con un rollout a fasi: un'anteprima galleggiante cinematica arriva prima del solver fisico completo, così le scene possono essere popolate presto. Non annunciamo una data; le immagini di riferimento decidono quando è finito.
La suddivisione è deliberata. Un'anteprima cinematica (gli oggetti seguono la superficie delle onde senza simulazione di forza completa) arriva prima, così gli artisti possono buttare mesh e popolare un mare mentre il pesante solver è ancora in fase di irrobustimento. Senti il risultato molto prima che la fisica sia definitiva. Il solver completo, l'auto-proxy e il pannello completo seguono. Progressi e milestone appaiono sulla roadmap pubblica, non in una sorpresa del giorno del lancio.
Il toolkit accanto a cui uscirà (scatter, mesh blending, grid, misurazione) è gratis da provare oggi. Se vuoi essere avvisato nel momento in cui esiste un build pubblico dell'acqua, il Discord collegato dal sito è dove sarà annunciato per primo, e dove i confronti superato/non superato delle immagini di riferimento verranno pubblicati man mano che accadono.
Mini-FAQ
Richiederà gli altri strumenti di Numivo? No, è un'estensione della stessa famiglia, progettata per reggersi da sola. Condivide però lo stesso principio: i risultati si convertono in dati nativi del motore ovunque sia fisicamente possibile, così possiedi ciò che crei.
Quali versioni di motore? Le versioni attuali di Unreal Engine 5. Le specifiche atterrano sulla roadmap man mano che l'estensione si avvicina a un build pubblico, invece di essere promesse ora e riviste dopo.
In cosa è diverso dall'acqua integrata del motore? I sistemi d'acqua integrati sono forti sull'aspetto e deboli sull'interazione generale: la galleggiabilità è tipicamente un componente separato, regolato a mano. Tutto il punto qui è che aspetto e comportamento vengono da un unico sistema fisicamente fondato, con il vincolo della foto di riferimento che tiene onesto l'aspetto attraverso le illuminazioni.
Perché annunciare prima del rilascio? Perché il metodo della fotografia di riferimento è esso stesso il punto. Preferiamo mostrare l'asticella pubblicamente ed essere misurati su di essa piuttosto che rivelare una cosa finita che nessuno avrebbe potuto scrutinare. Questo post è quell'asticella, per iscritto: chiedeteci conto.
