That should work fine, yes.
Tue, May 21
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.
Mon, May 20
I'm not sure if this belongs to https://developer.blender.org/T64879 or here,
As stated in T64877, this is true for all 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.
Sat, May 18
This continues to happen in the new blender 2.80 3b8ae2c08f5c
Tue, May 14
It is working in 2.8 build of 2019-05-13
Sun, May 5
@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.
Sat, May 4
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:
Thu, May 2
@Nils Thuerey (n_t) Hmm, looks like the branch could use a merge with master again. ;)
Wed, May 1
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.
Fri, Apr 26
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.
Thu, Apr 25
Apr 23 2019
@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.
Apr 18 2019
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.
Apr 17 2019
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?
Apr 16 2019
@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.
Apr 15 2019
I can confirm an issue with delete bake action.
Apr 14 2019
Apr 8 2019
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.
Apr 7 2019
@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.
Apr 4 2019
Would need to have a closer look, but could be caused by the change in the evaluation order of rigid body, similar to T63028.
Apr 3 2019
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
Apr 2 2019
Not sure about the right behavior, would consider quite low priority.
Mar 31 2019
Mar 28 2019
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'.
Mar 27 2019
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?
Mar 26 2019
Confirmed in older version, but appears to be fixed now.
Mar 25 2019
Mar 21 2019
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.
Mar 20 2019
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.
Mar 19 2019
I believe macOS particle drawing crashes were fixed, if it's still an issue we can reopen the report.
Mar 17 2019
I don't know what to expect here. Will someone be explaining to me what what to do about mt issue?
Mar 16 2019
Mar 15 2019
It works in LookDev mode.
Mar 13 2019
Thanks for the advice but the thing that I don't understand is that in the older version of blender the simulation runs perfectly.I hope they will fix that and again thanks for all the advices.
Mar 5 2019
No clue. If you figure it out we can re-open this. However I'll mark this as resolved in the mean time.
@Sebastian Parborg (zeddb) Deleting .config/blender/2.80 fixed the issue without a reinstall. Now the question is what was wrong about my previous config files that deletes rigid-bodies... :/
Mar 4 2019
That file works fine for me too.
Could you try to have a clean install on the 2.8 beta and try again?
Be sure to either rename or remove .config/blender/2.80
Afaics there is no direct way of tweaking collision distance.
Mar 3 2019
I saved this file with 2.8 from March 3. The cube has an active rigid body and the plane has a passive one. When I open it, neither rigid bodies are visible (the objects are visible). The cache doesn't play. When I add back the cube's rigidbody, its movement plays in accordance with cache.
@Sebastian Parborg (zeddb) I just downloaded the latest version and reproduced the issue. Interestingly, after I add back the missing rigid body in the physics panel, the baked simulation plays as it should.
Mar 2 2019
I can't reproduce this on my end. The baked simulation plays as it should. Perhaps this was fixed in a later build?
Mar 1 2019
Feb 28 2019
Feb 25 2019
Feb 22 2019
Feb 20 2019
Latest beta still crashes in particle edit. 2/20/19
Feb 18 2019
Feb 14 2019
Weird. Was looking for quite some time =\ Thanks!
@Sergey Sharybin (sergey): file was there in the report (made this more visible now...)
Please always attach .blend file which demonstrates the issue.
Feb 13 2019
This was fixed at some point.
AddressSanitizer: heap-use-after-free P911
Can reproduce here
Feb 12 2019
Fixed by rB024f5ba2bdb.