Hello
We are using the Bepu Physics Engine for an upcoming space game. At the moment we are working hard on a problem caused by the usage of ConvexHullShapes. The following happens:
- The 3d Model contains 1 Model for rendering and 1 collision model (which definetly is convex)
- During compile time the the vertices of the collision model are passed to the Toolbox.GetConvexHull method to retrieve the set of vertices on the surface of the hull
- At runtime this set of vertices is passed to the constructor of the ConvexHullShape class
- Then this ConvexHullShape is added to a CompoundShape
- Now when this object (which is for example a cube represented as convex hull) is shot to a flat floor (represented by a Box) the object sinks into it and seems to roll as if it was a cilinder
We think we are missing a general thing that should be considered when using hulls to represent collision objects. Could you please point out what we are doing wrong or which possibilities exist do debug / narrow down the issue?
Thank you very much
The dev team
Project Longshot
Using ConvexHullShape causes 'strange' effects
-
- Posts: 2
- Joined: Sun Dec 11, 2011 3:45 pm
Re: Using ConvexHullShape causes 'strange' effects
Most issues involving convex hulls involve a graphics-collision mismatch. This might be due to not compensating for the recentering a ConvexHullShape does on the points it is given. When the ConvexHullShape is created, it computes the center of the shape's volume and all points are recomputed as offsets from that center.
To narrow it down as quick as possible, I'd recommend trying to get the vertices into the BEPUphysicsDemos and create a convex hull from them in one of the demos. The BEPUphysicsDrawer will show exactly what the convex hull is doing.
For a longer term debugging investment, you could also get the BEPUphysicsDrawer from the BEPUphysicsDemos and use it in your own project to do debug visualization and compare it against the graphics.
There might be non-graphical problems involved too, like objects being outside the recommended range of 0.5 to 10 units in any dimension. Usually, it's safe to go beyond this, but staying with in the range gives strong guarantees of stability. Depending on the simulation, you might be able to use individual objects which are hundreds of units across without any problem. Unless your shapes are either very tiny (<0.15 units) or extremely large, I doubt this is the primary explanation for the observed problems.
To narrow it down as quick as possible, I'd recommend trying to get the vertices into the BEPUphysicsDemos and create a convex hull from them in one of the demos. The BEPUphysicsDrawer will show exactly what the convex hull is doing.
For a longer term debugging investment, you could also get the BEPUphysicsDrawer from the BEPUphysicsDemos and use it in your own project to do debug visualization and compare it against the graphics.
There might be non-graphical problems involved too, like objects being outside the recommended range of 0.5 to 10 units in any dimension. Usually, it's safe to go beyond this, but staying with in the range gives strong guarantees of stability. Depending on the simulation, you might be able to use individual objects which are hundreds of units across without any problem. Unless your shapes are either very tiny (<0.15 units) or extremely large, I doubt this is the primary explanation for the observed problems.
-
- Posts: 2
- Joined: Sun Dec 11, 2011 3:45 pm
Re: Using ConvexHullShape causes 'strange' effects
Thank you very much for your response. We will be integrating the BEPUphysicsDrawer into our model viewer. That way debugging the generated physics shapes will be quite easy.
As for the center point you seem to be right that we do not compensate the offset correctly. There is some calculation going on but we are not sure if it is correct. Our pipeline developer will check this out soon. Maybe he has some further questions.
Thank you very much
The dev team
Project Longshot
As for the center point you seem to be right that we do not compensate the offset correctly. There is some calculation going on but we are not sure if it is correct. Our pipeline developer will check this out soon. Maybe he has some further questions.
Thank you very much
The dev team
Project Longshot