Why is the Concave collision mode having such a strange behavior?
Or is it a bug?

Concave:
https://drive.google.com/file/d/0B-N-rMb06KuxZFpPR0l2bGhxaUU/view?usp=sharing [drive.google.com]

Box:
https://drive.google.com/file/d/0B-N-rMb06KuxVHlCQVVSN2dzY0U/view?usp=sharing [drive.google.com]

The “final” setup is something like this, where i want to just take these shelves as static collision object. As you see the active objects are shaking when static object has concave collisions.
https://drive.google.com/file/d/0B-N-rMb06KuxRlgtbWdEWGRrbmM/view?usp=sharing [drive.google.com]

The workaround I use for this, is just to import the shelves as Packed RBD and set it to static and use box collision (for just Static RBD box collision is not working properly, thats why i initialy used concave)

Cheers,
Tom

yes at this moment bullet concave collision is not good for sim!!!!
Although concave geometry reprisentation is best for create exact shape of collision but in bullet it's still unstable for concave collision specialy concave to concave object collision!!!!
better to use box or convex hull for that.

If you have a critical static hero object that has areas that are concave, use the Bake ODE SOP to construct your shape.

It will take any of box, primitive sphere, primitive tube, or capture pill (as in capture capture pill) as colliders. Mix and match to compose your object.

One common technique to quickly create a compound collider is to use a Peak SOP to offset your geometry in a known distance, scatter points on that surface and then copy spheres on to those points. I just tried using the scatter SOP create attributes pscale and it works very well.

Make sure to go to the DOP network and in the RBD Object fetching the compound object, in the bullet collision tab, make sure to set the Geometry Representation parameter to “compound” (makes sense that you have to do this, right?).

See the example file to create an RBD compound object of the Pig Head in a simple Bullet Simulation.

I'll add that whatever you use for collision geometry, is that you maintain the point count otherwise bullet will not substep collisions.

I've seen people run setups where the point count of collision geometry changes on each frame and bullet gives unpredictable results.

As jeff stated the common workflow is to turn concave geometry into a series of convex pieces which results in better behavior.

As for walls/floors, raying a grid to get the shape and then extruding the faces into unconnected little cubes speeds up collisions.

The only gotcha you can bump into with dividing up a complex deforming convex surface into simple primitives is getting smaller bullet objects stuck in between the collision objects which can cause them to flip out.

Is it more efficient to have 200 pieces of convex hulls collider vs one concave object? Thank you Jeff for the example file.

Depends on the test case and the size of the collision objects. If you have large detailed ground collision geometry as a test case, hundreds of small convex boxes would be better than one massive concave geometry. It'll also allow you to cull out unneeded geometry for faster processing times.

F e z
Is it more efficient to have 200 pieces of convex hulls collider vs one concave object? Thank you Jeff for the example file.

I'm not sure if it's more efficient (I bet it is though), but you'll get much better, much more stable results with many convex primitives than with concave, complex pieces.

Another thing you can do is do vdb_from_polygons and then vdb to spheres to do sphere packing. You can then say that all of those spheres are named the same thing. Then in the packed rbd object DOP node, set it to use a convex hull per set of connected polygons (or whatever that's called). Then you can use the transform pieces SOP to put your original geometry back on to the spheres after you've simulated it.