# How do you treat static worlds in physics sim?

This topic is 4842 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Hi, After seeing some pretty impressive physics demos (b34r, mr.rowl, jakobsen), I noticed that all of them use simple primitives as their dynamic bodies, but all support a complicated mesh for the static world. May I ask how you handle collision detection for such a complicated mesh? Right now, my engine uses a 2D bsp tree as the world. (its a 2d game). basically a wall is defined by a point and a direction. Left of the wall is solid, Right of the wall is space. If given a primitive I can tell you *extremely* quickly whether its colliding with the wall or not, but how do you calculate the collision point and the normal? Especially, if its a point on the wall that's penetrating the body, and not a point on the body that's penetrating the wall. (which you get when you have concave areas on the map). I'd really appreciate a link to a few articles on this, or just some quick tips. Thanks for the help. -Cuppo

##### Share on other sites
One way to do it is to start with a function that gives you the closest point on a shape to another point, which may be anywhere - inside, outside or on the shape border.

So for instance, you could probably easily derive the closest point to a sphere's surface, given the sphere's center and radius.

Solving for this point, and then testing if it is inside the sphere, will give you the penetration depth of the point.

If the point is in the world, you have just solved for world vertex vs sphere.

You can then further extend the idea to capsules, lozenges, OOBBs, or other CONVEX shapes.

For your case, you have a 2d bsp which can define 2d convex regions, or just a series of half-planes that define inside/outside.

So, I would imagine you would need to make some routines that would test whether your convex collision shape penetrated either the wall segment's line or one of its two points, and then get the penetration depth and contact normal.

##### Share on other sites
Quote:
 Original post by CuppoJavaMay I ask how you handle collision detection for such a complicated mesh?

My stuff just puts all the triangles into a loose octree - loose in the sense that each triangle can be in multiple leaf nodes (each triangle has a counter so that it only gets tested once per query).

Then a collision query between a primitive and the mesh turns into multiple collision tests between the primitive and all the triangles whose bounding boxes overlap the primitive's bounding box (or something like that). There's a chapter in GPG4 that descibes how you can flag edges etc of the triangle mesh as concave/convex to make the primitive-triangle tests cheaper.

##### Share on other sites
I thought a loose tree meant that when an entity overlapped the border between leaves, it was only placed in one leaf?

The nice thing about a static world mesh, is that a lot of the calculations for each triangle can be performed once and then cached, which may or may not improve your performance :)

##### Share on other sites
you could also create a separate mesh for just collision data

example, lets say within one of your meshes you have a long raised platform, and for texturing and lighting it looks like this many polygons:

|\|/|\|/|\|/|\|/|\|

you could create a separate mesh consisting of only two polygons

[_________________] ( bisect that to create two triangles )

depending on how you're sorting and testing triangles, the first row would make you do 18 separate tests for collision testing if they're all within the testing boundaries whereas the second one would only be two tests.

Since these triangles are in line on the same plane you will get the exact same result for collision *response* purposes, unless of course you're adding friction and such to individual polygons. Collision Detection math is very time consuming on the CPU so the less tests the better. This way you can have very highly detailed display meshes, and use a much much more degraded collision mesh.

Lets say that you have a room that's essentially a cube. And as you walk around in this cube a light follows you and you're using a GL Light. You will need to tesselate ( have more polygons ) than necessary to draw just a cube. In this cube are maybe two cylindrical pillars that are extremely detailed with geometry imperfections, such as added polygons for cracks.

You don't want to test every one of those polys ( normally ) individually. Lets say the cube was tesselated to 1200 polygons and you have it stored in an octtree. This Octtree may still tell you to test 18 of these polys for collision, and if that pillar mesh is in there it could get even worse.

If you create a separate mesh of the cube that is nothing more than a minimal cube of identical size and position you'll have no more than 12 faces to test against at any given time. Then instead of including your pillars in the collision mesh, store them as "cylinder objects" in a separate file that you do a radius test on. So that if your character/camera's height is between Cyl1->y and Cyl1->y + Cyl1->height, is distance( player, cyl1 ) > radius? if so then there's no possible collision ( only works with axis aligned bounding cylinders ).

my 2cp

private_ctor

1. 1
Rutin
42
2. 2
3. 3
4. 4
5. 5

• 9
• 27
• 20
• 15
• 14
• ### Forum Statistics

• Total Topics
633392
• Total Posts
3011634
• ### Who's Online (See full list)

There are no registered users currently online

×