# Which physics model

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

## Recommended Posts

I've been trying to program a homebrew clone of an F-Zero/Wipeout style game on my Nintendo DS for a while now, and every physics model I use has its disadvantages which I don't really want to settle with. At the moment I'm concentrating on collision detection with the level, and splitting this into 2 parts: 1- Preventing the ship passing through polygons 2- Firing a segment down the ship's -y axis to get the ship's height and rotation I'm having trouble with 1, I'll discuss the problems with each model. 1) Representing the player as a point and drawing a line between the ship's current and future positions, testing this segment against level polygons and moving the player a set distance PROBLEM: The player clips the world, for instance if I have a boundary on the side to stop them falling off the track, half the ship goes through the polygon. 2) Swept-sphere vs triangle PROBLEM: A VERY bad fit, most ships will be long and flat, using a sphere means a lot of wasted space around the ship and collisions with the ground and sides where they shouldn't be happening 3) Swept-OBB vs triangle, very good fit. PROBLEM: Moving around the world is fine, however if the player collides with a polygon and rotates on the same frame, the OBB can go through the polygon. When this happens all you can do is place the OBB past the polygon (so it goes through). Dave Eberly suggested for me to read his article on intersections using OBBs with linear and angular velocities, however before I go off and try another model (I'm a slow coder) I'd like for people to discuss what I SHOULD be doing, and also if this method will solve my problems and its efficiency. Makes me wonder what they did in F-Zero GX!

##### Share on other sites
Assuming your level and ship models are relatively simple, you could basically do (1) but for each of the 'extremities' of the ship. That would be similar to a swept OBB test but it might allow you to work out which part of the ship collided first (and when), and therefore allow you to perform the right response.

For a cuboid you'd use the 8 corners, and therefore collision detection would be 8 times as slow. More complicated ship designs might have more points and therefore require more calculation. This method also has the disadvantage that any small pieces of world map that can slip between the collision points could pass straight through your ship, and therefore it would not be suitable if your world map is of high detail.

##### Share on other sites
Hmm, I was thinking of doing something similar to this too, if the OBB test comes back as overlapped then testing which corner is the deepest and pushing the player out by that much.

##### Share on other sites
You could use an ellipsoid. Ellipsoid-triangle mesh checks are really easy because you just apply a scaling to both such that the ellipsoid becomes a sphere, and the triangles scale in the same way. Sphere-triangle checks are easy.

So long as all ships are the same shape (approx) then ellipsoid-ellipsoid checks are easy because you just scale them both into spheres. If you have different sized ships, then this would be a problem (sphere-ellipsoid check is actually a bit nasty)

I imagine an ellipsoid could fit a ship reasonably well - so you squash a sphere vertically and stretch it along the length of the ship.

There's a fair bit of info about this since it's used for character movement too - e.g. try this.

##### Share on other sites
I did also think of an ellipsoid (it was also mentioned to me in another post before) but would an ellipsoid be susceptible to the same problem I'm currently having with the OBB tests? Namely that rotating the OBB makes it start off overlapping a triangle and the only way to respond to that is to make it go through the triangle.

Article does looks interesting, I'll take a good look at it

##### Share on other sites
Quote:
 Original post by RajveerI did also think of an ellipsoid (it was also mentioned to me in another post before) but would an ellipsoid be susceptible to the same problem I'm currently having with the OBB tests? Namely that rotating the OBB makes it start off overlapping a triangle and the only way to respond to that is to make it go through the triangle.

Yes - but I don't think that's a problem because:

1. You're unlikely to rotate more than a few degrees between updates, and

2. It's quite easy to write code that "pushes" an ellipsoid out of a triangle if it does intersect.

So if you're using swept tests that would prevent intersection in the absence of rotation, then the intersection that you do get due to rotation will be small. And, importantly, rotating will never take the ellipsoid center from one side of the triangle to the other, so it will not result in you pushing the ellipsoid the wrong way.

##### Share on other sites
Great article, I've read and learned some things that I should have been doing before, like treating the collision function as a recursive one and doing it multiple times.

A quick question before I go off and change my collision routines to ellipsoid ones, I'm going to try sticking with my working swept-OBB. The only problem I'm having is coming up with a suitable sliding plane if the OBB intersects the edge of a triangle, would it simply be the plane of the first edge of the OBB intersecting the tri?

1. 1
Rutin
38
2. 2
3. 3
4. 4
5. 5

• 11
• 9
• 12
• 14
• 9
• ### Forum Statistics

• Total Topics
633350
• Total Posts
3011470
• ### Who's Online (See full list)

There are no registered users currently online

×