Lets talk about Mantaflow

That is a problem of refreshment of cache that is there since a very long period.
Not just with smoke/liquids, but with all physics, at the moment, that several objects are involved.

Depsgraph is updating only things related to active object.
And when you are making a simulation implying a domain that is more obvious.
When modified object is not the domain, cache is not erased.

That should not happen when simulation will be evaluated as a bunch of node connections.
I don’t think that developers will pass time on trying to solve that outside or Everything Nodes project.

But it is true that since introduction of mantaflow in 2.82, in february, user feedback is providing many bugreports.
It was known that usability was far from perfect during the merge for 2.82.
Logically, several problems were solved in 2.83 and 2.90.
For 2.91, focus was made on integration of GSOC about missing fluid visualization to debug simulation. We are currently in a bugfixing only week and there are still a little bit more than 2 weeks before 2.91 release.
Those new APIC particles are supposed to be a 2.92 feature.

According to release cycle policy, phase of introduction of new features for release 4 months away is overlapping stabilization of release that is 1 month away.
I think that sebbas just used that window to implement a small 2.92 feature before fixing bugs for next 4 months.

Long period is also before 2.8+?
In 2.79, if I remember correctly in simulations with cache of the replay type, if you made changes in any configuration of the simulation and you took the timeline to the beginning, the cache was correctly cleared and new parameters in the configurations they were taken into account when you play animation again for the new simulation. Apparently this is not happening in 2.8+ when you bring the timeline to the beginning and play animation.

Oh, you talked about Depsgraph so I guess you mean new Depsgraph since 2.8+

No, I am saying that problem is there since 2.5x.
There were some releases where problem was less present but that was sporadical.

It’s not, at least not to such a degree. I had no significant problems using Blender’s older, pre-Mantaflow fluid simulator. There were some minor issues occasionally, but nothing compared to the total unusability of Mantaflow.

There was no one old pre-mantaflow fluid simulator.
There was a smoke simulator and a liquid one.
There were cache problems with the old smoke simulator in 2.5,2.6. It began to become less problematic in 2.7.
It was more stable in 2.79, 2.80, 2.81. But that is a small period of time compared to the global time smokes were present in Blender.

And there was no replay mode with old liquids, there was no ability to tweak particles with old liquid simulation. So, when feature is not there, there is no problem associated to it.

Although maybe sometimes there were some update problems with the cache in 2.7x, I also think that in 2.8+ the cache in simulations is acting even weirder and with strange behavior. But I’m not sure it’s a Mantaflow only problem. I think the cache issues were also present in 2.80 and 2.81. But I’m not entirely sure, I should test again to confirm this.
I am referring to Live/Replay cache when play animation.

A new viscosity solver has been added to Mantaflow:

paper behind the method:


Distributing simulations any news ?
Allows you to set up the networks of a simulated object so that it can be solved in parallel on multiple machines.


I’m trying to import one frame of smoke simulation from one file into another. The noise cache is in vdb also, but when imported it doesn’t show in rendered view (it is visible in solid view thou). Obviously to me is that the noise file needs to be combined with smoke data cache vdb.
Is it possible to import one vdb cache file combined with noise?
I cant import whole simulation because it takes 100GB of RAM and one frame is much smaller.

You must set the “density” parameter in the shader to “density_noise”
The noise cache is the smoke cache + the noise, you only need this one.

1 Like

Fantastic! It’s working, thank you very much!

In the meantime I found convoluted workaround for this:

  • copy cache folder & rename it
  • remove all cache files and leave only one frame you need
  • in original scene unlink cache folder
  • append smoke domain from original scene in new scene
  • link it to copied cache folder with one frame

That said it will still be slower, and less responsivie than imported vdb object.

i dont know where to ask but this thread seem the right place

im veryyy curious
is it possible for Blender to create such a thing? :flushed:
1 Like

does anyone know how to mesh a liquid sim without the flickering ?

If it’s possible, it’s probably with a weird and cumbersome setup… :sweat_smile:

1 Like

I use a remesh modifier to have a dense mesh, and a big smooth on that.

1 Like

Is there any way to keep the same amount of liquid when I up the resolution divisions…? I think someone else asked this before, either here or in the devtalk forum but couldn’t find it.

I find it odd that upping the resolution will esentially create more liquid… That functionality completely destroys the ability to preview the sim at a low resolution and then upping it for final render.
If I preview at 32 divisions and everything looks right then I expect that upping the divisions to 64 or 128 will only make the sim look more detailed, instead of adding 2 or 4 times the liquid… Am I too far off in how I expect it to work?

And if that’s the case, can anyone point me in the correct workflow for this?

Yes sure, Probably with flip fluid addon…


In theory, making impressive fluid simulations with mantaflow is possible.
In practice, that demands a computer able to handle lots of data and computations to make simulation and render it.
You need the skills to animate the dragon. The skills to balance what is the most pertinent : one domain set-up with multiple inflows, outflows and effectors or a multiple domains set-up for each shot.

But yes. In theory, mantaflow is able to handle make a liquid simulation influencing a smoke one.
That should be possible. But there is no doubt that, in practice, that is a lot of work.

The fact that liquid volume, at high resolution, is not matching liquid volume, at low resolution, was already a problem with old simulation before mantaflow.

You can’t expect a satisfying low res preview with old system or with current one.
A low domain resolution simply means less volume space treated by simulation.
A big cell treated as filled with liquid can be replaced by a majority of smaller cells filled of liquid and some without liquid. And reciprocal is also true for big cells treated as empty.
But an higher resolution also simply means an higher amount of particles generated and involved in fluid simulation. This supplement of particles may change fluid movements, completely, modifying status of what would have been big cells of a low resolution.

Mantaflow is improving the workflow by showing to user, intermediate states (particles and 3D grid), before obtaining of mesh, that were hidden in older simulation.

The correct workflow is the following one.
Check out dynamics of simulation only by looking at generated particles.
Then, checkout 3D grid by hiding particles and enabling Grid display, disabling Slice display under Viewport Display panel. Those revealed grid cells are corresponding to where particles have been found. It is a rough approximation of what mesh should look like.
Mesh generated is taking shape of cached grid if smoothing settings are disabled.

So, at each check, you can try to adjust settings to make next step, closer to previous one.

Now, with modular cache, you can upscale mesh resolution, modify particles radius threshold used for meshing, and smooth it a lot, under mesh panel ; after generating faster a particles simulation at lower resolution. If that provides a more satisfying result.
Instead of inefficiently, regenerate both, at same time, for each tweak.

1 Like

Thanks for the explanation, but I’m already working as you mention. I haven’t even started to mesh the simulation because the difference between resolutions is just too high.
And that shouldn’t happen, is completely counterintuitive… the difference in the number of particles generated shouldn’t be to have more liquid, it should just improve the visual quality of the previous version. You say I can play with the options to generate the mesh and add more detail to that, but here’s the problem: a mesh with 4 or 8 subdivisions generated on top of a 32res sim won’t look any better than the default of 2 subdivisions, because there are not enough particles in the sim! And if I up the resolution from 32 to 64 then suddenly I’m dealing with a completely different result; not a little different, is like if all the other settings were modified too.
After checking the manual again I see that the particle radius plays a very important role in this, but even after doing several tests still can’t get it to work correctly, it seems to me that there should be an option to allow the particle radius to change automatically according to the resolution divisions in order to maintain the same behavior of the liquid and only make it more detailed.

I remember having to use realflow at work around 2012 and they already had that workflow sorted out. You simulate the particles at a lower res, check if everything’s ok, then up the resolution to get the same result only more detailed, and after the final bake is done create a mesh and export. There were never differences between resolutions, it only improved the detail of the sim.

Now if the current behavior is expected and that’s how it was meant to be, then the UI should make this clearer, because right now is confusing.
This option should then be called simply Grid Size and make it very clear in the tooltip that a higher size will result in more liquid being generated.

With that change done, there’s still something to be done about the problem I’m facing, how to work in lower res and then have a final simulation with a higher resolution that DOESN’T changes the behavior of the liquid.
Why? Because even if I have the ability to run just the particle sim without meshing it, it still will take a lot of time to run a sim at 128 or 256 resolution, and if I’m making tests for a client’s project I need to be able to preview as fast as possible, and only when I’m satisfied with the results I’ll up the res and leave it simulating over night. But that can only be possible if I’m sure that there won’t be any differences between the sim at 32 res and the sim at 256 res.

1 Like

I genrally agree with what you are saying. What you described apply to smoke as well. I recently wasted dozens of hours to find the right settings for one smoke sim. The inability to fast preview overall shape and refine the details later with maintaning this overall shape is frustrating and it wastes A LOT of time.
Combined with couple annoying bugs - like inabillity to see modular noise bake (which was thankfully fixed) or not updating preview after domain change (https://developer.blender.org/T77170) - are making working with Mantaflow pain in the ╒ᶸͻʞ¡ƞᵷ ₳₴₴.

1 Like