Het doel is om 10 seconden zeer gedetailleerde vloeistofsimulatie te maken voor een close-up met 60 frames per seconde.

Na ongeveer een dag te hebben geëxperimenteerd en MantaFlow met Flip Fluis te hebben vergeleken, heb ik voor het laatste gekozen, omdat MantaFlow zich zeer onvoorspelbaar gedraagt, afhankelijk van de resolutie.

Ik dacht dat het water het oppervlak van het zwembad zou bereiken in 50 frames + je hebt 10 seconden van de animatie zelf nodig bij 60 fps, wat resulteert in een simulatie van 650 frames met een resolutie van 150 miljoen voxels. Deze simulatie op de Ryzen 3700x duurde 5 dagen.

Verder bleek dat de blender crasht in de render als de geometrie in FlipFluids te hoog polygonaal is. Ik wilde de simulatie echt niet opnieuw doen met een lagere resolutie en opnieuw een aantal dagen wachten. Ik heb een paar dagen gezocht naar een oplossing voor het probleem en begon er zelfs over na te denken om terug te keren naar MantaFlow.

Ik heb de scène opnieuw geconfigureerd van Cycles naar Octane Render, het probleem bleef bestaan, dus besloot ik terug te keren naar Cycles.

Blender kan over het algemeen heel goed met een groot aantal polygonen om, het probleem zit hem in de FlipFluids-geometrie. De add-on-ontwikkelaars geven het probleem op hun GitHub toe en schrijven dat het aan de Blender-kant ligt, omdat het niet goed werkt met HighPoly-geometrie gemaakt in Python of iets dergelijks.

Ik besloot te proberen de geometrie naar Alembic te exporteren, zodat ik deze vervolgens weer kon importeren, dus er zouden geen problemen mee moeten zijn. Ik heb op verschillende manieren geprobeerd te exporteren, maar het eindigde altijd met een crash van de blender. Eén export duurde zelfs meer dan een dag.

Toen vond ik op een Amerikaans forum een oplossing waarbij werd gezegd dat je in de geometrie voor het exporteren alleen maar de modifiers hoeft om te wisselen en de Smooth modifier neer te zetten, waarna de FlipFluids-geometrie snel naar Alembic werd geëxporteerd. Het werkte. Ik exporteerde de geometrie naar Alembic, verborg de originele FlipFluids-geometrie voor de render en viewport, maar liet de bubbels en het schuim achter en importeerde de Alembic-geometrie.

Ik was aangenaam verrast dat de Alembic-geometrie de snelheidsinformatie behield en MotionBlur op het water correct werkte en de scène niet langer crashte. Om precies te zijn, het ging niet onmiddellijk van start, maar iets later.

Ik startte de render, maar deze crashte pas de volgende dag, na ongeveer honderd frames. Het is normaal, je kunt leven, ik heb zojuist de weergave opnieuw gestart vanaf het punt waarop deze was gestopt.

Op het contactpunt van de straal met het wateroppervlak ziet de vloeistof er donker uit. Helemaal geen ‘blauwe lagune’. Het probleem zijn de beperkingen van PathTracing-technologie. Op deze plek is er een groot aantal reflecties en brekingen van het wateroppervlak en de bubbels, en de renderer telt maximaal 12 reflecties en tekent vervolgens zwartheid. Je kunt uiteraard niet 12 instellen, maar 128, 1024 etc., maar dan wachten we maanden op het renderresultaat. Daarom heb ik turquoise zelf-gloeiing aan de bubbels toegevoegd en 10 keer minder van dezelfde zelf-gloeiing aan het water zelf. De stijl is verdwenen, de rendertijd is niet veranderd. Ik render vanaf het begin. Tegelijkertijd besloot ik niet vanaf frame 50 te beginnen, maar vanaf frame 100, waar trillingen al zichtbaar zijn op het wateroppervlak. Ik heb ook helderheid toegevoegd aan de lichtbronnen en een beetje mist aan het water.

Na enige tijd testen merkte ik dat de scène zich in Blender 3.5 veel stabieler gedraagt dan in versie 3.6, dus besloot ik erin te blijven werken. Materialen met de Mix-kaart moesten opnieuw worden geconfigureerd, omdat het in versie 3.6 anders werkt, en de eerste frames zullen opnieuw moeten worden weergegeven, omdat sommige materialen er nu een beetje anders uitzien.

Nog een dag later bekeek ik de eerste seconden van de resulterende animatie en merkte dat de planten niet in de wind zwaaiden zoals ik had gepland, er zat geen textuur op de takken en het gras was verdwenen. Het probleem is dat ik het project op een laptop deed, en de simulatie en weergave op een pc, en op de pc in versie 3.5 was er een oude versie van vegetatie-add-ons. De vegetatie-add-on opnieuw geïnstalleerd, de vegetatie opnieuw geconfigureerd. De plug-in voor gras opnieuw geïnstalleerd, het gras opnieuw geconfigureerd. Ik heb ingesteld dat de animatie opnieuw moet worden weergegeven.

Ik ontdekte het programma Batch Render Creator, waardoor het aantal crashes tijdens het renderen nog verder afnam.

De zelfgloed vanuit deze hoek, vlakbij de donkere barst waar het water uitstroomt, ziet er niet erg goed uit. Helaas beschikt blender niet over een Distance map, die is wel beschikbaar in 3ds Max en Corona, dus je zult de versie zonder self-glow opnieuw moeten renderen en deze in AfterEffecs moeten mixen zodat er geen self-glow ontstaat op het gebied van ​de kloof, maar die is er ook op andere plaatsen.

Er waren ook andere problemen, bijvoorbeeld met de camerapositie, omdat ik het begin van de animatie verschoof van frame 50 naar frame 100, en ik moest er ook een deel van opnieuw renderen. En ik moest sleutelen aan Geometry Nodes om de bodem bij het water af te snijden, aangezien ik de simulatie niet voor de hele diepte van het zwembad deed.

Als reactie op potentiële critici die nog nooit zoiets hebben gedaan, maar geloven dat er in Houdini of PhoenixFD minder problemen zijn en alles sneller kan, stel ik voor dat je eerst een 150+ miljoen voxelsimulatie maakt en deze samen met de GPU weergeeft met geanimeerde vegetatie en verplaatsing, en schrijf vervolgens op hoe lang het duurde en welke nuances en onverenigbaarheden je tegenkwam.