Recursive btCompoundShape question
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
- Contact:
Recursive btCompoundShape question
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
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: New btInternalEdgeUtility has been added
Recursive btCompoundShape's should work fine.sparkprime wrote: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.
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
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
- Contact:
Re: New btInternalEdgeUtility has been added
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
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: Recursive btCompoundShape question
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).
Thanks,
Erwin
This discussion was split from this topic:
http://bulletphysics.org/Bullet/phpBB3/ ... 697#p17697
As I mentioned before, we are going to add more asserts.the problem with *not* tying it down in my opinion.
Thanks,
Erwin
This discussion was split from this topic:
http://bulletphysics.org/Bullet/phpBB3/ ... 697#p17697
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
- Contact:
Re: Recursive btCompoundShape question
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).
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
- Posts: 66
- Joined: Tue Mar 02, 2010 6:13 am
Re: Recursive btCompoundShape question
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
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
- Site Admin
- Posts: 4221
- Joined: Sun Jun 26, 2005 6:43 pm
- Location: California, USA
- Contact:
Re: Recursive btCompoundShape question
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.majestik666 wrote: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 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:sparkprime wrote: 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.
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);
Thanks,
Erwin
- majestik666
- Posts: 66
- Joined: Tue Mar 02, 2010 6:13 am
Re: Recursive btCompoundShape question
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 ?
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 ?
Re: Recursive btCompoundShape question
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
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
Re: Recursive btCompoundShape question
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.
-
- Posts: 508
- Joined: Fri May 30, 2008 2:51 am
- Location: Ossining, New York
- Contact:
Re: Recursive btCompoundShape question
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.
I doubt there is a performance problem.