Celem jest wykonanie 10 sekund bardzo szczegółowej symulacji płynów w celu uzyskania zbliżenia przy 60 klatkach na sekundę.

Po spędzeniu około dnia na eksperymentowaniu i porównywaniu MantaFlow z Flip Fluis wybrałem ten drugi, ponieważ MantaFlow zachowuje się bardzo nieprzewidywalnie, w zależności od rozdzielczości.

Obliczyłem, że woda dotrze do powierzchni basenu w 50 klatkach + potrzeba 10 sekund samej animacji przy 60 fps, co daje symulację 650 klatek przy rozdzielczości 150 milionów wokseli. Ta symulacja na Ryzen 3700x trwała 5 dni.

Dalej okazało się, że blender zawiesza się w renderowaniu, jeśli geometria w FlipFluids jest zbyt wielokątna. Naprawdę nie chciałem ponownie przeprowadzać symulacji w niższej rozdzielczości i ponownie czekać kilka dni. Spędziłem kilka dni szukając rozwiązania problemu, a nawet zacząłem myśleć o powrocie do MantaFlow.

Zmieniłem konfigurację sceny z Cycles na Octane Render, problem nadal występował, więc zdecydowałem się wrócić do Cycles.

Ogólnie Blender bardzo dobrze radzi sobie z dużą liczbą wielokątów, problem dotyczy geometrii FlipFluids. Twórcy dodatków przyznają się do problemu na swoim GitHubie i piszą, że leży on po stronie Blendera, ponieważ nie działa dobrze z geometrią HighPoly wykonaną w Pythonie lub czymś podobnym.

Postanowiłem spróbować wyeksportować geometrię do Alembica, aby móc ją później zaimportować z powrotem, więc nie powinno być z nią żadnych problemów. Próbowałem eksportować na różne sposoby, ale zawsze kończyło się to awarią blendera. Jeden eksport trwał nawet dłużej niż jeden dzień.

Następnie na amerykańskim forum znalazłem rozwiązanie gdzie było powiedziane, że w geometrii przed eksportem wystarczy zamienić modyfikatory i odłożyć modyfikator Smooth, po czym geometria FlipFluids została szybko wyeksportowana do Alembica. Zadziałało. Wyeksportowałem geometrię do Alembic, ukryłem oryginalną geometrię FlipFluids przed renderowaniem i rzutnią, ale pozostawiłem bąbelki i piankę i zaimportowałem geometrię Alembic.

Byłem mile zaskoczony, że geometria Alembic zachowała informacje o prędkości, a MotionBlur na wodzie działał poprawnie, a scena nie powodowała już awarii. Dokładniej, nie wystartowało od razu, ale nieco później.

Uruchomiłem render, zawiesił się dopiero następnego dnia, po około stu klatkach. To normalne, możesz żyć, właśnie uruchomiłem ponownie renderowanie od miejsca, w którym się zatrzymało.

W miejscu kontaktu strumienia z powierzchnią wody ciecz wygląda na ciemną. Wcale nie jest to „błękitna laguna”. Problemem są ograniczenia technologii PathTracing. W tym miejscu pojawia się ogromna ilość odbić i załamań od powierzchni wody oraz bąbelków, a renderer liczy maksymalnie 12 odbić, po czym rysuje czerń. Można oczywiście ustawić nie 12, ale 128, 1024 itd., ale wtedy na efekt renderowania będziemy czekać miesiącami. Dlatego do bąbelków dodałem turkusowy blask, a do samej wody 10 razy mniej tego samego blasku. Ościeżnica zniknęła, czas renderowania się nie zmienił. Renderuję od początku. Jednocześnie zdecydowałem się zacząć nie od klatki 50, a od klatki 100, gdzie wibracje są już widoczne na powierzchni wody. Dodałem też jasności do źródeł światła i trochę mgły do wody.

Po pewnym czasie testów zauważyłem, że w Blenderze 3.5 scena zachowuje się znacznie stabilniej niż w wersji 3.6, dlatego zdecydowałem się kontynuować w niej pracę. Trzeba było przekonfigurować materiały z kartą Mix, bo w wersji 3.6 działa to inaczej i pierwsze klatki trzeba będzie wyrenderować na nowo, bo teraz niektóre materiały wyglądają trochę inaczej.

Następnego dnia później obejrzałem pierwsze sekundy powstałej animacji i zauważyłem, że rośliny nie kołysały się na wietrze tak, jak planowałem, nie było tekstur na gałęziach i brakowało trawy. Problem w tym, że projekt robiłem na laptopie, a symulację i rendering na PC, a na PC na wersji 3.5 była stara wersja dodatków wegetacyjnych. Zainstalowano ponownie dodatek do roślinności, ponownie skonfigurowano roślinność. Zainstalowałem ponownie wtyczkę dla trawy, ponownie skonfigurowałem trawę. Ustawiłem ponownie renderowanie animacji.

Odkryłem program Batch Render Creator, dzięki niemu liczba awarii podczas renderowania spadła jeszcze bardziej.

Samoświecenie pod tym kątem, w pobliżu ciemnej szczeliny, z której wypływa woda, nie wygląda zbyt dobrze. Niestety blender nie posiada mapy Distance, która jest dostępna w 3ds Max i Corona, więc trzeba będzie wyrenderować wersję bez samoświecenia jeszcze raz i zmiksować je w AfterEffecs, żeby nie było samoświecenia w obszarze ​lukę, ale jest ona w innych miejscach.

Były też inne problemy, na przykład z pozycją kamery, ponieważ przesunąłem początek animacji z klatki 50 na klatkę 100, a także musiałem część z niej wyrenderować. Musiałem także majstrować przy węzłach geometrii, aby odciąć dno w pobliżu wody, ponieważ nie przeprowadziłem symulacji dla całej głębokości basenu.

W odpowiedzi na potencjalnych krytyków, którzy nigdy czegoś takiego nie robili, ale uważają, że w Houdinim lub PhoenixFD jest mniej problemów i wszystko można zrobić szybciej, sugeruję najpierw wykonanie symulacji ponad 150 milionów wokseli i wyrenderowanie jej na GPU wraz z z animowaną roślinnością i przemieszczeniem, a następnie napisz, ile czasu Ci to zajęło i jakie niuanse i niezgodności napotkałeś.