Is there a recommended way to handle static level geometry in Bullet? I'm not sure whether I should use box shapes (and some convex hull shapes) or a triangle mesh shape.
My kinematic character controller works reasonably well with boxes, but there's a couple of issues when using triangle mesh shape and InternalEdgeUtility. I haven't figured out if they are problems with my code, the port, or InternalEdgeUtility. So if it happens to be the case that box shapes are the way to go, that would probably save me a considerable amount of debugging. One potential downside to the box shape approach is that it seems like creating a level with box shapes would be more time consuming.
If I were to use box shapes, how should I handle when walls intersect at non-right angles. Should I try to avoid overlap between the walls, which may require using convex hull shapes in some cases? Or is it not a problem?
[Bullet] Static level geometry - boxes or triangle mesh?
I use a tri-mesh for my level geometry (subdivided into mulitple meshes) without any problems. The problem with boxes is, that bullet need to manage each box as individual object, whereas a tri-mesh is a single object.
I'm afraid there's no well-established way demonstrated to be superior.
I use an assembly of simple collision shapes. In my current dataset, it's probably about 70% boxes, 20% hulls and 5% spheres. I must say that my current dataset is pretty much ideal. Back when I used a more generic one to stress the workflow, it was about 90% hulls and 10% boxes. Unfortunately, I have no recent performance data but I'm inclined to overuse the broadphase first.
Did you manage to make [font=courier new,courier,monospace]InternalEdgeUtility [/font]work? It doesn't do anything for me. Not even in the demo!
I use an assembly of simple collision shapes. In my current dataset, it's probably about 70% boxes, 20% hulls and 5% spheres. I must say that my current dataset is pretty much ideal. Back when I used a more generic one to stress the workflow, it was about 90% hulls and 10% boxes. Unfortunately, I have no recent performance data but I'm inclined to overuse the broadphase first.
Did you manage to make [font=courier new,courier,monospace]InternalEdgeUtility [/font]work? It doesn't do anything for me. Not even in the demo!
If I were to use box shapes, how should I handle when walls intersect at non-right angles. Should I try to avoid overlap between the walls, which may require using convex hull shapes in some cases? Or is it not a problem?What is your concern? Static geometry can encroach as you want, at worse, collision pairs will be somewhat redundant, it's not much of a big problem as - in the end - one of the two contact points will get filtered away. I'm interested in understanding your question.
In general it is faster to check for collisions against boxes, spheres, and convex hulls than triangle meshes.
You should use triangle collision tests only when absolutely necessary.
L. Spiro
You should use triangle collision tests only when absolutely necessary.
L. Spiro
Use a triangle mesh, or experiment with using more smaller triangle meshes. Using boxes for level geometry will be a pain and it will restrict you too much on the level design part.
All physics engines use some kind of an algorithm that speeds up static triangle mesh collision a lot.
All physics engines use some kind of an algorithm that speeds up static triangle mesh collision a lot.
Author
Thanks for the suggestions, everyone. I guess for now I'll spend some time looking at my triangle mesh code to see if I can work out the issues.
Heh, depends on your definition of "work". I got it to prevent the player from being able to stand on the diagonal of slopes that should be too steep to stand on, but it seems to have introduced a couple of other problems. The player can't walk off some edges, and when jumping straight up in a corner formed by short walls the player starts teleporting up and down. I'll try another port and see if I get the same behavior as a start. I've not run the demo yet, so I should probably do that too.
Yes, that answers my question, thank you.
Did you manage to make InternalEdgeUtility work? It doesn't do anything for me. Not even in the demo!
Heh, depends on your definition of "work". I got it to prevent the player from being able to stand on the diagonal of slopes that should be too steep to stand on, but it seems to have introduced a couple of other problems. The player can't walk off some edges, and when jumping straight up in a corner formed by short walls the player starts teleporting up and down. I'll try another port and see if I get the same behavior as a start. I've not run the demo yet, so I should probably do that too.
What is your concern? Static geometry can encroach as you want, at worse, collision pairs will be somewhat redundant, it's not much of a big problem as - in the end - one of the two contact points will get filtered away. I'm interested in understanding your question.
Yes, that answers my question, thank you.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
