Bounding Volumes, Ghost Objects, and geometry location

Troubleshooting physics
1

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.


  1. 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.


  2. 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
2

Why don’t you use the CollisionShapeFactory? It handles these cases normally.

3

I did look at that. I think there is a bug in it that I was going to submit a patch for later. I tried using the following routine with passing in the Geometry of the object:



[java]

public static CollisionShape createBoxShape(Spatial spatial) {

if (spatial instanceof Geometry) {

return createSingleBoxShape((Geometry) spatial, spatial);

} else if (spatial instanceof Node) {

return createBoxCompoundShape((Node) spatial);

} else {

throw new IllegalArgumentException("Supplied spatial must either be Node or Geometry!");

}

}





/**

  • Uses the bounding box of the supplied spatial to create a BoxCollisionShape
  • @param spatial
  • @return BoxCollisionShape with the size of the spatials BoundingBox

    */

    private static BoxCollisionShape createSingleBoxShape(Spatial spatial, Spatial parent) {

    spatial.setModelBound(new BoundingBox());

    //TODO: using world bound here instead of “local world” bound…

    BoxCollisionShape shape = new BoxCollisionShape(

    ((BoundingBox) spatial.getWorldBound()).getExtent(new Vector3f()));

    return shape;

    }

    [/java]



    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?
4

Why you use the create box shape when you want wire shapes?

5

My goal was to create a ghost control physics object. I was only viewing the wire shapes drawn with physicsSpace.enableDebug so I could see where they were.



I was creating the box collision shape because I thought I was supposed to pass in a collision shape to the ghost control constructor. Do I not need to?

6

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…

7

I switched to

[java]

CollisionShape colShape = CollisionShapeFactory.createDynamicMeshShape(geometry);

[/java]

and it works fine.



I think there is a problem using CollisionShapeFactory.createBoxShape with a box that has the origin somewhere other than the middle of the box, but maybe that’s for another day.