I’m looking forward to it and hope that anyone can possibly provide a new build.
I’m looking forward to it and hope that anyone can possibly provide a new build.
@Piet. Mantaflow build is not currently working with the latest changes. You have functional builds for Windows here (by juangea):
and for Linux (by jensverwiebe) the link is embedded within this message:
could someone explained “decoupled fluid cache” from https://developer.blender.org/p/sebbas/
would it solve crashes related to cache read/write?
Until now, domain could simulate liquid or smoke.
Sebbas always said that he wanted to bring ability to simulate both at same time.
In his last GSOC, he added secondary particles.
There was recent changes of smoke cache in master to limit its size and render smoke faster.
So, he had several reasons to work on cache.
He would probably communicate when branch will be ready to be used again.
I still have not checked it, but it goes more through the route of decoupling different phases simulation, something like simulating the low resolution fields, after that, when you are happy with it, you can do the high res simulation, and when you are happy you can mesh the simulation, and you can delete the part you want to re-do.
Something like that, but I still don´t know it in detail.
thanks for the link… I will check that every day looking forward to that…
Thank you Sebbas, Juang3D, Ko., everyone. I see a lot of Sebbas’ commits in march at https://developer.blender.org/p/sebbas/
How significant are the commits? Are the commits plenty enough for a new blender build, ie. Blender 2.79b + Mantaflow?
I succeeded to build the branch, yesterday.
What sebbas means about decoupled cache is now obvious.
You can bake FLIP particles without baking mesh.
When you are OK with FLIP particles behaviour, you can bake mesh and then secondary particles.
Each type of data will be contained in a specific directory inside cache directory.
If you don’t check particles animation before baking mesh cache, it can erase particles cache and produce an empty mesh cache.
You have to enable high resolution to be able to use Bake Data High and Bake Mesh High buttons.
But these buttons are producing a unsatisfying or empty high resolution cache and may erase low resolution caches.
For fluids, mesh caches have same resolution than FLIP particles.
You can not set resolution for particles to 128 and resolution for mesh to 256.
And an high resolution mesh cache is just the same subdivided and as blobby as low resolution cache.
For smokes, it is just simply impossible to bake an high res simulation.
If you follow expected workflow and bake low res smoke first, enabling high resolution option to bake high res smoke is erasing low res cache.
If you enable high res option first, pressing Bake Low will not register Low Res cache and you can not press Bake High if there is no baked low res cache.
Clearly, it is too early for an usable new build.
We could wait at least that Sebbas fixes smokes baking before sharing a new one.
Thanks zeauro for that information!
@zeauro thank you! could you share the build here? https://github.com/sebbas/BlenderMantaflow/releases
-- PACKAGE-INFORMATION -- Branch: fluid-mantaflow Revision: b122c5a Submodules: locale d3349b4 addons 8f2fd7e addons_contrib 3105780 tools f35d8e5 OS: GNU/Linux, Architecture: x86_64, GLIBC: 2.19 Builddate: Mo 2. Apr 15:17:49 UTC 2018 Filesize: 110459020 byte Sha256sum: fbc1fed1893fe8b1effbee08d32e2437c8942ecc3052d844f7657fa6377c2429 URL: http://www.jensverwiebe.de/Blender/blender_fluid-mantaflow_linux64_latest.tar.xz CHANGES SINCE d7161fc: -fix smoke / manta rename in quick effects -fix smoke / manta rename in UI -replaced WITH_SMOKE macro with WITH_MANTA in entire project -clean up and fixed some warnings -minor stability improvements for new adaptive inflow setup -updated adaptive time stepping -just cleanup and minor bug fixes -get wavelet noise params at every frame (animatable) -support for animated properties in new decoupled baking setup -big cleanup in FLUID.cpp -fix for multiple domains and different flow objects in scene -more updates for decoupled baking - initial support for smoke -cleanup and made multiprocessing only available for unix
Anyone know where i can grab a windows version with the changes @jensverwiebe mentioned?
i managed to build my own version of blender seems i couldn’t get any results turns out blender was removing part of the file path to the cache so it couldn’t read or write the cache files.
my folder was set to D:\blendertmp\ when i looked in the console blender was trying to write to dlendertmp\ all i did to fix it was to add an extra \ in the file name so it looked like: D:\blendertmp.
Just posting encase anyone else was having issues.
Share the .blend file.
new_fluid.zip (98.7 KB)
In order to successfully open the file, you need the Mantaflow branch.
It is only .blend files. Cache is not included.
Bake is necessary to see the fluid.
Bake time is 50 minutes. On my PC (i7-3820).
This is the video when I made this blend file.
This is another video I made using Mantaflow.
thank you so much Kumayuki !
Hi having a play with Mantaflow any advice on what area in Mantaflow I should be adjusting to help prevent fluid going through the mesh in my test scene is it resolution dependent sub frames, flip or another area ?
also is there a way to use all the cpu’s power when baking ? currently i am getting 24 t0 54 percent usage at 128 res all threads are working fine.
Cheers for any help
I tried out more options and got good results from setting the bucket object from 0.5 to 1.00 for collision.
Seeing as only 50% of my AMD 8350FX is being used I have two instances of Blender MantaFlow running
one Raytracing my Frames to file and the other baking a 256 res sim with particles no crash and burn yet ha ha… also using the smooth modifier on the Bake works out well.
A 256 res bake from the Manta flow Blender build, I got the collision setting right on this one,I baked out the particle simulation with floats,drop and bubbles but was getting weird popping of particles appearing from nowhere like it was dropping a few frames…no idea what it was I need more practice shame I don’t have a AMD Thread-Ripper CPU as all the baking is CPU based.
Occasionally the camera would have a bad day act all weird see picture below and I had a few crashes, Look forward to using it in my font project once I learn how to drive it better, way cool simulator thanks a lot for building it
Just having a play now with smoke/fire - I’m finding that if I switch ‘High resolution’ on then fire disappears. Switching on ‘Final’ for the viewport display makes the fire disappear in the viewport too…
With this Buid blender-2.79a-908dbed
Some more testing…
I get crashing when using animated armatures on my system (windows 8.1 pro AMD 8350FX 32GB ram) it gets to 99% of the bake then dies tried it several times and its allways crashes at 99% it will not crash if the armature is not moving.
If I move the armature out of the domain or move the fluid sim to the top of the stack it works fine ie: its not dealing with the armature, I also tested it with and without contraints.
also get crashes with high men usage when over 29 GB is in use (on a scene with no rigs)
I tried the animated rig scene with the default Blender fluid sim with no problems , I don’t know if these are bugs or just my PC but thought I would post my test results…
I’ve been trying out the latest cache updates by sebbas, and I have to say
they’re quite nice. I like the fact that you can set up the basis first, and
then tweak the mesh and particle parameters after.
For instance, if you find that you have too many tracer particles, instead of
having to bake everything over again, you just free the particle cache, make
your changes and re-bake the particle cache. So it’s much faster.
Having to bake everything separately is a bit tedious though, perhaps the UI
could be tweaked a bit - something like a “checklist” or bake everything button?
Also, now everything is baked to /tmp . I assume this is temporary since you
don’t want to lose the data if you restart your computer.
The cache path definition text box doesn’t work for relative directories : // ?
One small display issue that I noticed, is that after baking it displays the
final baking state instead of the actual current state at frame 1. You need to
advance the frame for it to update the display.
Also, for tracer particles, there seems to be an offset for the first 2 frames:
Finally, I had a crash when I was trying to animate an inflow’s > ‘Flow Velocity’ >
‘Normal’ parameter. This could just be user error, but lowering the Inflow object’s
(Circle) ‘Normal’ keyframe to a value of 0 on frame 49 stops it from crashing.
Here’s the blend file and crash text file:
Ubuntu 16.04 64
“preparations for liquid real time updates during bake”
I like the sound of that.
Off to test the pause/resume bake functionality