W skrócie: Budujemy system wody dla Unreal Engine z dwiema obietnicami: woda, która wygląda właściwie, bo światło, kolor i piana są liczone fizycznie (a nie strojone ręcznie per scena) oraz woda, która się zachowuje: upuść dowolny mesh na powierzchnię, a poprawnie zapływa, przechyli się lub zatonie, bez żadnej konfiguracji. Jest w aktywnym rozwoju. Ten wpis wyjaśnia, co obejmuje, jak rozliczamy się fotografiami referencyjnymi, dlaczego pływalność to trudna część, którą wszyscy pomijają, i gdzie mieści się obok reszty zestawu narzędzi.
Poprzeczka do pobicia. Zauważ, co czyni to prawdziwym: piana zrodzona z załamujących się fal, mgła zjadająca klify, statystyka białych grzyw na całej fali, nic nie umieszczone ręcznie, wszystko fizyka. To poprzeczka, którą postawiliśmy.
Po co kolejny system wody?
Większość wody w grach wygląda świetnie w dokładnie jednym warunku oświetleniowym, tym ze zrzutu ekranu w sklepie. Przesuń słońce, przełącz na pochmurno, ustaw kamerę do połowy pod linią wody, i się rozpada.
Jest druga, cichsza porażka, która liczy się tak samo: niemal każdy system wody traktuje pływające obiekty jako coś dodatkowego. Dostajesz szablon łodzi, stronę instrukcji montażu pontonów i niewypowiedziane założenie, że nikt nigdy nie wrzuci przypadkowej skrzyni do morza. Gracze wrzucają skrzynie do morza bez przerwy.
Chcieliśmy dwóch rzeczy, które obecnie nie współistnieją w jednym pakiecie: wyglądu w jakości filmowej, który przetrwa każde oświetlenie, i fizycznego zachowania, które nie wymaga żadnej konfiguracji. Żadnego z nich nie osiągniesz, kręcąc parametrami, aż zrzut ładnie wygląda, bo zrzut to pojedyncza klatka pod pojedynczym słońcem, a gdy tylko któreś się zmieni, woda strojona pod gust pokazuje swoje szwy. Fundamentem projektu nie jest więc lista funkcji. To test akceptacyjny, z którym człowiek nie może się spierać: fotografia.
Oceniana względem zdjęć, nie względem gustu
Rozwój jest bramkowany fotografiami referencyjnymi ze stałymi kontraktami kamery i oświetlenia, fizyczne jednostki światła, zablokowany tonemapper i percepcyjna metryka różnicy decydująca o zaliczeniu lub niezaliczeniu, a nie nastrój art directora danego dnia.
Dwie referencje są kanoniczne i wybrano je tak, by były przeciwieństwami:
- Czyste jezioro, kamera w linii wody. Pół powietrza, pół wody, falista granica bez pasma artefaktów; zielonkawa woda typu przybrzeżnego, której kolor pogłębia się z odległością; kaustyki na skałach zgodne z powierzchnią nad nimi; zatopione kłody poprawnie załamujące się na granicy. Ta testuje refrakcję, przekroczenie linii wody i podwodną absorpcję koloru, wszystko naraz.
- Sztormowy brzeg pod pełnym zachmurzeniem. Bez słońca, bez pasma połysku: morze musi czytać się przez miękkie odbicie nieba, odbarwioną szarozieleń, statystykę białych grzyw i mgłę nad klifami. Boja jedzie falą z wiarygodnym okresem i przechyłem; zachowanie jest częścią akceptacji, nie tylko nieruchomy obraz.
Referencja pochmurna jest celowo jedną z dwóch. Nasłoneczniona woda schlebia każdemu rendererowi na Ziemi, lśnienie spekularne kryje mnóstwo grzechów. Zabierz słońce, a woda musi udźwignąć kadr samą szorstkością odbić, kolorem i ruchem. To uczciwy test, i to ten, którego większość systemów po cichu unika. Ocean, który wygląda dobrze tylko w słońcu, nie wychodzi.
Strona kamery jest wyspecyfikowana równie rygorystycznie jak strona wody, bo porównanie zdjęć jest uczciwe tylko wtedy, gdy kamera nie może oszukiwać. To oznacza prawdziwe fizyczne natężenia światła (słońce w południe około 100 000 luksów, nie arbitralny suwak jasności), stałą ekspozycję i stałą konfigurację tonemappingu i bloomu per referencja. Zmień tonemapper, a każdą wodę można dopasować do każdego zdjęcia, i właśnie dlatego tonemapper przybija się jako pierwszy.
Drop-a-Mesh: pływanie bez zadania domowego
Przeciągnij dowolny mesh na zbiornik wody Numivo, a od razu zachowuje się poprawnie, system automatycznie buduje proxy fizyki, liczy wyparte objętości na klatkę z rzeczywistej wysokości fali i wyprowadza pływa-czy-tonie z rzeczywistej gęstości.
Pod wodą to miejsce, nie postproces. Kolor absorbuje się z głębokością, światło filtruje w dół smugami, a granica nad głową musi być przekroczona czysto, referencja jeziora istnieje, by trzymać wszystkie trzy uczciwe naraz.
Kłoda pływa i obraca się na swój długi bok. Skrzynia kołysze się. Kamienny posąg tonie. Bez montażu, bez rozmieszczania pontonów, bez skryptów. Pod maską:
- kształt kolizji jest automatycznie woksuelizowany (asynchronicznie i buforowany per asset, więc dzieje się to tylko raz), by zmierzyć rzeczywistą objętość obiektu;
- pływalność liczona jest fizycznie co klatkę z wypartej objętości względem gęstości wody, a woda słodka i słona naprawdę się różnią (woda słona jest gęstsza, więc ta sama skrzynia jedzie wyżej w morzu niż w jeziorze);
- pływa-czy-tonie wynika z gęstości, masa podzielona przez objętość proxy: nie ma domyślnego pola „czy to powinno pływać?", bo domyślnie jest to fizyka;
- stabilność wyłania się z tego, jak rozłożona jest objętość proxy: skrzynie z ciężarem u góry się wywracają, kadłuby z balastem w stępce się prostują, deska leży płasko;
- pływające obiekty sprzęgają się z powrotem z powierzchnią: zmarszczki, kilwatery, pierścień piany na linii wody i efekty rozprysku przy uderzeniu.
Jest mały panel na aktorze do nadpisań (wymuś pływanie, wymuś tonięcie, suwak tłumienia, przełączniki kilwateru i rozprysku), ale nadpisanie skaluje fizykę, a nie ją zastępuje. Wymuś pływanie głazu, a i tak kołysze się z właściwym okresem i zostawia właściwy kilwater; zachowuje się tylko tak, jakby był lżejszy. To rozróżnienie się liczy: wymuszone wyniki ignorujące solver wyglądają jak propy przyklejone do płaszczyzny, a gracze zauważają to natychmiast.
Cel projektowy jest bezceremonialny i jest to demo, które chcemy móc uruchamiać na żywo: ktoś przeciąga dwadzieścia losowych propów na morze i wszystko po prostu się zachowuje, bez otwierania najpierw ani jednego okna ustawień. Jeśli to demo potrzebuje tutoriala, funkcja zawiodła.
Co obejmuje
Woda przybrzeżna, otwarty ocean, pod wodą i jaskiniowe rozlewiska są wszystkie pierwszoklasowe, fale oparte na widmie z osobną falą długą i morzem krzyżowym, piana z naprawdę załamujących się fal, kaustyki napędzające podwodne smugi światła i stabilność pod efektami filmowymi.
Szczegóły, które się liczą, jeśli zależy ci na wodzie:
- Fale pochodzą z widm oceanograficznych (tych samych modeli statystycznych używanych do opisu prawdziwych mórz), z rozproszeniem kierunkowym i niezależnie sterowaną falą długą. Stan morza staje się decyzją pogodową, „nadciągający sztorm, długa fala z zachodu", zamiast trzydziestu niepowiązanych suwaków, którymi kręcisz, aż wygląda burzowo.
- Piana to nie namalowana maska. Powstaje tam, gdzie fale naprawdę się załamują, starzeje się z czasem i smuży pod wiatrem. Malowana piana to najczęstszy znak fałszywej wody, bo nie porusza się z fizyką, którą ma reprezentować.
- Pod wodą to prawdziwe miejsce. Poprawna absorpcja koloru wg głębokości (czerwony odchodzi pierwszy, potem zielony, zostawiając głęboki błękit, który wszyscy znają z nagrań nurkowych), smugi światła wyprowadzone z tego samego pola kaustyki, które oświetla dno, i przekroczenie na linii wody bez klasycznego twardego pasma artefaktu.
- Jaskiniowe rozlewiska mają własne potraktowanie (woda stojąca lub ledwo ruchoma, zaburzenia od kropli, odbicia w niemal ciemności), bo spokojne rozlewisko wnętrza obnaża inne błędy niż otwarty ocean.
- Cinematiki to kryteria akceptacji, nie coś dodatkowego. Powierzchnia musi pozostać stabilna pod głębią ostrości, rozmyciem ruchu i ziarnem filmowym, bez spekularnych fireflies pojawiających się dopiero po nałożeniu ziarna, bez migotania, które wolna kamera zmienia w stroboskop.
Dlaczego pływalność to część, którą wszyscy pomijają
Wygląd można podrobić dobrym shaderem, ale zachowania nie, przekonujące pływanie-i- tonięcie potrzebuje szacunku objętości w czasie rzeczywistym i stabilnego solvera, co jest naprawdę trudne, więc większość systemów wydaje prefab łodzi i kończy.
Niewygodna prawda inżynierska jest taka, że piękny shader wody to rozwiązany problem, a ogólny solver pływalności nie. Podrobienie wyglądu fali to problem tekstury i normalnych; sprawienie, by dowolny, nigdy wcześniej niewidziany mesh usiadł poprawnie w tej fali, to problem fizyki, który musi działać z prędkością klatek, przetrwać szybkie kroki czasu i nie wybuchnąć, gdy skała z tysiąca trójkątów spotka sztormową falę długą. Ta luka to powód, dla którego „woda" w większości silników znaczy „ładna płaszczyzna, z którą nie da się wchodzić w interakcję", i dlaczego część interaktywna, gdy istnieje, jest ręcznie zrobioną łodzią.
Zamknięcie tej luki (uczynienie zachowania równie automatycznym jak wygląd) jest powodem istnienia tego projektu i powodem, dla którego wymaga dyscypliny fotografii referencyjnej plus prawdziwego solvera, a nie weekendu pracy nad shaderem.
Kiedy będziesz mógł go użyć?
Jest w rozwoju jako rozszerzenie Unreal Engine, z etapowym wdrożeniem, kinematyczny podgląd pływania pojawia się przed pełnym solverem fizyki, by sceny można było zaludniać wcześnie. Nie ogłaszamy daty; obrazy referencyjne decydują, kiedy jest gotowe.
Etapowanie jest celowe. Kinematyczny podgląd (obiekty podążają za powierzchnią fali bez pełnej symulacji sił) pojawia się pierwszy, by artyści mogli upuszczać meshe i zaludniać morze, gdy ciężki solver jest jeszcze utwardzany. Czujesz wynik na długo przed finalizacją fizyki. Pełny solver, auto-proxy i kompletny panel następują potem. Postęp i kamienie milowe pojawiają się na publicznej roadmapie, nie w niespodziance dnia premiery.
Zestaw, obok którego wyjdzie (scatter, mesh blending, gridy, pomiary) jest darmowy do wypróbowania dziś. Jeśli chcesz otrzymać powiadomienie w chwili, gdy istnieje publiczny build wody, Discord podlinkowany ze strony to miejsce, gdzie zostanie ogłoszony jako pierwszy, i gdzie porównania zaliczone/niezaliczone obrazów referencyjnych będą publikowane na bieżąco.
Mini-FAQ
Czy będzie wymagać innych narzędzi Numivo? Nie, to rozszerzenie z tej samej rodziny, zaprojektowane, by stać samodzielnie. Dzieli jednak tę samą zasadę: wyniki zapiekają się do danych natywnych silnika wszędzie, gdzie fizycznie możliwe, więc jesteś właścicielem tego, co robisz.
Które wersje silnika? Aktualne wydania Unreal Engine 5. Szczegóły lądują na roadmapie, w miarę jak rozszerzenie zbliża się do publicznego builda, zamiast być obiecywane teraz i rewidowane później.
Czym różni się to od wbudowanej wody silnika? Wbudowane systemy wody są mocne w wyglądzie i słabe w ogólnej interakcji, pływalność to zwykle osobny, ręcznie strojony komponent. Cały sens tutaj jest taki, że wygląd i zachowanie pochodzą z jednego fizycznie ugruntowanego systemu, a bramka fotografii referencyjnej trzyma wygląd uczciwym w różnych oświetleniach.
Po co ogłaszać przed premierą? Bo metoda fotografii referencyjnej sama jest sednem. Wolimy publicznie pokazać poprzeczkę i dać się względem niej mierzyć niż ujawnić skończoną rzecz, której nikt nie mógłby prześwietlić. Ten wpis to ta poprzeczka, na piśmie, rozliczcie nas z niej.
