Wasser, das sich benimmt: ein erster Blick auf Numivo Water

Kurz gesagt: Wir bauen ein Wassersystem für Unreal Engine mit zwei Versprechen: Wasser, das richtig aussieht, weil Licht, Farbe und Schaum physikalisch berechnet werden, nicht pro Szene von Hand getunt, und Wasser, das sich benimmt: Wirf ein beliebiges Mesh auf die Oberfläche, und es schwimmt, kippt oder sinkt korrekt, ohne Einrichtung. Es ist in aktiver Entwicklung. Dieser Beitrag erklärt, was es abdeckt, wie wir uns mit Referenzfotos in die Pflicht nehmen, warum Auftrieb der schwierige Teil ist, den alle überspringen, und wo es neben dem Rest des Toolkits passt.

Der Maßstab, den es zu schlagen gilt. Beachte, was das real macht: Schaum, aus brechenden Wellen geboren, Dunst, der die Klippen frisst, Schaumkronen-Statistik über den Wellengang, nichts davon von Hand platziert, alles Physik. Das ist die Latte, die wir gesetzt haben.

Warum noch ein Wassersystem?

Das meiste Spielwasser sieht in genau einer Lichtsituation großartig aus: der auf dem Store-Screenshot. Beweg die Sonne, schalte auf bedeckt, setz die Kamera halb unter die Wasserlinie, und es fällt auseinander.

Es gibt ein zweites, stilleres Versagen, das genauso wichtig ist: Fast jedes Wassersystem behandelt schwimmende Objekte als Nachgedanken. Du bekommst eine Boot-Vorlage, eine Seite Ponton-Rigging- Anleitung und die unausgesprochene Annahme, dass niemand je eine zufällige Kiste ins Meer wirft. Spieler werfen ständig Kisten ins Meer.

Wir wollten zwei Dinge, die derzeit nicht in einem Paket koexistieren: filmreifen Look, der jede Beleuchtung übersteht, und physikalisches Verhalten, das keine Einrichtung braucht. Keines davon erreicht man durch Parameter-Getüftel, bis ein Screenshot schön aussieht, denn ein Screenshot ist ein einzelnes Bild unter einer einzelnen Sonne, und sobald sich eines ändert, zeigt nach Geschmack getuntes Wasser seine Nähte. Das Fundament des Projekts ist also keine Feature-Liste. Es ist ein Abnahmetest, mit dem ein Mensch nicht streiten kann: ein Foto.

Gemessen an Fotos, nicht am Geschmack

Die Entwicklung wird durch Referenzfotos mit festen Kamera- und Lichtverträgen gegated: physikalische Lichteinheiten, ein fixierter Tonemapper und eine perzeptuelle Differenzmetrik, die über Bestehen oder Nichtbestehen entscheidet, nicht die Tageslaune eines Art Directors.

Zwei Referenzen sind kanonisch, und sie wurden als Gegensätze gewählt:

• Ein klarer See, Kamera in der Wasserlinie. Halb Luft, halb Wasser, eine wellige Grenze ohne Artefaktband; grünes Küstenwasser, dessen Farbe mit der Distanz tiefer wird; Kaustiken auf den Felsen, die zur Oberfläche darüber passen; versunkene Baumstämme, die sich an der Grenzfläche korrekt brechen. Diese testet Brechung, den Wasserlinien-Übergang und die Unterwasser-Farbabsorption auf einmal.
• Eine Sturmküste unter voller Bewölkung. Keine Sonne, kein Glitzerband, das Meer muss durch weiche Himmelsreflexion, entsättigtes Graugrün, Schaumkronen-Statistik und Dunst über den Klippen lesbar sein. Eine Boje reitet den Wellengang mit glaubwürdiger Periode und Neigung; das Verhalten ist Teil der Abnahme, nicht nur das Standbild.

Die bedeckte Referenz ist bewusst eine der beiden. Sonnenbeschienenes Wasser schmeichelt jedem Renderer der Welt: das Spekular-Glitzern verbirgt eine Vielzahl von Sünden. Nimm die Sonne weg, und das Wasser muss das Bild allein durch Reflexions-Rauheit, Farbe und Bewegung tragen. Das ist der ehrliche Test, und es ist der, den die meisten Systeme still vermeiden. Ein Ozean, der nur bei Sonnenschein gut aussieht, geht nicht in den Verkauf.

Die Kamera-Seite ist so streng spezifiziert wie die Wasser-Seite, denn ein Foto-Vergleich ist nur fair, wenn die Kamera nicht schummeln kann. Das bedeutet echte physikalische Lichtintensitäten (eine Mittagssonne um die 100.000 Lux, kein beliebiger Helligkeitsregler), eine feste Belichtung und eine feste Tonemapping- und Bloom-Konfiguration pro Referenz. Ändere den Tonemapper, und jedes Wasser lässt sich an jedes Foto anpassen, genau deshalb wird der Tonemapper zuerst festgenagelt.

Drop-a-Mesh: schwimmen ohne die Hausaufgaben

Zieh ein beliebiges Mesh auf einen Numivo-Wasserkörper, und es benimmt sich sofort korrekt: das System baut automatisch einen Physik-Proxy, berechnet das verdrängte Volumen pro Frame aus der tatsächlichen Wellenhöhe und leitet Schwimmen-oder-Sinken aus der realen Dichte ab.

Unterwasser ist ein Ort, kein Post-Process. Farbe wird mit der Tiefe absorbiert, Licht fällt in Schäften herab, und die Grenzfläche darüber muss sauber übergehen; die See-Referenz existiert, um alle drei auf einmal ehrlich zu halten.

Ein Baumstamm schwimmt und rollt auf seine lange Seite. Eine Kiste dümpelt. Eine Steinstatue sinkt. Kein Rigging, keine Ponton-Platzierung, keine Skripte. Unter der Haube:

• die Kollisionsform wird automatisch voxelisiert (asynchron und pro Asset gecacht, sodass es nur einmal passiert), um das reale Volumen des Objekts zu messen;
• der Auftrieb wird jeden Frame physikalisch berechnet aus dem verdrängten Volumen gegen die Dichte des Wassers, und Süß- und Salzwasser unterscheiden sich echt (Salzwasser ist dichter, also reitet dieselbe Kiste im Meer höher als in einem See);
• Schwimmen-oder-Sinken kommt aus der Dichte, Masse geteilt durch Proxy-Volumen; es gibt kein „Soll das schwimmen?"-Häkchen als Standard, denn der Standard ist die Physik;
• Stabilität ergibt sich daraus, wie das Volumen des Proxys verteilt ist: kopflastige Kisten kentern, kielbeschwerte Rümpfe richten sich auf, eine Planke liegt flach;
• schwimmende Objekte koppeln zurück in die Oberfläche: Kräuselungen, Kielwasser, ein Schaumring an der Wasserlinie und Spritzeffekte beim Aufprall.

Es gibt ein kleines Panel am Actor für Overrides (Schwimmen erzwingen, Sinken erzwingen, ein Dämpfungsregler, Kielwasser- und Spritz-Schalter), aber ein Override skaliert die Physik, statt sie zu ersetzen. Erzwing das Schwimmen eines Felsbrockens, und er dümpelt trotzdem mit der richtigen Periode und hinterlässt das richtige Kielwasser; er benimmt sich nur, als wäre er leichter. Diese Unterscheidung zählt: erzwungene Ergebnisse, die den Solver ignorieren, sehen aus wie auf eine Fläche geklebte Requisiten, und Spieler bemerken es sofort.

Das Design-Ziel ist unverblümt, und es ist eine Demo, die wir live vorführen können wollen: Jemand zieht zwanzig zufällige Requisiten aufs Meer, und alles benimmt sich einfach, ohne zuvor ein einziges Einstellungsfenster zu öffnen. Wenn diese Demo ein Tutorial braucht, ist das Feature gescheitert.

Was es abdeckt

Küstennahes Wasser, offener Ozean, Unterwasser und Höhlenteiche sind alle erstklassig: spektrumbasierte Wellen mit getrenntem Swell und Kreuzsee, Schaum aus tatsächlich brechenden Wellen, Kaustiken, die Unterwasser-Lichtschäfte treiben, und Stabilität unter cineastischen Effekten.

Details, die zählen, wenn dir Wasser wichtig ist:

• Wellen kommen aus ozeanographischen Spektren (denselben statistischen Modellen, die reale Meere beschreiben), mit gerichteter Streuung und unabhängig steuerbarem Swell. Ein Seegang wird zu einer Wetter-Entscheidung: „aufziehender Sturm, langer Swell aus Westen", statt zu dreißig zusammenhanglosen Reglern, an denen du drehst, bis es stürmisch aussieht.
• Schaum ist keine gemalte Maske. Er entsteht dort, wo Wellen tatsächlich brechen, altert mit der Zeit und zieht Streifen unter Wind. Gemalter Schaum ist der häufigste Verräter falschen Wassers, weil er sich nicht mit der Physik bewegt, die er darstellen soll.
• Unterwasser ist ein echter Ort. Korrekte Farbabsorption nach Tiefe (Rot geht zuerst, dann Grün, übrig bleibt das tiefe Blau, das jeder aus Tauchvideos kennt), Lichtschäfte, abgeleitet aus demselben Kaustikfeld, das den Grund beleuchtet, und ein Übergang an der Wasserlinie ohne das klassische harte Artefaktband.
• Höhlenteiche bekommen ihre eigene Behandlung: stilles oder kaum bewegtes Wasser, tropfende Störungen, Reflexionen im Halbdunkel, weil ein ruhiger Innenteich andere Fehler bloßlegt als der offene Ozean.
• Cinematics sind Abnahmekriterien, kein Nachgedanke. Die Oberfläche muss unter Tiefenschärfe, Motion Blur und Filmkorn stabil bleiben: keine Spekular-Fireflies, die erst mit Korn erscheinen, kein Flimmern, das eine langsame Kamera in Stroboskop verwandelt.

Warum Auftrieb der Teil ist, den alle überspringen

Der Look lässt sich mit einem guten Shader faken, das Verhalten nicht: überzeugendes Schwimmen-und-Sinken braucht eine Echtzeit-Volumenschätzung und einen stabilen Solver, was wirklich schwer ist, also liefern die meisten Systeme ein Boot-Prefab und hören auf.

Die unbequeme Ingenieurswahrheit ist, dass ein schöner Wasser-Shader ein gelöstes Problem ist und ein allgemeiner Auftriebs-Solver nicht. Den Look einer Welle zu faken ist ein Textur-und-Normal-Problem; ein beliebiges, nie zuvor gesehenes Mesh korrekt in dieser Welle sitzen zu lassen, ist ein Physik-Problem, das mit Framerate laufen, schnelle Zeitschritte überstehen und nicht explodieren muss, wenn ein Tausend-Dreieck-Fels auf einen Sturmwellengang trifft. Diese Lücke ist der Grund, warum „Wasser" in den meisten Engines „eine hübsche Fläche, mit der man nicht interagieren kann" bedeutet, und warum der interaktive Teil, wenn er existiert, ein von Hand erstelltes Boot ist.

Diese Lücke zu schließen, Verhalten so automatisch zu machen wie den Look, ist der Grund, warum dieses Projekt existiert, und der Grund, warum es Referenzfoto-Disziplin plus einen echten Solver braucht statt eines Wochenendes Shader-Arbeit.

Wann kannst du es nutzen?

Es ist in Entwicklung als Unreal-Engine-Erweiterung, mit einem gestaffelten Rollout: eine kinematische Schwimm-Vorschau landet vor dem vollen Physik-Solver, sodass Szenen früh bevölkert werden können. Wir kündigen kein Datum an; die Referenzbilder entscheiden, wann es fertig ist.

Die Staffelung ist bewusst. Eine kinematische Vorschau (Objekte folgen der Wellenoberfläche ohne volle Kraftsimulation) kommt zuerst, sodass Artists Meshes ablegen und ein Meer bevölkern können, während der schwere Solver noch gehärtet wird; du spürst das Ergebnis lange, bevor die Physik final ist. Der volle Solver, der Auto-Proxy und das komplette Panel folgen. Fortschritt und Meilensteine erscheinen auf der öffentlichen Roadmap, nicht in einer Launch-Day-Überraschung.

Das Toolkit, an dessen Seite es ausgeliefert wird (Scatter, Mesh Blending, Grids, Messen), ist heute kostenlos ausprobierbar. Wenn du benachrichtigt werden willst, sobald ein öffentlicher Wasser-Build existiert, ist der von der Seite verlinkte Discord der Ort, wo es zuerst angekündigt wird, und wo die Referenzbild-Bestanden/Nichtbestanden-Vergleiche gepostet werden, sobald sie passieren.

Mini-FAQ

Wird es Numivos andere Tools voraussetzen? Nein, es ist eine Erweiterung derselben Familie, dafür ausgelegt, allein zu stehen. Es teilt aber dasselbe Prinzip: Ergebnisse backen zu Engine-nativen Daten, wo physikalisch möglich, sodass dir gehört, was du machst.

Welche Engine-Versionen? Aktuelle Unreal-Engine-5-Releases. Details landen auf der Roadmap, wenn sich die Erweiterung einem öffentlichen Build nähert, statt jetzt versprochen und später revidiert zu werden.

Wie unterscheidet sich das vom eingebauten Wasser der Engine? Eingebaute Wassersysteme sind stark beim Look und schwach bei allgemeiner Interaktion: Auftrieb ist typischerweise eine separate, von Hand getunte Komponente. Der ganze Punkt hier ist, dass Look und Verhalten aus einem physikalisch fundierten System kommen, wobei das Referenzfoto-Gate den Look über alle Beleuchtungen hinweg ehrlich hält.

Warum vor der Veröffentlichung ankündigen? Weil die Referenzfoto-Methode selbst der Punkt ist. Wir zeigen lieber die Latte öffentlich und lassen uns daran messen, als eine fertige Sache zu enthüllen, die niemand hätte prüfen können. Dieser Beitrag ist diese Latte, schriftlich: nagle uns darauf fest.