Målet er å lage 10 sekunder med svært detaljert væskesimulering for et nærbilde med 60 bilder per sekund.

Etter å ha brukt omtrent en dag på å eksperimentere og sammenligne MantaFlow med Flip Fluis, valgte jeg sistnevnte, da MantaFlow oppfører seg veldig uforutsigbart, avhengig av oppløsningen.

Jeg regnet med at vannet ville nå overflaten av bassenget i 50 bilder + du trenger 10 sekunder av selve animasjonen ved 60 fps, noe som resulterer i en simulering på 650 bilder med en oppløsning på 150 millioner voksler. Denne simuleringen på Ryzen 3700x tok 5 dager.

Videre viste det seg at blenderen krasjer i gjengivelsen hvis geometrien i FlipFluids er for høy polygonal. Jeg ville virkelig ikke gjøre simuleringen igjen med en lavere oppløsning og vente flere dager igjen. Jeg brukte et par dager på å lete etter en løsning på problemet, og begynte til og med å tenke på å gå tilbake til MantaFlow.

Jeg rekonfigurerte scenen fra Cycles til Octane Render, problemet vedvarte, så jeg bestemte meg for å gå tilbake til Cycles.

Blender, generelt, håndterer et stort antall polygoner veldig bra, problemet er med FlipFluids-geometrien. Tilleggsutviklerne innrømmer problemet på GitHub og skriver at det er på Blender-siden da det ikke fungerer bra med HighPoly-geometri laget i Python eller noe sånt.

Jeg bestemte meg for å prøve å eksportere geometrien til Alembic slik at jeg kunne importere den tilbake, så det skulle ikke være noen problemer med den. Jeg prøvde å eksportere på forskjellige måter, men det endte alltid med at blenderen krasjet. En eksport tok til og med mer enn en dag.

Så på et amerikansk forum fant jeg en løsning der det ble sagt at i geometrien før eksport trenger du bare å bytte modifikatorer og legge ned Smooth-modifikatoren, hvoretter FlipFluids-geometrien raskt ble eksportert til Alembic. Det funket. Jeg eksporterte geometrien til Alembic, gjemte den originale FlipFluids-geometrien fra gjengivelsen og viewporten, men lot boblene og skummet stå og importerte Alembic-geometrien.

Jeg ble positivt overrasket over at Alembic-geometrien beholdt hastighetsinformasjonen og MotionBlur på vannet fungerte riktig og scenen krasjet ikke lenger. Mer presist, det tok ikke av umiddelbart, men litt senere.

Jeg startet gjengivelsen, den krasjet først neste dag, etter omtrent hundre bilder. Det er normalt, du kan leve, jeg har nettopp startet gjengivelsen på nytt fra der den stoppet.

Ved kontaktpunktet mellom strålen og overflaten av vannet ser væsken mørk ut. Ikke en "blå lagune" i det hele tatt. Problemet er begrensningene til PathTracing-teknologien. På dette stedet er det et stort antall refleksjoner og brytninger fra overflaten av vann og bobler, og gjengiveren teller maksimalt 12 refleksjoner, og tegner deretter svarthet. Du kan selvfølgelig ikke angi 12, men 128, 1024 osv., men da venter vi måneder på gjengivelsesresultatet. Derfor tilsatte jeg turkis selvglød til boblene og 10 ganger mindre av samme selvglød til selve vannet. Jamben er borte, gjengivelsestiden er ikke endret. Jeg gjengir fra begynnelsen. Samtidig bestemte jeg meg for å ikke starte fra ramme 50, men fra ramme 100, der vibrasjoner allerede er synlige på overflaten av vannet. Jeg la også lysstyrke til lyskildene og litt tåke til vannet.

Etter en tid med testing la jeg merke til at i Blender 3.5 oppfører scenen seg mye mer stabilt enn i versjon 3.6, så jeg bestemte meg for å fortsette å jobbe i den. Materialer med Mix-kortet måtte konfigureres på nytt, fordi i versjon 3.6 fungerer det annerledes, og de første rammene må gjengis på nytt, for nå ser noen materialer litt annerledes ut.

En annen dag senere så jeg på de første sekundene av den resulterende animasjonen og la merke til at plantene ikke svaiet i vinden slik jeg hadde planlagt, det var ingen tekstur på grenene og gresset manglet. Problemet er at jeg gjorde prosjektet på en bærbar datamaskin, og simuleringen og gjengivelsen på en PC, og på PC-en på versjon 3.5, var det en gammel versjon av vegetasjonstillegg. Installerte vegetasjonstillegget på nytt, rekonfigurerte vegetasjonen. Installerte plugin for gress på nytt, rekonfigurerte gresset. Jeg satte animasjonen til å gjengis på nytt.

Jeg oppdaget Batch Render Creator-programmet, takket være det reduserte antallet krasj under gjengivelsen enda mer.

Selvgløden fra denne vinkelen, nær den mørke sprekken der vannet renner ut, ser ikke veldig bra ut. Dessverre har ikke blender et avstandskart, som er tilgjengelig i 3ds Max og Corona, så du må gjengi versjonen uten selvglød igjen og blande dem i AfterEffecs slik at det ikke er selvglød i området gapet, men det er andre steder.

Det var også andre problemer, for eksempel med kameraposisjonen, fordi jeg flyttet starten av animasjonen fra bilde 50 til bilde 100, og jeg måtte også gjengi noe av det. Og jeg måtte tukle med Geometry Nodes for å kutte av bunnen nær vannet, siden jeg ikke gjorde simuleringen for hele dybden av bassenget.

Som svar på potensielle kritikere som aldri har gjort noe lignende, men som tror at i Houdini eller PhoenixFD er det færre problemer og alt kan gjøres raskere, foreslår jeg at du først lager en 150+ millioner voxel-simulering og gjengir den på GPU-en sammen med animert vegetasjon og forskyvning, og skriv så ned hvor lang tid det tok deg og hvilke nyanser og inkompatibiliteter du møtte.