Kort gezegd: We bouwen een watersysteem voor Unreal Engine met twee beloftes: water dat er juist uitziet omdat licht, kleur en schuim fysisch worden berekend (niet per scène met de hand afgesteld), en water dat zich gedraagt: laat een willekeurige mesh op het oppervlak vallen en het drijft, kantelt of zinkt correct, zonder enige instelling. Het is in actieve ontwikkeling. Deze post legt uit wat het dekt, hoe we onszelf verantwoordelijk houden met referentiefoto's, waarom drijfvermogen het lastige deel is dat iedereen overslaat, en waar het past naast de rest van de toolkit.
De maat om te verslaan. Let op wat dit echt maakt: schuim geboren uit brekende golven, nevel die de kliffen opeet, schuimkop-statistiek over de deining: niets met de hand geplaatst, alles fysica. Dat is de lat die we hebben gelegd.
Waarom nog een watersysteem?
Het meeste game-water ziet er in precies één lichtsituatie geweldig uit: die van de store-screenshot. Verplaats de zon, schakel naar bewolkt, zet de camera half onder de waterlijn, en het valt uit elkaar.*
Er is een tweede, stillere mislukking die net zo belangrijk is: bijna elk watersysteem behandelt drijvende objecten als een bijzaak. Je krijgt een bootsjabloon, een pagina met ponton-riggingsinstructies, en de onuitgesproken aanname dat niemand ooit een willekeurige kist in de zee gooit. Spelers gooien voortdurend kisten in de zee.
We wilden twee dingen die momenteel niet in één pakket samengaan: een uitstraling van filmkwaliteit die elke belichting overleeft, en fysisch gedrag dat geen instelling vereist. Geen van beide bereik je door aan parameters te sleutelen tot een screenshot mooi is, want een screenshot is één enkel frame onder één enkele zon, en zodra een van beide verandert, toont op smaak afgesteld water zijn naden. Het fundament van het project is dus geen lijst met functies. Het is een acceptatietest waar een mens niet mee kan discussiëren: een foto.
Beoordeeld tegen foto's, niet tegen smaak
Ontwikkeling wordt begrensd door referentiefoto's met vaste camera- en lichtcontracten: fysische lichteenheden, een vastgezette tonemapper, en een perceptuele verschilmetriek die slagen of zakken bepaalt, niet de dagstemming van een art director.*
Twee referenties zijn canoniek, en ze zijn gekozen om tegenpolen te zijn:
- Een helder meer, camera in de waterlijn. Half lucht, half water, een golvende grens zonder artefactband; groenig kustachtig water waarvan de kleur met de afstand dieper wordt; caustics op de rotsen die overeenkomen met het oppervlak erboven; verzonken boomstammen die correct buigen bij het grensvlak. Deze test breking, de waterlijnovergang en de onderwaterkleurabsorptie in één keer.
- Een stormkust onder volledige bewolking. Geen zon, geen glitterband: de zee moet leesbaar zijn via zachte hemelreflectie, ontkleurd grijsgroen, schuimkop-statistiek en nevel over de kliffen. Een boei rijdt de deining met een geloofwaardige periode en helling; het gedrag is deel van de acceptatie, niet alleen het stilstaande beeld.
De bewolkte referentie is bewust een van de twee. Zonovergoten water vleit elke renderer op aarde: de speculaire glitter verbergt een veelheid aan zonden. Neem de zon weg en het water moet het beeld alleen dragen op reflectieruwheid, kleur en beweging. Dat is de eerlijke test, en die vermijden de meeste systemen stilletjes. Een oceaan die er alleen goed uitziet in de zon, gaat niet in verkoop.
De camerakant is even strikt gespecificeerd als de waterkant, want een fotovergelijking is alleen eerlijk als de camera niet kan valsspelen. Dat betekent echte fysische lichtintensiteiten (een middagzon rond de 100.000 lux, geen willekeurige helderheidsschuif), een vaste belichting, en een vaste tonemapping- en bloomconfiguratie per referentie. Verander de tonemapper en elk water kan aan elke foto worden aangepast: precies waarom de tonemapper eerst wordt vastgespijkerd.
Drop-a-Mesh: drijven zonder het huiswerk
Sleep een willekeurige mesh op een Numivo-waterlichaam en het gedraagt zich meteen correct: het systeem bouwt automatisch een fysica-proxy, berekent het verplaatste volume per frame uit de werkelijke golfhoogte, en leidt drijf-of-zink af uit de echte dichtheid.*
Onder water is een plek, geen post-process. Kleur wordt met de diepte geabsorbeerd, licht filtert in bundels omlaag, en het grensvlak erboven moet netjes worden gekruist: de meer-referentie bestaat om alle drie tegelijk eerlijk te houden.
Een boomstam drijft en rolt op zijn lange kant. Een kist dobbert. Een stenen standbeeld zinkt. Geen rigging, geen pontonplaatsing, geen scripts. Onder de motorkap:
- de collisievorm wordt automatisch gevoxeliseerd (asynchroon, en per asset gecachet zodat het maar één keer gebeurt) om het echte volume van het object te meten;
- drijfvermogen wordt elk frame fysisch berekend uit het verplaatste volume tegen de dichtheid van het water, en zoet en zout water verschillen echt (zout water is dichter, dus dezelfde kist rijdt hoger in de zee dan in een meer);
- drijf-of-zink komt uit de dichtheid, massa gedeeld door proxy-volume: er is geen "moet dit drijven?"- vinkje als standaard, want de standaard is de fysica;
- stabiliteit ontstaat uit hoe het volume van de proxy is verdeeld: topzware kisten kapseizen, kielgewogen rompen richten zichzelf op, een plank ligt plat;
- drijvende objecten koppelen terug in het oppervlak: rimpelingen, kielzogen, een schuimring aan de waterlijn, en spateffecten bij inslag.
Er is een klein paneel op de actor voor overrides (drijven forceren, zinken forceren, een dempingsschuif, kielzog- en spatschakelaars), maar een override schaalt de fysica in plaats van haar te vervangen. Forceer een rotsblok om te drijven en het dobbert nog steeds met de juiste periode en laat het juiste kielzog na; het gedraagt zich alleen alsof het lichter is. Dat onderscheid telt: geforceerde resultaten die de solver negeren zien eruit als props op een vlak geplakt, en spelers merken het meteen.
Het ontwerpdoel is botweg, en het is een demo die we live moeten kunnen draaien: iemand sleept twintig willekeurige props op de zee, en alles gedraagt zich gewoon: zonder eerst één enkel instellingenvenster te openen. Als die demo een tutorial nodig heeft, is de functie mislukt.
Wat het dekt
Kustnabij water, open oceaan, onder water en grotpoelen zijn allemaal eersteklas: spectrum-gebaseerde golven met aparte deining en kruiszee, schuim van echt brekende golven, caustics die onderwaterlichtbundels aandrijven, en stabiliteit onder cinematische effecten.*
Details die tellen als water je iets kan schelen:
- Golven komen uit oceanografische spectra (dezelfde statistische modellen die echte zeeën beschrijven), met richtingsspreiding en onafhankelijk regelbare deining. Een zeegang wordt een weerbeslissing, "opkomende storm, lange deining uit het westen", in plaats van dertig losstaande schuiven die je duwt tot het stormig oogt.
- Schuim is geen geschilderd masker. Het ontstaat waar golven werkelijk breken, veroudert in de tijd en trekt strepen onder wind. Geschilderd schuim is het meest voorkomende teken van nepwater, omdat het niet meebeweegt met de fysica die het moet voorstellen.
- Onder water is een echte plek. Correcte kleurabsorptie per diepte (rood gaat eerst, dan groen, waarna het diepe blauw overblijft dat iedereen van duikbeelden kent), lichtbundels afgeleid van hetzelfde caustic-veld dat de bodem verlicht, en een overgang aan de waterlijn zonder de klassieke harde artefactband.
- Grotpoelen krijgen hun eigen behandeling (stil of nauwelijks bewegend water, druppelverstoringen, reflecties in het bijna-donker) omdat een kalme binnenpoel andere fouten blootlegt dan de open oceaan.
- Cinematics zijn acceptatiecriteria, geen bijzaak. Het oppervlak moet stabiel blijven onder scherptediepte, motion blur en filmkorrel: geen speculaire fireflies die pas verschijnen zodra korrel is toegepast, geen geflikker dat een trage camera in stroboscoop verandert.
Waarom drijfvermogen het deel is dat iedereen overslaat
De look kan worden nagemaakt met een goede shader, maar het gedrag niet: een overtuigend drijf-en-zink heeft een real-time volumeschatting en een stabiele solver nodig, wat echt lastig is, dus de meeste systemen leveren een boot-prefab en houden op.*
De ongemakkelijke technische waarheid is dat een mooie watershader een opgelost probleem is en een algemene drijfvermogen-solver niet. De look van een golf namaken is een textuur-en-normaalprobleem; een willekeurige, nooit eerder geziene mesh correct in die golf laten zitten is een fysicaprobleem dat op framerate moet draaien, snelle tijdstappen moet overleven, en niet mag exploderen wanneer een rots van duizend driehoeken een stormdeining ontmoet. Die kloof is waarom "water" in de meeste engines "een mooi vlak waarmee je niet kunt interacteren" betekent, en waarom het interactieve deel, wanneer het bestaat, een met de hand gemaakte boot is.
Die kloof dichten (gedrag net zo automatisch maken als de look) is de reden dat dit project bestaat en de reden dat het referentiefoto-discipline plus een echte solver vereist in plaats van een weekend shaderwerk.
Wanneer kun je het gebruiken?
Het is in ontwikkeling als Unreal Engine-extensie, met een gefaseerde uitrol: een kinematische drijvende preview landt vóór de volledige fysica-solver, zodat scènes vroeg kunnen worden bevolkt. We kondigen geen datum aan; de referentiebeelden beslissen wanneer het klaar is.*
De fasering is bewust. Een kinematische preview (objecten volgen het golfoppervlak zonder volledige krachtsimulatie) komt eerst, zodat artists meshes kunnen neerzetten en een zee kunnen bevolken terwijl de zware solver nog wordt gehard: je voelt het resultaat lang voordat de fysica definitief is. De volledige solver, de auto-proxy en het complete paneel volgen. Voortgang en mijlpalen verschijnen op de openbare roadmap, niet in een launch-day-verrassing.
De toolkit waarnaast het uitkomt (scatter, mesh blending, grids, meten) is vandaag gratis te proberen. Wil je op de hoogte worden gebracht zodra een openbare waterbuild bestaat, dan is de vanaf de site gelinkte Discord de plek waar het eerst wordt aangekondigd, en waar de slagen/zakken-vergelijkingen van de referentiebeelden worden gepost zodra ze gebeuren.
Mini-FAQ
Vereist het de andere tools van Numivo? Nee, het is een extensie in dezelfde familie, ontworpen om op zichzelf te staan. Het deelt wel hetzelfde principe: resultaten bakken tot engine-native data waar fysisch mogelijk, zodat je bezit wat je maakt.
Welke engineversies? Huidige Unreal Engine 5-releases. Details landen op de roadmap naarmate de extensie een openbare build nadert, in plaats van nu te worden beloofd en later herzien.
Hoe verschilt dit van het ingebouwde water van de engine? Ingebouwde watersystemen zijn sterk in de look en zwak in algemene interactie: drijfvermogen is doorgaans een apart, met de hand afgesteld component. Het hele punt hier is dat look en gedrag uit één fysisch gefundeerd systeem komen, waarbij het referentiefoto-slot de look eerlijk houdt over belichtingen heen.
Waarom aankondigen vóór release? Omdat de referentiefoto-methode zelf het punt is. We tonen liever de lat publiekelijk en laten ons eraan meten dan een afgewerkt ding te onthullen dat niemand kon onderzoeken. Deze post is die lat, op schrift: houd ons eraan.
