btCompoundShape::getChildTransform

[ejtttje]

I think you meant to have btCompoundShape::getChildTransform return a reference or pointer to the transform? Not much point in the const version of the function if you're returning a copy...

But while on the subject, if I adjust the transform of a child shape, I see I need to call recalculateLocalAabb(), should anything else be called?

Finally, it would be convenient to have a built-in findShape(btCollisionShape* shape, int start=0) which returns the index of the next occurrence following 'start', so that this index can be passed to the other functions (namely getChildTransform or getChildList...)

Shall I whip up a patch?

[Erwin Coumans]

I think you meant to have btCompoundShape::getChildTransform return a reference or pointer to the transform? Not much point in the const version of the function if you're returning a copy...

But while on the subject, if I adjust the transform of a child shape, I see I need to call recalculateLocalAabb(), should anything else be called?

Thanks for the report, it should return a (const) reference. It has been fixed in the latest trunk, and also updateChildTransform has been added:
http://code.google.com/p/bullet/source/detail?r=1494

Finally, it would be convenient to have a built-in findShape(btCollisionShape* shape, int start=0) which returns the index of the next occurrence following 'start', so that this index can be passed to the other functions (namely getChildTransform or getChildList...)

Shall I whip up a patch?

Although valid, it seems a bit uncommon to add child shapes multiple times into the same btCompoundShape. Is that intentional? Can you give more details on your use-case?

Thanks again,
Erwin

[ejtttje]

Although valid, it seems a bit uncommon to add child shapes multiple times into the same btCompoundShape. Is that intentional? Can you give more details on your use-case?

Oh, I agree it's probably uncommon (although perhaps not, I could see having replicated features within the compound)... in my case there's only one of each shape instance. But if having duplicate shape entries is valid, then the find() function should be able to iterate through them. Note that the 'start=0' default argument means that just calling compound.find(shape) will return the first instance, so only people who have multiple entries need to worry about handling it.

My main use for this is that my initialization is a little awkward, where I allocate the shape in the compound at one point, and then set up the transform at a later point when I get positioning data. I could always remove and re-add the collision shape, but my first instinct was just to modify the transform.

[ejtttje]

by the way, with the addition of updateChildTransform, you should probably remove the non-const version of getChildTransform so users can't accidentally screw themselves... unless there's a reason they might want to change the transform without updating the bb or tree...

Similarly, getChildList perhaps should be marked const (on both the function and the return value)

And one more question while I'm at it... if I change the local scaling on a child shape, I should call recalculateLocalAabb() and/or something to update the tree? I wonder if the main chunk of updateChildTransform should be repackaged as something like "recomputeChildBounds(int index)", although I suppose users could always call updateChildTransform with the current transform. Having a separate function would make it more clear documentation-wise what you need to do when a child is modified though.

(I'm not really planning to do much runtime modification, in my case this is all just during initialization as I read parameter files, but I could see using a compound shape as a semi-soft body for something that occasionally changes shape due to application logic but is usually static)

[Erwin Coumans]

Good points again. Let's remove the non-const getChildTransform, getChildList(), and add a recomputeChildBounds (after scaling etc).

I could always remove and re-add the collision shape, but my first instinct was just to modify the transform.

It is really better to only add the child shapes to the btCompoundShape once you know the final transform. Adding them at the origin and relocating them works, but is less optimal (and slows down tree construction). The same for creation of other objects as well. For example, don't create all your rigid bodies at the world origin (0,0,0) and relocate them afterwards. It would generate an explosion of overlapping pairs.

Is there any way you can refactor your code, you can avoid having to relocating children?