Collisionobject hierarchy

[Zielscheibe]

Hi all,

im currently working on a game project on my university, using Bullet as physicengine.
I have a general question on a major design problem.
First, we are using a selfmade grahpicsengine, which so far works good with bullet, also because of this forum, so i have to thank you all in advance .
I also searched a lot to find some hints, but without success...

Currently we are just using the collisionpipeline. So our game entities (Spaceships and so on) are just collision/ghost objects.
We are planning to give the ship, which can be controlled by the player, some hardpoints like weapons. We want to handle them as individuals, so they can be hit/destroyed seperatly by other players/AI.

Now the problem is, that as far as i know bullet does not provide some sort of hierarchie for the collisionobjects. In the scenegraph of our graphicsengine it
is possible for example to set the weapon as the child node of the chassis. But the collisionworld should be the one, who updates the positions, not the other way around.
So is it somehow possible to create a hierachie with bullet, so that a weapon is alway at the same relativ position towards a parent chassis collision object?

I already read about compoundShapes, which seems to solve this problem. But on the other hand it opens many new questions.
As far as i know the advantage of collisionshapes is that one can use only one instance for many similar objects. If i would use compoundshapes now, i would think that i have to create every Compundshape and its childnode seperatly for every spaceship entity.

The other thing of which one can think of are constraints, but they seem to be only used for rigidbody simulation, which would cost us performance and as i would think it would not be really stable.

So is there maybe a better way to solve such a problem, which i missed on my research?

[Basroil]

The way compound shape currently updates children (from what I can make out of the code) is have a struct with a transform and collision shape, so you can share children as long as the only changes are shape specific transforms. If you have a dynamic AABB tree enabled, it should form that tree automatically. You'll still need to make compound shapes for each object, but the children should be able to be shared between the shapes (i.e. only need as many gun children as gun types).

If you need everything shared and then a gun separate, maybe you could use a compound inside a compound? Never used it personally (only straight up compound with shared children), so can't tell you if it's going to be a performance nightmare or not.

[Zielscheibe]

Thanks for the fast reply.

There would be still one problem. For what i understand the only way to get information of your game-entity back, out of for example a raycallback, is the userPointer/Index.

For our needs a simple integer is enough to get the game entity, which was hit.

Here i think is the reason why i can not reuse the collision shapes, is because every shape had to point on its entity(for example the gun).

So the question is, how bad is it actually if you dont reuse the shapes?
The memory it needs shouldnt actually be a problem, from my point of view.

[xexuxjy]

The raycasts etc should be able to return you the collision object (normally rigid body) not just the collision shapes, so while the compound shape is shared there will still be distinct bodies for you to identify.