Also something funny happens with duplicated objects.

I assume its because the objects share the same cache.

Yes, there is currently no mechanism that resets the cache after changing a flow object. Only changing the domain itself will clear the cache.
I will set this report to known issue for now.

This should have way higher priority. Back when Blender had it's own internal fluid solver, it wasn't the best quality, but at least it was usable. The issues with Mantaflow implementation are so severe it's really hard to confidently say Blender currently has any reasonable means of creating fluid simulations. The workflow is broken to such a degree it's just not possible to use this in any degree of production scenario.

This should also be considered a regression, because we went from usable fluid solver from pre Mantaflow branch merge to now unusable fluid solver.

How can something that is completely dealbreaking in terms of the entire software major feature (fluid simulation) be simply categorized as Known Issue? Known issues are usually minor limitations, not major things that invalidate one whole section of the software feature set.

Blender has a whole section dedicated to Simulation at https://www.blender.org/features/ yet this "known issue" basically eliminates it. So if it's okay to categorize this as known issue, then it'd be appropriate to remove Fire&Smoke and Fluid section from https://www.blender.org/features/simulation/.

@Ludvik Koutny (rawalanche) there seems to be a clear workaround (tweak the domain object), so I don't see how this is a deal-breaker.

Known issues reflect the upcoming agenda of a module and serve to communicate that to users to avoid misaligned expectations. @Sebastián Barschkis (sebbas) can elaborate further on the reason this won't be prioritized now.

@Ludvik Koutny (rawalanche) I personally try to fix any report, regardless of its subtype or priority. Tagging this as "Known issue" was a mistake, sorry about that.

In T77170#1017001, @Dalai Felinto (dfelinto) wrote:

@Ludvik Koutny (rawalanche) there seems to be a clear workaround (tweak the domain object), so I don't see how this is a deal-breaker.

Known issues reflect the upcoming agenda of a module and serve to communicate that to users to avoid misaligned expectations. @Sebastián Barschkis (sebbas) can elaborate further on the reason this won't be prioritized now.

You really think that having to click on the domain and change some random parameter, then revert it back to previous value on the domain object after every single change to parameters or transforms of any inflow, force, collider etc... in scene is an acceptable workaround?

I mean, it make so ridiculously little sense. If a domain GUI interaction is required after almost any change to the various scene elements affecting the outcome of the fluid simulation, then what is the point of even having a "Replay" mode. If one has to already click on domain properties to refresh it, then the user may as well set the mode to "All" instaed and cycle the Bake/Free bake button. Then, the Replay mode can be completely removed, as otherwise all it serves as is a giant room for error, because most of the users will be hardly aware of the nonsensical intricacy that the Replay mode really only works with domain settings, and changing any other requires manual refresh. And how is the manual refresh performed? "Well - you just change something on the domain and then undo it."

Here's an analogy. Imagine the same degree of problem in Mesh Editing section of Blender: Any mesh edit tool like extrude, loop cut, knife, etc... would show no changes to the mesh after performed. The viewport would be displaying outdated mesh prior to mesh editing operation. After exiting to Object mode, and re-entering the Edit mode, the changes would finally appear. Can you imagine simply classifying this as a Know Issue and then saying "there seems to be a clear workaround (exit and re-enter edit mode), so I don't see how this is a deal-breaker." ?

Honestly, I can't understand how anyone could consider workflow resulting from this workaround to be even remotely in the territory of acceptable:

If you are the one in charge of managing the tasks of Blender developers (which I assume so, as you are the one who usually puts together meeting notes), then you should know the Fluid Simulation part of Blender at least to such a degree that you'd realize how breaking this is to a major feature of Blender, and how far below it is compared to quality standards of other parts of Blender.

If you by any chance have contacts to some high profile Blender users and influencers, I'd suggest reaching out to them and asking them if they had used Blender's fluid simulation tools ever since Mantaflow branch merge, and if so, whether they had any success using it. I think you'll be surprised.

Check it on 2.91.0 alpha. https://builder.blender.org/download/
Crashes fixed and viewport updates seems fine.

Maybe a temporay workaround would be to make a modal that lets everything through except spacebar in conjunction with some other key, in which case it unchecks and rechecks 'use adaptive time steps' to ensure new settings are used, then rewinds and then plays.

@Sebastián Barschkis (sebbas) , @Dalai Felinto (dfelinto) mentioned you could shed some light why getting mantaflow up to the same standard as some other areas of Blender doesn't need to be a priority at the moment. Is this a hint that it's going to be replaced completely? I think I recall seeing that development of Mantaflow by it's developers ended in 2017 (could be wrong though).

In T77170#1032765, @michael campbell (3di) wrote:

@Sebastián Barschkis (sebbas) , @Dalai Felinto (dfelinto) mentioned you could shed some light why getting mantaflow up to the same standard as some other areas of Blender doesn't need to be a priority at the moment. Is this a hint that it's going to be replaced completely? I think I recall seeing that development of Mantaflow by it's developers ended in 2017 (could be wrong though).

@michael campbell (3di) I am not aware that Dalai ever said that. The discussion in the comments above was just regarding this report and not about the simulation system itself. Please don't put your own interpretation into other people's comments.
As for this bug: Yes, I can see how this is not an optimal workflow. I will take a look at this as soon as possible.

As for Mantaflow itself, maybe it is not getting as many updates as in 2017, but I can guarantee you it is being maintained and gets a new feature every now and then.

I only have my own interpretation of other peoples comments available to me :D .... which I'm aware may be incorrect... hence me asking you for your clarification.

Dalai said:

@Sebastián Barschkis (sebbas) can elaborate further on the reason this won't be prioritized now.

Anyway, thanks for the clarification, it wasn't my intention to make you defensive. I was just checking so I could decide if it was worth including mantaflow in a course I'm putting together.

Cheers 👍

We have so many channels nowadays (devtalk, blender.chat, social media, blenderartists) where we can talk about these topics all day long!
Your question was just too broad. The bug tracker needs to stay precise and strictly on-topic.

Just poke me in the chat next time for such questions and all is good!

cool, thanks.

Can this please be worked on? I realize that there are other problems and possible features, but this is incredibly annoying when trying to work with mantaflow.

In T77170#1026153, @Carlos Troncoso (schmick) wrote:

Check it on 2.91.0 alpha. https://builder.blender.org/download/
Crashes fixed and viewport updates seems fine.

Nope, Replay caching mode is still broken on 2.91 release. Even setting a driver with a random noise to update the domain settings wont trigger the cache deletion. You have to manually select the domain and change some parameter, every, single, time. It makes the Replay mode useless since you already have to manually delete the cache on the Modular mode anyway. It's been 10 months since 2.82 came out with Mantaflow and I'm still using 2.81 for simulations because of this bug alone.

In T77170#1062683, @John (sixeg) wrote:

In T77170#1026153, @Carlos Troncoso (schmick) wrote:

Check it on 2.91.0 alpha. https://builder.blender.org/download/
Crashes fixed and viewport updates seems fine.

Nope, Replay caching mode is still broken on 2.91 release. Even setting a driver with a random noise to update the domain settings wont trigger the cache deletion. You have to manually select the domain and change some parameter, every, single, time. It makes the Replay mode useless since you already have to manually delete the cache on the Modular mode anyway. It's been 10 months since 2.82 came out with Mantaflow and I'm still using 2.81 for simulations because of this bug alone.

Yes, it's still broken. I am very confused about how is it possible that Mantaflow is getting new features before this is addressed. If there's just one developer working on MF integration, what's the point of adding a new features to a module no one can use because it's broken? No amount of new shiny features will make it usable as long as the dealbreaking bugs like this one are not solved.

This bug will be a target for the 2.93 release (i.e. cache invalidation needs to be improved). Unfortunately there is no time to get this ready for 2.92.

Hopefully not forgotten?

Hi, I can confirm that this bug still happens in master branch blender 3.0 hash 47e88345a154.

Finally got a chance to use the new Mantaflow fluid sim and I was wondering what on earth was wrong since the cache was not updating when a change was made to the flow object (unless some random parameter was changed in the Domain object). I am using 2.92 official release. Does anyone know if this bug has been fixed in any of the experimental builds? Mantaflow has a lot of potential but previewing results in real time is extremely difficult at present. Thanks for your time!

Can't believe that this is still broken on 2.93 release ._.

In T77170#1092635, @Sebastián Barschkis (sebbas) wrote:

This bug will be a target for the 2.93 release (i.e. cache invalidation needs to be improved). Unfortunately there is no time to get this ready for 2.92.

Can't believe that this is still broken on 2.93 release ._.

In T77170#1092635, @Sebastián Barschkis (sebbas) wrote:

This bug will be a target for the 2.93 release (i.e. cache invalidation needs to be improved). Unfortunately there is no time to get this ready for 2.92.

Hi, we're now on 2.93.1 LTS and this isn't fixed. Also I would like to add that modifying the domain object doesn't produce accurate results either as seen here (It seems to half-bake the effect or only work on the first frame?):

@Sebastián Barschkis (sebbas) working on performance while we need to go back and forth with the domain to refresh the cache is kinda weird thinking.... should't this bug, overall interactivity and ui/ux be a higher priority that rough performance ? imagine having gpu acceleration in 3.1 and still having to manually resetting the cache after each emitter/force change

Any news on solving this issue?

Could a button be added to the cache section that we could push to invalidate the cache? This would remove the need to toggle a setting and could help a lot of people move forward.

Mantaflow (fluid simulator) has no active developer at the moment. Moving those bugs as known issues so at least other users can find their issues already reported.