@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 0 to see the result. That doesn't happen here.

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.

I'm getting this error printed in the terminal (probably related to this issue):
ERROR (bke.rigidbody): /home/zed/prog/blender/source/blender/blenkernel/intern/rigidbody.c:299 rigidbody_get_shape_convexhull_from_mesh: no vertices to define Convex Hull collision shape with

Not sure about the right behavior, would consider quite low priority.

Checked this again and atm it just averages positions and normals of participating verts.
A rotation is derived from the resulting averaged normal alone - thus not being 'stable'.

Havent actually checked it, and it feels like swapping mesh datablocks in a framechange handler is not the best solution, but would it help getting the evaluated object?

So why can't I fetch the mesh data block, from the .abc animation, in a frame change?
Shouldn't the Mesh Sequence Cache modifier correctly present the current mesh data block, to the API, for the frame it is displaying?
Why does the frame change code fail?

Confirmed in older version, but appears to be fixed now.

Yes, this is indeed a chicken & egg issue (and yes, it also happens in 2.7x). Guess we can close that as known limitation for now, then.

But same happens in 2.7?
This sounds like a feedback loop between rigid body simulation which needs geometry for the collisions, but geometry needs transform for modifier stack. While we can avoid some dependency cycles here, the order of updates might be wrong from users perspective. And the only user-controllable solution here would be to go node based.

Deg warning about DEG_OB_COMP_GEOMETRY relation is now fixed, but the rigid body simulation remains completely broken in 2.8 currently here (neither of the two displace modifiers work, only really moving red object works currently).

@Sergey Sharybin (sergey) - I see you just fixed another issue with rigid bodies and particles, could you have a look at this one too?

Using an empty (or center point of any object) is a valid usecase of this modifier, will check on those relations tagging.

The issue in code i saw was related on a fake dependency cycle, which is now fixed in rB099a4104788.
Now i can open the file and there is a playback going on.

I fixed the issue. I just had to turn my quality steps down to 2.

I believe macOS particle drawing crashes were fixed, if it's still an issue we can reopen the report.

I don't know what to expect here. Will someone be explaining to me what what to do about mt issue?

It works in LookDev mode.