Why add Mantaflow Smoke System?

General Forums Blender and CG Discussions
1

Hello,
I’ve been testing Mantaflow a bit recently, and comparing it to the existing Smoke simulator. Now, don’t get me wrong: I do appreciate the work that goes into Blenders physics module, and I do like the FLIP based fluid simulator, it’s really neat and IMO much better than Blenders current fluid simulator. But that impression didn’t carry over to the smoke section. When I compared them, I couldn’t find major workflow differences (aside from the seperate High resolution, which is slow too and doesn’t look all that good IMO, but I think I will make a seperate post out of that). There is one feature I do like, and that’s to be able to resume baking.

But performance wise, it really isn’t great. When comparing a simple test scene (do quick smoke on the default cube, delete it, replace it with a torus, move it down on the z axis by 1, scale at *0.5), it was roughly 8 times slower on my machine, at the same resolution, without highres. And even the best shiniest fancy features can’t make up for that bad performance IMO. So, why do we replace the existing smoke simulator, if the new is pretty much inferior? Maybe I am missing something, but currently, I don’t like the mantaflow smoke simulator really.

2 Likes
2

Are they seriously going to replace it? Because that be a pretty stupid thing to do.

3

Well, I did a quick verification.
A torus emitting smoke during 100 frames at a resolution of 48 and noise/high res divisions to 2.
Mantaflow is 2 times faster on my machine.

So, are you sure you did not forget to set same quality settings during your tests ?

Mantaflow branch has highest standard in terms of quality than regular blender.
In master, default resolution for smoke domain is 32. In mantaflow branch, it is 64.
1 high res division in master. 2 upres factor in mantaflow.

2 Likes
4

Not sure about this but isn’t one of the advantages of Mantaflow that fulid and smoke can interact with each other?

5

http://mantaflow.com/

I haven’t been following development closely, and effects is not my area of expertise, but from the little I’ve read, this seems like it will be a highly production capable tool. So we’re not talking about fun little clips of smoke puffing, but very complex, cinema quality simulations. At that level, I’m pretty sure Blender’s current solution will fall very short. :slight_smile:

2 Likes
6

I didn’t use high res, but here are the test files (very simple):
smokeTestInternal.blend (702.3 KB) smokeTestMantaflow.blend (702.6 KB)
And, of course, it may very well be that I just missed a setting somewhere, I don’t mean to talk bad about Mantaflow or anything.

7

That is a beginning.

Observed difference is due to the way to cache data.
For example, current simulation takes more time if you choose an OpenVDB file format with a full data depth and file compression.
I suppose that mantaflow UNI cache format stores more data than point cache. It simply takes more time to write files because of that. Registered velocities are re-used when you use a smoke domain to guide another simulation.
If you compare times for an OpenVDB cache with full data depth in both blender versions, gap should be less important.

Mantaflow Replay mode for cache works as 2.80’s one by writing low res cache and high res cache at same moment. There is no improvement in terms of speed to expect from that.

That is the Modular mode that permits to cache low res and high res separately which is responsible of a gain.
In that case, computing of high res cache when low res has already been generated is done faster.

So, it is true : mantaflow is not faster ; if you only do low res. But most of time, you want high res, too.

8

I also have bad impression about the new Mantaflow smoke system.
I’ve spend 5 day on Mantaflow for an advertising and the results are bad compare to the old one.

I take some time to find exemples of Mantaflow on youtube to be sure that I didn’t miss something.
And everyting I saw look less realistic, more blobby.
The up-res seems like procedural effect mixed with the base simulation. The old one give more organic results.

Those demos done by Blender Diplom 6 years ago on the the old Smoke seems impossible to redo on Mantaflow:

It’s diffcult to compare the speed when you don’t have the same results but with the same resolution, Mantaflow is slower. I have done the tests on a Quad core and on a dual Xeon with 20 cores ant 128gb of ram and it’s obvious that Mantflow don’t take advantage of a multicore architecture. Mantaflow push the cores between 50 to 100% but the baking time is not improving a lot.
It’s more like a waste of computer power.

I’m a bit worried about the current situation.
Why dropping the old smoke system when Mantflow seems to not be ready in it’s current state?!
Who is testing Mantaflow and decide that it’s good enough in it’s current state?

1 Like
9

To be fair, the video in your example has the same horizontal line issues and flickering new mantaflow has.

10

I can only explain the how it happened. I don’t know the who or why.

2.8 project is refactoring everything.
Mantaflow was a project initiated years ago, with guy from blender diplom as its first supporter.

So, in december, Mantaflow appeared to be one of the most advanced project among all sort of changes promised by 2.8 series.
Despite known bugs, devs decided to merge it into master.
Most of people only tested mantaflow’s smoke after the merge.
Before the merge, EEVEE and Cycles were not handling it properly during first part of 2.8 development and people were only able to test its liquid simulation.
There was a request to implement replay cache system. That took away a part of developers time.
But Mantaflow is vast and anyways, there was not enough time, with a merge happening at one third of release cycle, to examine all cases.

As a result, there were bugs in 2.82. Several were solved in 2.82a.

I was surprised when mantaflow was merged. I was expecting other stuff like Volume Object type being done before Mantaflow merge.

Currently with 2.82a or 2.83, from what I experienced, if you set CFL number to 10, baking time of smoke should be less problematic.

About blobby look, old simulation had an FFT noise that is not available with Mantaflow.
So, that is more complicated to deal with mantaflow noise to produce fire.
You have to minimize upres noise strength and prefer to use a force field to make turbulence in simulation basis.
Noise has a Time value that is only satisfying if you animate it.
And contrary to old simulation, noise has a scale setting that can also be animated.

Among things that can make render looks different after mantaflow merge.
Management of steps of volume shader has been modified by Brecht.

To sum up, mantaflow is better if you want to make a liquid simulation.
It should not be different for most of smoke simulations.
It is more complicated or worst for some cases of smoke simulations.
But it is also possible to make things impossible with old simulation like liquid influencing smoke simulation.

Mantaflow is a system unifying liquids and smoke simulations. It would not have make sense to maintain 2 smoke simulations and handle bugreports for both.

There is no reason to despair. Situation will not last.

  • Implementation of mantaflow is not finished or complete. Sebbas has plans to pursue it and improve it. And he will continue to fix bugs.
  • Manftaflow UI will continue to evolve to be handled by modifier nodes. And we will soon be able to experience it with new particles nodes.
  • In 2.83, Volume Object type will be available. You will be able to re-use your 2.79, 2.80, 2.81 simulations into future releases of Blender until mantaflow become rock solid.
11

Thanx for the explanations!
Meanwhile, if find some tweets from Andrew Price about Mantaflow current state and bugs.

It’s good to see that I’m not alone complaining :grinning:

Didn’t know that the FFT noise is better for fire.
So the Noise can look ok in Mantaflow if you animate the value? Not sure what you mean be “satisfying”

12

Well. FFT noise is not creating spirals like wavelet one. It is rather creating elongated noise that is more convenient to give a flames look to flow.

About animating noise settings, you can obtain a last variety of results according to values used.
Result may be at the opposite of expected result if values are wrong.
But a subtle animation of noise may break the feeling of an uniform, too much procedural pattern.

13

No those are just artifacts, which look bad. What gives flames realistic flow looks is the volumetrics motion blur, which both Cycles and Eevee still lacks. That’s why pretty much no simulations coming out of Blender look anywhere near the triple A movie quality.

14

As you said, that has nothing to do with mantaflow abilities but with render engines abilities.
Result of noise simulation are voxels.
If motion blur is supported for volumes, in future releases ; it would blur details brought by noise, too.
Currently, sensation of motion blur is handled by increasing Sampling Substeps of inflow.

I am not comparing Blender to other software.
I am just responding to Ron7, comparing old smoke simulation noise from 2.81 to simulation noise in 2.82 or 2.83.