I also run into this issue today. Tried everything within my knowledge but it wont work. SIngle bake does work , but thats not useful with multiple items. How did they do the open movie projects without this?!?!?

This is indeed a known limitation, we should improve the UI here once but for now it is require to have the same level for both.

That should work fine, yes.

Still not sure if I understand correctly:

Have a decent play with the removing and adding, cause it produces different results all the time.

Problem is Removing the Ridgid Body World in the first place [which in turn removes the ridgid bodies from the objects].
If you want to keep the ridgid body settings (but for some reason wont those object not to participate in the simulation), why not move the objects to a different collection [not the RidgidBodyWorld one]?

The big issue here though is that it sets EVERYTHING to default Dynamic/Active and resets mass. Even if it already had a rigidbody. So you lose everything you set up already.

I'm not sure if this belongs to https://developer.blender.org/T64879 or here,

As stated in T64877, this is true for all (EDIT: not all, some) Physics types and these are not just disabled, but removed.

Indeed, seems weird.

Think this bug is back - bb88485a1693751baff8a61917987323dbee654a distorts smoke with the adaptive domain.

This continues to happen in the new blender 2.80 3b8ae2c08f5c
When you create a cube and fill it with particles in volume mode and with grid distribution, a diagonal row is missing, if you invert the grid only this row appears.

It is working in 2.8 build of 2019-05-13

@Bastien Montagne (mont29) thanks for the detailed comments! We'll have to more carefully look at the points you mentioned. Good idea to make the naming scheme consistent, to properly indicate the parts of the new solver. I'd suggest using "manta" there to distinguish it from the old smoke and liquid version.

Note: just updated the branch against latest master (was kinda painful, thanks to some 'cleanup' in BKE physics files :( ), would be nice if patches could be updated too.

Some initial usability review after using the branch for a few tests, and a first quick review of the patches:

@Nils Thuerey (n_t) Hmm, looks like the branch could use a merge with master again. ;)

@Brecht Van Lommel (brecht), @Bastien Montagne (mont29) - okay, very good!

Yes, it’s still on my radar for this week or next one…

The plan is still for @Bastien Montagne (mont29) to do the initial code review. @Bastien Montagne (mont29), will you have time to do this in the next few weeks? Spending like one day to go over the code and testing the functionality.

I have another question here for the experienced blender devs (@Brecht Van Lommel (brecht) @Sam Van Hulle (sam_vh) @Martin Felke (scorpion81) @Jacques Lucke (JacquesLucke) and maybe others?): what would be the best next steps for an official 'approval' of the mantaflow diffs? I saw the 2.8 timeline, and I guess it would be ideal to verify that the patch is in a good enough state some time soon. Then it could be merged into the main branch as soon as possible after 2.8 is released in July, such that it can be included for the 2.81 release.

@Brecht Van Lommel (brecht) Okay, yes - the GIL seems to be unproblematic so far. It could make the UI somewhat unresponsive when baking large sims, though. The new node system notes look interesting. I think for mantaflow it would neat to go for the "everything-nodes" direction, where a node graph would define the data flow of the simulation. This could then use a python back-end, or directly hook into the mantaflow functions (the functions that are exposes to python are the crucial ones that ideally would also be available as nodes). It's definitely a good point to keep in mind.

Ok. The main concern is not so much that it's slow for fluid simulation by itself, but if multiple performance sensitive areas use Python it does become a problem to have these global locks. If this is how the Mantaflow API works and it's a big burden to use C++ instead it seems acceptable.

@Brecht Van Lommel (brecht) Good question, to add to sebbas comments, there are a few reasons for the python bindings: a first mundane one is that that's how the mantaflow solver worked originally, and it would have been a lot more work to switch to C/C++ bindings. Also, the performance impact is negligible, as mantaflow provides all the solver building blocks via python, but each of the steps is quite expensive. So there are no low-level operations in python (e.g. access to grid cells), but just a small number of calls to high level functions that typically make several passes over the full grid.

There's a pull request from David Ullmann extending the NOPYTHON option.

@Brecht Van Lommel (brecht) Right now the only way to access all Mantaflow functions is through Python. In terms of performance I wouldn't say that this is an issue. Once the Manta solver acquires the GIL it will compute one "step" and only once completed release it. The time between steps where other resources (like the UI) can acquire the GIL and Manta has to wait for it would be the only delay during a bake job. This delay is negligible from my experience unless there are other resources that could block the GIL for a very long time.

@Nils Thuerey (n_t) Yes, you're right. Those lines won't be needed in the future anymore. Will remove them.

Can someone remind me why this is integrated through Python rather than C++, and how much work it would to change it to C++?

@Sebastián Barschkis (sebbas) - I noticed the exported python scene has a few lines at the top for OS/multi-processing checks that don't seem to be used or necessary. (from "withMP ... up to VARIABLES", ca. lines 8 to 18). Those could be removed, right?

@Ulysse Martin (youle), thanks for the video. What I tested is that when I'm at e.g. frame 50 and press Delete Bake then, I would expect it to remove all results from the physics sim, and you'd have to go back to frame 1 and play to simulate again. That doesn't happen here. If you're at frame 1 this patch works fine indeed.

I join a .gif video to show before and after applying the patch on my computer:

This patch doesn't seem to do anything for me.

I can confirm an issue with delete bake action.

Hi everyone, great to see the manta integration being re-revived! @Sebastián Barschkis (sebbas) thanks for the large patch collection. I just checked out and tried the revised diff "from scratch". Works nicely on my MAC. The sims also run through without problem (I tested based on the quick-smoke and quick-liquid setups). So I think this patch looks good, overall. There are some obvious next steps, like removing the old liquid/smoke modifiers, and cleaning up the code, but I think this would be better to address once the manta code is integrated.

@Bastien Montagne (mont29) Yes, that's definitely a good idea. I just updated the diffs (now it's branched from the 2.8 "master") and also synced it with the fluid-mantaflow branch which can be used for test builds. From here we could now get the review rolling.

Hi Sergey,

Would need to have a closer look, but could be caused by the change in the evaluation order of rigid body, similar to T63028.