Bullet Pieces stuck in air as inactive (SOP-Solver)

[m-egger]

Hello,

I'm currently struggling really bad with completely unpredictable behaviour of the Bullet Solver and am completely out of ideas with how to debug it further.

I'm having a large structure fall into a sinkhole and my current test was just about letting the whole thing drop to the bottom. Now what happens is that certain pieces just get stuck in the air and it seems that no amount of attribut cleaning can fix this. I've had this happen earlier in this project, but also faced it on previous ones very arbitrarily. Currently it's stopping any progress, however, hence this cry for help.

This is one of the cache-dailies, without constraints, that demonstrates the issue best:

This is a screenshot:

(((Ignore the ground, it's a seperate sim and just serves as a backdrop here, not affecting the sim, the whole structure SHOULD just drop straight down)))

 

 

If I glue the pieces together, the thing just sticks in the air and only the bottom rows fall:

 

I cleared all attributes on the input geo, on the constraints, rebuilt the constraints from scratch, all the same.

Has anyone else come across this? I tried on 18.0.460 and the latest 18.0.499, completely clueless. Could this be a bug? It seems so arbitrary.

 

This is the setup in it's simplest form: Same thing happens, the whole thing just gets stuck in the air as soon as the pieces are connected by the constraints.

The constraints are setup with the default configurations of the RBD tools, the attributes on those are nothing out of the ordinary. I can't seem to be unable to upload anything but screens here, so I put it here: https://gofile.io/d/g6XdaY

 

Thanks for any help,
Martin

Edited July 3, 2020 by tortoise

[Noobini]

don't quite know but if I create one from scratch...it just works. So could be some funny buggers going on pre stash

vu_RBD_test.hiplc

[Noobini]

here you are, works. I sped up my testing with gravity set at -99.8, you reset it to -9.8. Wouldn't bother with your custom set active

debug_coalpp_drop_0001_fix.hipnc

(it's something to do with your volume/pscale !)

Edited July 4, 2020 by Noobini

[Noobini]

here's the closest fix I can get to your orig setup.

The crucial bit is the delete small parts. Who knows what you did with volume/pscale before the stash...well...only you would know but toggle the delete small parts on/off and you'll see.

debug_coalpp_drop_0001_fix2.hipnc

(I'm clutching at straws here...but it could be because some of your geo are minute...that size/mass approaching Zero causing these to be treated as inactive...hence delete small parts remedied it)

Edited July 4, 2020 by Noobini

[m-egger]

Yes!! This is the point, thank you! I must have searched really poorly to not have found anything on this before - at least it's documented in one more way now. 

The pre-fractured geo was indeed sliced up by "funny buggers" a custom fracturing process with multiple voronois over the same geometry (I love the fracturing result though), and it apparently caused certain pieces to have no volume at all.

All this also translated through the simplification-setup which placed spheres with the same volume as the fractured piece at the centroid. *Facepalm*

I wish I could buy you a beer! Thank you so much.