Recursive btCompoundShape question

[sparkprime]

Does a recursive compound shape actually work though? Is it not going to run into exactly this kind of problem? E.g. the index is not going to make sense in the contact callback. I suspect there are many people using bullets in ways that you consider to be 'misuse' and that is the problem with *not* tying it down in my opinion.

[Erwin Coumans]

Does a recursive compound shape actually work though? Is it not going to run into exactly this kind of problem? E.g. the index is not going to make sense in the contact callback. I suspect there are many people using bullets in ways that you consider to be 'misuse' and that is the problem with *not* tying it down in my opinion.

Recursive btCompoundShape's should work fine.

We can put an assert in the 'addChildShape' to check so that people dont' put any of the following shapes as child shapes: btTriangleShape, btBvhTriangleMeshShape, btGImpact*Shape, btStaticPlaneShape and a bunch more.
Thanks,
Erwin

[sparkprime]

How can they work fine though? What index is reported? There is more than one index if you have a recursive compound shape.

[Erwin Coumans]

Recursive btCompoundShape should collide and simulate fine. With respect to the callback for recursive compounds: the index returned is the index for the deepest level of recursion of the btCompoundShape. If you want to get access to the parent compound for the child shape, you could assign a pointer to the parent compound as user info (btCollisionShape::setUserPointer/getUserPointer).

the problem with *not* tying it down in my opinion.

As I mentioned before, we are going to add more asserts.

Thanks,
Erwin

This discussion was split from this topic:
http://bulletphysics.org/Bullet/phpBB3/ ... 697#p17697

[sparkprime]

OK that's what I thought. In fact it's exactly as bad as putting a non-transformed bvh triangle mesh in a compound. Why support one and not the other? In fact it is worse than that, since a nested compound can be supported externally to Bullet by flattening. However there is no way of joining a bvh triangle mesh shape with additional primitives without supporting it in the compound shape. There would be no choice but to add separate collision objects, which is considerably more work and perhaps would also add more work to the broadphase.

For gimpact meshes inside compound shapes, there is no option other than support within Bullet. I would definitely say more important than nested compounds. You can really help a gimpact mesh by adding a few primitives to it.

If you like, how about asserting on the addChild and instead having some function to attach a single triangle mesh shape to the compound. There would be no child transform option, and no more than 1 triangle mesh would be allowed (so the index data could be properly understood).

As an alternative, modify (or extend) the interface to the edge adjustment utility to allow passing in of the collision shape (not the object). That would completely fix the original problem with no need for any hacks.

By the way everything actually works right now. It may not be 'supported' but it works. You could support it easily.

If you add asserts it will stop working and I will just remove them using my local patchset because otherwise my code won't run. It would be overconstraining the API -- breaking things that currently work fine (or can be made to work with a simple patch).

[majestik666]

am not sure what you guys exactly mean by "recursive" but am running into
some weirdness with compounds, is it legal to create something like this :

compound1
| \------- compound2 |--------- btGImpactMeshShape
\ ------- compound3 |--------- btGImpactMeshShape

the inner compounds are created at the same time as the btGImpactMesh
and I then add both of them to the top compound (compound 2 and 3
are childShapes of compound 1 in case the drawing isn't clear ...)
The creating seems to work fine, but when I go and step the world, I get a
crash in : btCompoundLeafCallback::ProcessChildShape.

Is it a problem with the structure itself, or is it just me doing something very
wrong somewhere else ?

Cheers

[Erwin Coumans]

am not sure what you guys exactly mean by "recursive" but am running into
some weirdness with compounds, is it legal to create something like this :

You are trying to add a btGImpactMeshShape to a compound, which is not supported. As I mentioned before, adding the following shapes to a btCompoundShape is not supported: btTriangleShape, btBvhTriangleMeshShape, btGImpact*Shape, btStaticPlaneShape and a bunch more.

If you add asserts it will stop working and I will just remove them using my local patchset because otherwise my code won't run.

You don't need to patch the code for this. We will add an assert to prevent issues, but leave the option open for developers to ignore the assert (without breaking the API for regular use). Something like this:

Code: Select all

/// If you want to add unsupported child shapes, you can set assertOnUnsupportedChildShape to false. 
/// If things don't work as expected (for example adding a btGimpactMeshShape to a btCompoundShape), you will likely have to fix issues yourself.
btCompoundShape::addChildShape(const btTransform& localTransform,btCollisionShape* shape, bool assertOnUnsupportedChildShape=true);

Here is the issue: http://code.google.com/p/bullet/issues/detail?id=348
Thanks,
Erwin

[majestik666]

ok thanks for the info !

I was doing it this way since the Dynamica plugin is actually doing it,
could be a good idea to update this so it doesn't create confusion ?

[Bbilz]

Hi,

I just came across this post, and I never realised that creating Compound shapes with BvhTriangleMeshShape children was unsupported..

How bad is this? Is it a question of efficiency or stability?
We have been doing this for ages and not suffered any instability or crashing, but it would be good to know if this is affecting our framerate!

Thanks

[dphil]

In addition, I am wondering what, then, is the preferred approach for sticking "unsupported" shapes together. For an arbitrary example, a btGImpactMeshShape with a btSphereShape and a btStaticPlaneShape. Ideally I'd like arbitrary combinations because in a simulation I may have two or more objects with any shapes colliding and I want to stick them together.

[sparkprime]

The problem is identifying which parts of the compound are in contact, which you want to know for custom physical materials, etc.

I doubt there is a performance problem.