Do we have a timeline on mantaflow in blender yet? I have been searching all over the place and haven’t found really any update on when this is planned to happen. Are you thinking like 2.84 or 2.85?
Hi, there are three mentions of Mantaflow in the dev meeting notes:
current plan is still to review and land for 2.82.
Yes, I can confirm this. I am working on it and the plan is to get it into 2.82.
I hoped that it will be merged into 2.81 by the suggestion from blender.org/features
Still it’s great for MantaFlow to be in 2.82 and I hope it will be faster in master
Awesome! Thank you for the quick reply! I’ve literally been scouring the internet trying to find when it was planned to be out!
Hey Sebbas, the plan still for 2.82? I’m so excited if it is! I tried to do a fluid sim with elbeem for weeks but haven’t been able to do it with sufficient quality. I have tried to use mantaflow with the daily builds and it’s looking a lot better I just am unsure how to get the result that I want.
as far as I know it’s still planned!
Yes, AFAIK it’s still planned for 2.82, he is doing an amazing job, even we had a new feature recently to avoid blockines in slopes
Is the blockiness in slopes for water? Also, does mantaflow fix the problem with elbeem where it has “V” marks on them when simulating the water when it is in something that is sloped? Or is that what you are referring to?
I have tried with last update in the branch made a honey simulation, but all simulations was the same. Bug?
In elbeem, problem was related to discordance between particles amount and mesh resolution.
In mantaflow build, both can be generated separately.
User have control of amount and size of particles for remeshing and ability to upscale resolution of domain for mesh and to adjust smoothing settings.
So, if result is blocky, it is your fault.
Here, they are not the same. But they are very very close.
I think that viscosity presets from elbeem have not been updated, yet, to take into account new settings like (surface tension and FLIP ratio).
But yes, maybe, there is a bug.
It is sure that viscosity settings (base and exponent) have an impact.
It is not obvious with default settings that are corresponding to a big world to simulate honey, a small resolution and realtime.
If world is smaller and resolution higher and in slow motion, difference between water and honey should be visible. But simulations should stay close.
I am not sure if tweaking particle randomness and surface tension are supposed to be sufficient to obtain an honey look.
I tried changing the settings to a extreme values and the size of simulaton to 0,1 meters. And I didn’t see any change in the solution. In previous versions, maybe a year ago, the difference was clear to me.
In your domain go to cache, and set the “Type” to “Replay”
This way you will see the simulation immediately.
You have to delete the folders in your cache folder manually to see a new simulation.
That’s a bug for now I think.
After another try, that is just a question of being strict with scale.
If you set Real World Size to 0.1m, your domain should be 0.1m wide instead of 4 m by using quick effect.
If you set your domain as is, you have to go to particles tab to change particles size to 0.001 m.
At that scale, an Honey fluid looks like honey just by changing viscosity preset. No need to modify resolution or anything else that could influence viscosity.
At same frame, result with honey on the left and water on the right.
So, I think that I don’t understand that parameter (RealWorldSize) it not pick your domain, for example 4x4meters, and scale the simulation to that domain is a 0,1mx0,1m?
Sorry, your are right. That should probably work as you describe it and current behavior should be considered as a bug.
What I wanted to report is that viscosity preset is working correctly.
Am using 2.82 Mantaflow build. My problem with fire simulation is that Adaptive Domain does not take Noise into consideration, so after baking the noise, the tail of the flame/smoke is always clipped by the resized domain. I have no choice but to disable AD which results in longer noise baking and larger cache size.
Reported a bug of fire being not rendered but just the smoke.
Also I am not sure if I should report this as a bug, but when I try to simulate a quick moving fire trail, it just doesn’t connect but like a chain of fire blobs, the smoke trail is properly interpolated though. I have already set maximum Sampling Substeps, i.e. 10, but no good. I don’t want to change the time scale which breaks other physics values I am already happy with when only the smoke trail is rendered.