Versuch mit Blender-Fluids

Hallo zusammen,

ich benütze ja normalerweise RealFlow für Fluid-Simulationen in 3D und habe auch nicht vor dem (kostspieligen) Progamm untreu zu werden... aber warum nicht auch mal einen Blick über den Tellerrand hinaus auf die Seite der sogenannt freien Programme, zu Blender. Das gewinnt ja immer mehr Freunde, und kürzlich ist auch ein Buch ausschliesslich zum Thema Physik-Simulationen mit Blender herausgekommen, das ich gerade lese (Bounce, Tumble, and Splash!: Simulating the Physical World with Blender 3D, Tony Mullen).

Also habe ich ein kleines Setup in Blender gemacht und einen Strom von Flüssigkeit in eine Box laufen lassen, um zu sehen, wie sich die Blenderfluids so anfühlen, speziell in einer längeren Simulation, wo die Box auch langsam mit Flüssigkeit gefüllt wird (QuickTime, 55Mb spielt aber schon beim laden):
http://www.cardiomyocytes.com/movies/Blenderfluids-box2.mov

Ein grosser Unterschied bei der Bedienung des Programmes ist, dass bei RealFlow alles auf einzelnen Partikeln basiert und bei Blender auf einem anderen Verfahren (Lattice-Boltzmann), das eine zuvor zu definierende Domäne mit fester Auflösung erfordert. Die praktische Konsequenz ist, u.a. dass man in RealFlow mit wenigen Partikeln ein sehr rasche Simulation einer kleinen Flüssigkeitsmenge machen kann welche immer langsamer mit zusätzlichen Partikeln wird, während in Blender die Auflösung zu Beginn festgelegt wird und die Simulationszeit in jedem Schritt ungefähr diesselbe (?) ist. Was mir bei Blender aber auch sehr gut gefallen hat, ist das regelmässige Auffüllen des Volumens der Box in dem Versuch oben und dass die Flüssigkeit nie zittert und an Oberflächen recht realistisch als flache Tropfen haften kann.

Danke. Ja, ist mir auch aufgefallen. Müsste wohl die Inflow-Geschwindigkeit animieren.

In RealFlow könnte man beim Emitter einen Zufallsfaktor eingeben oder ein Störungsfeld hinzufügen, ...oder ebenfalls die Geschwindigkeit animieren.

vidiot:
Beim Blender Fluid-System wird die Genauigkeit und Details der Fluids nicht mit der Anzahl und Auflösung der Partikel festgelegt (wie bei RealFlow oder dem AoI-Fluid), sondern mit der Auflösung der Domain, in der sich die Fluids bewegen. Damit wird vor allem das für diese Domain reservierte RAM zum Flaschenhals. In meinem Beispiel hatte die Domain, d.h. der Würfel eine Auflösung von 184, was konstant 600MB RAM benötigt. Was jedoch während der Berechnung ändert ist die Grösse des Polygon-Objekts das die Flüssigkeit in dem jeweiligen Frame der Animation darstellt. Je nach der Grösse der Oberfläche (ist sehr gross wenn viele kleine Tröpfchen herumfliegen) sind dann die Files, die auf die HD geschrieben werden, entsprechend umfangreich. Für diese Simulation waren die "fluidsurface"-files zwischen 200k und 25 Mb gross.
Was die Oberfläche angeht, so gibt es hier die Parameter "Surface Subdiv" (hier =3) und "Surface Smoothing" (ebenfalls =3), welche die Flüssigkeitsoberfläche glätten. Das ist ein Punkt, wo ich von den bisher gezeigten Beispielen der Deltor-Fluids noch nicht so überzeugt bin. Ich glaube, das ist eine Eigenschaft eines Fluid-Systems, das den Realismus enorm verbessert und wo die Blender-Fluids zur Zeit die Nase vorn haben.

@Fish:
Danke ! Das habe ich schon mal mit einem transparenten Material probiert. Es war nicht so übel, wie ich es eigentlich erwartet hatte. Verlängerte die Renderzeit um ca den Faktor 2. Kenne mich allerdings zuwenig aus mit Texturen in Blender, sodass ich erstmal nur mit den Fluids spiele und mit dem Standard-Material.

Ein update zu diesem Thema:

der Anmerkung von Elfmann folgend habe ich meine (bescheidenen) Blender-Kenntnisse um die IPO-Kurven erweitert, d.h. Animation mit Keyframes, und damit die Inflow-Geschwindigkeit animiert. Das macht das ganze gleich etwas lebendiger ! Das Fluid reagiert auf die verschiedenen Geschwindigkeiten und wird entsprechend aufgewühlt oder beruhigt sich dazwischen. Man sieht auch noch besser hier, wie Tröpfchen auf die unsichtbare Wand des Würfels prallen und manchmal daran runtergleiten:
http://www.cardiomyocytes.com/movies/Blenderfluids-box3.mov

Hallo Vid

das sind hier 2000 Frames bzw. Schritte und gedauert hat die Simulation ca. 20 Stunden und das Rendern danach ca 8 Stunden. Die Simulations geschwindigkeit hängt sehr stark mit der Auflösung der Domain zusammen (ich wollte ja aber z.B. die feinen Tröpfchen und Wellen sehen, deshalb ging's nur so). Beim Rendern sind die ersten hundert Frames in einer Viertelstunde durch und dann gehts langsamer voran, wenn die Fluid-Objekte eine besonders grosse Oberfläche=polys haben. Motionblur ist mit AfterEffects gemacht, das spart auch nochmals Renderzeit.

Der Rechner ist ein MacPro 3Ghz Xeon, 2xQuadCore aber Blenderfluids lasten beim Backen immer nur exakt einen Core mit 100% aus. Beim Rendern ist es anders, wo die Vorbereitungsphase auf nur einem Core läuft und dann zum Rendern der Bildteile wird die Arbeit wohl verteilt und die System-Auslastung springt für kurze Zeit auf ca 700% hoch.

Den Vergleich mit RF mache ich vielleicht noch. Es wären schon ziemlich verschiedene Methoden, die dann verglichen würden.... Oder fürchte ich vielleicht einfach, dass Blender besser wäre

Von dem Buch habe ich bis jetzt erst das Fluid-Kapitel ganz gelesen. Ist gut geschrieben (engl.). Nur könnte es evtl. passieren dass es mit all den Screenshot relativ bald wieder veraltet ist. Steht leider nur wenig über die Physik-Hintergründe der Simulationen drin. Aber auch viel zu Partikeln, Pflanzen, Fell, Springfedern etc.