Målet er at lave 10 sekunders meget detaljeret væskesimulering til et nærbillede med 60 billeder i sekundet.

Efter at have brugt omkring en dag på at eksperimentere og sammenligne MantaFlow med Flip Fluis, valgte jeg det sidste, da MantaFlow opfører sig meget uforudsigeligt, afhængig af opløsningen.

Jeg regnede med, at vandet ville nå overfladen af poolen i 50 billeder + du skal bruge 10 sekunder af selve animationen ved 60fps, hvilket resulterer i en simulering af 650 billeder med en opløsning på 150 millioner voxels. Denne simulering på Ryzen 3700x tog 5 dage.

Ydermere viste det sig, at blenderen styrter i renderingen, hvis geometrien i FlipFluids er for høj polygonal. Jeg ville virkelig ikke lave simuleringen igen med en lavere opløsning og vente flere dage igen. Jeg brugte et par dage på at lede efter en løsning på problemet, og begyndte endda at tænke på at vende tilbage til MantaFlow.

Jeg omkonfigurerede scenen fra Cycles til Octane Render, problemet fortsatte, så jeg besluttede at vende tilbage til Cycles.

Blender håndterer generelt et stort antal polygoner meget godt, problemet er med FlipFluids-geometrien. Addon-udviklerne indrømmer problemet på deres GitHub og skriver, at det er på Blender-siden, da det ikke fungerer godt med HighPoly-geometri lavet i Python eller sådan noget.

Jeg besluttede at prøve at eksportere geometrien til Alembic, så jeg derefter kunne importere den tilbage, så der skulle ikke være nogen problemer med den. Jeg forsøgte at eksportere på forskellige måder, men det endte altid med, at blenderen styrtede. En eksport tog endda mere end en dag.

Så fandt jeg på et amerikansk forum en løsning, hvor det blev sagt, at man i geometrien inden eksport bare skulle bytte modifikatorerne og sætte Smooth modifieren ned, hvorefter FlipFluids-geometrien hurtigt blev eksporteret til Alembic. Det virkede. Jeg eksporterede geometrien til Alembic, gemte den originale FlipFluids-geometri fra gengivelsen og viewporten, men efterlod boblerne og skummet og importerede Alembic-geometrien.

Jeg var glædeligt overrasket over, at Alembic-geometrien beholdt hastighedsinformationen, og MotionBlur på vandet fungerede korrekt, og scenen styrtede ikke længere ned. Mere præcist tog det ikke fart med det samme, men lidt senere.

Jeg lancerede renderingen, den styrtede først ned næste dag efter omkring hundrede billeder. Det er normalt, du kan leve, jeg har lige genstartet gengivelsen, hvor den stoppede.

I det punkt, hvor strålen er i kontakt med vandoverfladen, ser væsken mørk ud. Slet ikke en "blå lagune". Problemet er PathTracing-teknologiens begrænsninger. På dette sted er der et stort antal refleksioner og brydninger fra vandoverfladen og bobler, og rendereren tæller maksimalt 12 refleksioner og tegner derefter sort. Du kan selvfølgelig ikke sætte 12, men 128, 1024 osv., men så venter vi måneder på gengivelsesresultatet. Derfor tilføjede jeg turkis selvglød til boblerne og 10 gange mindre af samme selvglød til selve vandet. Jamben er væk, gengivelsestiden er ikke ændret. Jeg gengiver fra begyndelsen. Samtidig besluttede jeg at starte ikke fra ramme 50, men fra ramme 100, hvor vibrationer allerede er synlige på vandoverfladen. Jeg tilføjede også lysstyrke til lyskilderne og lidt tåge til vandet.

Efter nogen tids test bemærkede jeg, at i Blender 3.5 opfører scenen sig meget mere stabilt end i version 3.6, så jeg besluttede at fortsætte med at arbejde i den. Materialer med Mix-kortet skulle omkonfigureres, for i version 3.6 fungerer det anderledes, og de første rammer skal gengives igen, for nu ser nogle materialer lidt anderledes ud.

En anden dag senere kiggede jeg på de første sekunder af den resulterende animation og bemærkede, at planterne ikke svajede i vinden, som jeg havde planlagt, der var ingen tekstur på grenene, og græsset manglede. Problemet er, at jeg lavede projektet på en bærbar computer, og simuleringen og gengivelsen på en pc, og på pc'en i version 3.5, var der en gammel version af vegetationstilføjelser. Geninstallerede vegetationstilføjelsen, omkonfigurerede vegetationen. Geninstallerede plugin'et til græs, omkonfigurerede græsset. Jeg indstillede animationen til at blive gengivet igen.

Jeg opdagede Batch Render Creator-programmet, takket være det faldt antallet af nedbrud under gengivelsen endnu mere.

Selvgløden fra denne vinkel, nær den mørke revne, hvor vandet strømmer ud, ser ikke særlig godt ud. Desværre har blenderen ikke et Distance-kort, som fås i 3ds Max og Corona, så du bliver nødt til at rendere versionen uden selvglød igen og blande dem i AfterEffecs, så der ikke er selvglød i området ved ​kløften, men der er andre steder.

Der var også andre problemer, for eksempel med kamerapositionen, fordi jeg flyttede starten af animationen fra frame 50 til frame 100, og jeg var også nødt til at gengive noget af det. Og jeg var nødt til at pille ved Geometry Nodes for at afskære bunden nær vandet, da jeg ikke lavede simuleringen for hele bassinets dybde.

Som svar på potentielle kritikere, der aldrig har gjort noget lignende, men mener, at der i Houdini eller PhoenixFD er færre problemer, og alt kan gøres hurtigere, foreslår jeg, at du først laver en 150+ millioner voxelsimulering og gengiver den på GPU'en med animeret vegetation og forskydning, og skriv derefter ned, hvor lang tid det tog dig, og hvilke nuancer og uforeneligheder du stødte på.