Målet är att göra 10 sekunders mycket detaljerad vätskesimulering för en närbild med 60 bilder per sekund.

Efter att ha tillbringat ungefär en dag med att experimentera och jämföra MantaFlow med Flip Fluis valde jag det senare, eftersom MantaFlow beter sig väldigt oförutsägbart, beroende på upplösningen.

Jag räknade med att vattnet skulle nå poolens yta på 50 bildrutor + du behöver 10 sekunder av själva animeringen vid 60fps, vilket resulterar i en simulering av 650 bildrutor med en upplösning på 150 miljoner voxlar. Denna simulering på Ryzen 3700x tog 5 dagar.

Vidare visade det sig att mixern kraschar i renderingen om geometrin i FlipFluids är för hög polygonal. Jag ville verkligen inte göra simuleringen igen med en lägre upplösning och vänta flera dagar igen. Jag tillbringade ett par dagar med att leta efter en lösning på problemet och började till och med fundera på att återvända till MantaFlow.

Jag konfigurerade om scenen från Cycles till Octane Render, problemet kvarstod, så jag bestämde mig för att återgå till Cycles.

Blender, i allmänhet, hanterar ett stort antal polygoner mycket bra, problemet är med FlipFluids-geometrin. Tilläggsutvecklarna erkänner problemet på sin GitHub och skriver att det är på Blendersidan då det inte fungerar bra med HighPoly-geometri gjord i Python eller något liknande.

Jag bestämde mig för att försöka exportera geometrin till Alembic så att jag sedan kunde importera tillbaka den, så det borde inte vara några problem med det. Jag försökte exportera på olika sätt, men det slutade alltid med att mixern kraschade. En export tog till och med mer än en dag.

Sen på ett amerikanskt forum hittade jag en lösning där det stod att man i geometrin innan man exporterar behöver bara byta modifierare och lägga ner Smooth-modifieraren, varefter FlipFluids-geometrin snabbt exporterades till Alembic. Det fungerade. Jag exporterade geometrin till Alembic, gömde den ursprungliga FlipFluids-geometrin från renderingen och viewporten, men lämnade bubblorna och skummet och importerade Alembic-geometrin.

Jag blev positivt överraskad över att Alembic-geometrin behöll hastighetsinformationen och MotionBlur på vattnet fungerade korrekt och scenen kraschade inte längre. Mer exakt, det tog inte fart direkt, utan lite senare.

Jag startade renderingen, den kraschade först nästa dag, efter ungefär hundra bilder. Det är normalt, du kan leva, jag startade precis om renderingen där den slutade.

Vid kontaktpunkten för strålen med vattenytan ser vätskan mörk ut. Inte en "blå lagun" alls. Problemet är PathTracing-teknikens begränsningar. På denna plats finns det ett stort antal reflektioner och brytningar från vattenytan och bubblor, och renderaren räknar maximalt 12 reflektioner och drar sedan svärta. Du kan naturligtvis inte ställa in 12, utan 128, 1024, etc., men sedan väntar vi månader på renderingsresultatet. Därför tillsatte jag turkos självglöd till bubblorna och 10 gånger mindre av samma självglöd till själva vattnet. Jamben är borta, renderingstiden har inte ändrats. Jag renderar från början. Samtidigt bestämde jag mig för att inte börja från ram 50, utan från ram 100, där vibrationer redan är synliga på vattenytan. Jag lade också till ljusstyrka till ljuskällorna och lite dimma till vattnet.

Efter en tid av testning märkte jag att scenen i Blender 3.5 beter sig mycket stabilare än i version 3.6, så jag bestämde mig för att fortsätta arbeta i den. Material med Mix-kortet var tvungna att konfigureras om, eftersom det i version 3.6 fungerar annorlunda, och de första ramarna kommer att behöva renderas om, för nu ser vissa material lite annorlunda ut.

Ytterligare en dag senare tittade jag på de första sekunderna av den resulterande animationen och märkte att plantorna inte vajade i vinden som jag hade planerat, det fanns ingen struktur på grenarna och gräset saknades. Problemet är att jag gjorde projektet på en bärbar dator, och simuleringen och renderingen på en PC, och på PC:n på version 3.5, fanns det en gammal version av vegetationstillägg. Installerade om vegetationstillägget, konfigurerade om vegetationen. Installerade om plugin för gräs, konfigurerade om gräset. Jag ställde in animationen för att renderas igen.

Jag upptäckte programmet Batch Render Creator, tack vare det minskade antalet krascher under renderingen ännu mer.

Självglöden från denna vinkel, nära den mörka sprickan där vattnet rinner ut, ser inte särskilt bra ut. Tyvärr har blender ingen Distance-karta, som finns i 3ds Max och Corona, så du måste rendera versionen utan självglöd igen och blanda in dem i AfterEffecs så att det inte finns någon självglöd i området gapet, men det finns på andra ställen.

Det fanns också andra problem, till exempel med kamerapositionen, eftersom jag flyttade början av animationen från bildruta 50 till bildruta 100, och jag var också tvungen att återrendera en del av den. Och jag var tvungen att mixtra med Geometry Nodes för att skära av botten nära vattnet, eftersom jag inte gjorde simuleringen för hela poolens djup.

Som svar på potentiella kritiker som aldrig har gjort något liknande, men tror att i Houdini eller PhoenixFD finns det färre problem och allt kan göras snabbare, föreslår jag att du först gör en 150+ miljoner voxelsimulering och renderar den på GPU:n. med animerad vegetation och förskjutning, och skriv sedan ner hur lång tid det tog dig och vilka nyanser och inkompatibiliteter du stött på.