While troubleshooting some physics issues, I enabled debug shapes on my physicsSpace and found that the debug wireframe shapes are shifted so that only a part of the debug shape is covering the geometry. I also noticed that ghost objects that I’ve created are detecting the collision with the shifted debug shape as well.
While looking into why this is, I noticed that my bounding box has a center that is not 0,0,0. I think this implies that the geometry model that I imported from blender does not have it’s origin in the center of the geomety and that the ghost objects and debug shapes are relative to the geometry world translation instead of the bounding volume center.
I am creating the collision shape for the ghost object based on the extents calculated for the geometry and then passing it into the ghost object constructor.
Are ghost objects and debug shapes placed relative to the bounding volume center or the geometry world translation? I think the answer is that they are placed relative to the geometry world translation which may not be the center of the object.
Where I should be defining the origin of the geometry so that my physics objects are correct. Should geometries have the origin defined in the center of the model or are ghost objects and debug shapes supposed to handle geometries that have their origins located somewhere other than the model’s center?
As a side note, when I have a RigidBodyControl attached to the geometry, the collision is detected where it should be, not offset by the bounding volume center like the ghost objects and debug shapes appear to be. For example, my character control object will walk through the debug shape and stop when the character collides with the drawn static wall that is in the scene, not stop when it intersects the drawn shifted debug shape.
[EDIT] It looks like the debug shapes are drawn correctly for RigibBodyControls, just not GhostControls
When I used it, all my objects that I performed this on started culling as soon as the center of the bounding volume went outside the camera frustrum. I believe this is because the above creates a new bounding volume for the geometry, but doesn’t update it so the extents are set to all 0.
But even with that said, it doesn’t do anything different than what I was doing (ie. use the bounding volume extents to size the collision shape). That’s actually where I got the idea from. I think the actual issue is due to the ghost object using the world translation as the origin instead of the world translation offset by the bounding volume center.
Did I use the wrong method or should I have passed a node that contains the geometry?
Yes but I’d go for a hull shape… But if its really a box then that should be ok as well… The offset issues are mostly due to local/world relations I guess. You can look at the CollisionShapeFactory and how it compensates for this, basically it creates a relative translation from a root node and a geometry for the collision shape. The setting of a BoundingBox in the collision shape generator should be removed really…