Wheel to track collision detection

Hi all, A long time ago I was playing around with creating a car sim project, but got sidetracked by other things :-( Anwyay, I'm back to looking at it again now, and I have one question that is currently bugging me. How do you determine and handle the collision between a wheel and the track? If the road is a completely flat surface, then I guess it would be quite a simple "hack" to keep the Y-axis of the wheel constant so it won't move up or down. But I want to be able to drive up hills, on slopes, etc or do take off (in the event of hitting a ramp!). So, how to do it? Any pointers? Cheers, Nick.

> If the road is a completely flat surface, then I guess it would be > quite a simple "hack" to keep the Y-axis of the wheel constant so it > won't move up or down. But I want to be able to drive up hills, on > slopes, etc or do take off (in the event of hitting a ramp!). So, how > to do it? With great difficulty :-) What needs to be there is rigid body dynamics, to allow the car to twist and spin and leave the ground, and collide. Then you need to have a polygon collision detection system to test where the road and other objects are. The two go together. It is best to start with rigid body dynamics first, then move to collision detection. It is pretty complicated stuff though, and I am in the phase of doing this myself. At the moment just a simple 2D rigid body application, which I'm having problems with, so 3D isn't achievable for me just yet :( Do a search for "rigid body" or "Chris Hecker" on google, he has written some articles about it which I am using to develop such a system (though not with great success at the moment!) Regards

I've done rigid body dynamics before, and wrote a simple physics engine, but I am wondering if there is any "quick" way of keeping the wheels above the track, rather than doing point in poly detection. The problem I had when developing my physics engine was that to find the collision point I was sub-dividing the time-step and this caused it to slow down quite a bit. So I was just wondering if there is some "quick n easy" way of doing it. What I thought of last night was to find that the wheel was penetrating the surface, and then work out how much it was penetrating by. Once I've found that, I simply set the wheel to be not penetrating and use that offset to determine the amount of force on the suspension..... It would probably be easier to explain if I could draw a diagram, but my ASCII art isn't that good ;-) Oh, and if you want some help with your rigid body application, drop me an email and I'll see if I can help. Nick. "Alex Smith" <[email hidden]> wrote in message news:<b1p6cc$d3l$[email hidden]>...

Quoted text (27 lines)

> > If the road is a completely flat surface, then I guess it would be > > quite a simple "hack" to keep the Y-axis of the wheel constant so it > > won't move up or down. But I want to be able to drive up hills, on > > slopes, etc or do take off (in the event of hitting a ramp!). So, how > > to do it? > > With great difficulty :-) > > What needs to be there is rigid body dynamics, to allow the car to twist and > spin and > leave the ground, and collide. Then you need to have a polygon collision > detection > system to test where the road and other objects are. The two go together. > It is best to start with rigid body dynamics first, then move to collision > detection. > It is pretty complicated stuff though, and I am in the phase of doing this > myself. > At the moment just a simple 2D rigid body application, which I'm having > problems > with, so 3D isn't achievable for me just yet :( > > Do a search for "rigid body" or "Chris Hecker" on google, he has written > some > articles about it which I am using to develop such a system (though not with > great success at the moment!) > > Regards

Hi Nick, Here is what I have done as a first draft: - - I have the track split up into a quadtree - For each face i have a bounding circle (the track is essentially 2d after all) - this is used for a very quick rejection test - I have a ray going from the tyre centre directly downwards. - Store the last hit triangle for each tyre. Ok, so this is what i do, - First of all check if we are hitting the last triangle for this tyre ...if so we are finished! - If not, go through all the tri's in the current quad doing a circle / point test (i.e. the bounding circle from the triangle face and the Contact Point of the tyre) - If the circle / point test succeeds then we do a triangle / ray test. This will return the depth that we have sunk into the ground (think of this as the compression of the tyre). - Use this depth to calculate a spring force that pushes the tyre up...hey presto we have a tyre that will react to changes in terrain. :) Of course this is for poly collision, which is just plain wrong for racing sims - F12002 got away with it though :). You will be wanting to investigate splines and patches in the future. I hope this helps, All the best, Ash http://www.siroccoracing.com

On Wed, 5 Feb 2003 10:45:14 -0000, "Ashley McConnell" <[email hidden]> wrote: >- I have the track split up into a quadtree >- For each face i have a bounding circle (the track is essentially 2d after >all) - this is used for a very quick rejection test >- I have a ray going from the tyre centre directly downwards. You may also want to use a ray that uses the tire direction. In other words, the car's body direction more or less (skipping camber effects). If you have a car orientation matrix, it's just the Y vector from that matrix. >- Store the last hit triangle for each tyre. A big timesaver! :)

Quoted text (10 lines)

>Ok, so this is what i do, > >- First of all check if we are hitting the last triangle for this tyre ...if >so we are finished! >- If not, go through all the tri's in the current quad doing a circle / >point test (i.e. the bounding circle from the triangle face and the Contact >Point of the tyre) >- If the circle / point test succeeds then we do a triangle / ray test. >This will return the depth that we have sunk into the ground (think of this >as the compression of the tyre).

If it does not, you may want to try the node one level up. In Racer, when I get no cached-triangle hit, I dive completely anew into the quadtree. Faster is probably to try the enclosing node first. >Of course this is for poly collision, which is just plain wrong for racing >sims - F12002 got away with it though :). You will be wanting to >investigate splines and patches in the future. Indeed, and that's a whole creative area out there (as the splines and polygons won't match up completely, so you might have to trace twice to match polygon hit vs. patch hit upto a certain error boundary). Patches are useful anyway; they give UV coordinates, useful for directions, AI, car ordering, left-right distances etc. Cheerio, Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On 5 Feb 2003 01:10:45 -0800, [email hidden] (Nick Bull) wrote: >I've done rigid body dynamics before, and wrote a simple physics >engine, but I am wondering if there is any "quick" way of keeping the >wheels above the track, rather than doing point in poly detection. With a quadtree/octree (any-tree) and a simple triangle-ray intersection algorithm (available on the net) things are not really that bad (read: slow). Since tracks are mostly 2D, often you can get away with quadtrees (unless perhaps loopings are prominent). >The problem I had when developing my physics engine was that to find >the collision point I was sub-dividing the time-step and this caused >it to slow down quite a bit. Don't. Just set either the wheel height to match the track height (compressing the suspension, as it seems some arcade games do), or use the penetration depth as the tire spring force, as Ash proposed. >So I was just wondering if there is some "quick n easy" way of doing >it. What I thought of last night was to find that the wheel was >penetrating the surface, and then work out how much it was penetrating >by. Once I've found that, I simply set the wheel to be not >penetrating and use that offset to determine the amount of force on >the suspension..... You might just move the wheel (massless wheel) and let the suspension do its thing on the car body with its new compression length. Cheers, Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

"Ashley McConnell" <[email hidden]> wrote in message news:<b1qqa3$srd$[email hidden]>...

Quoted text (33 lines)

> Hi Nick, > > Here is what I have done as a first draft: - > > - I have the track split up into a quadtree > - For each face i have a bounding circle (the track is essentially 2d after > all) - this is used for a very quick rejection test > - I have a ray going from the tyre centre directly downwards. > - Store the last hit triangle for each tyre. > > Ok, so this is what i do, > > - First of all check if we are hitting the last triangle for this tyre ...if > so we are finished! > - If not, go through all the tri's in the current quad doing a circle / > point test (i.e. the bounding circle from the triangle face and the Contact > Point of the tyre) > - If the circle / point test succeeds then we do a triangle / ray test. > This will return the depth that we have sunk into the ground (think of this > as the compression of the tyre). > - Use this depth to calculate a spring force that pushes the tyre up...hey > presto we have a tyre that will react to changes in terrain. :) > > > Of course this is for poly collision, which is just plain wrong for racing > sims - F12002 got away with it though :). You will be wanting to > investigate splines and patches in the future. > > I hope this helps, > > All the best, > Ash > http://www.siroccoracing.com

Pretty much same here.. I don't bother with quadtree ATM. I have a "sector" organization, object naming in the track tells the game who's eligible for "ground" collisions. All the "ground" triangles are stored in a sector buffer ordered by type.. that is, road first, then kerbs, then grass/sand... so we get the best possible performance when we're on the track. Tyres are storing the last triangle just like Ashley. Then: 1 - Check the last triangle if it fails, check the triangles in the sector, if it fails check the next sector, if it fails check the last sector (here "last" and "next" means in the sectors list)... if it fails again curse the world and check all the sector blindly. 2 - If it's a "road" triangle get the "smoothed" collision point. Im using an automatic system derived from a paper I found on gamasutra about triangles bezier patches.. not related to collisions.. but it just fired the idea. This "auto-smooth" can be overridden by a spline patch "a-la-Racer" that I'm using for critical corners (ATM just for Spa-Eau Rouge... geez all that code for one corner :-( ) I'm investigating a further optimization that could really make it VERY fast.. the idea is to store the 3 neighbour triangles for triangle.. if the tyre's not on the last triangle must be around somewhere close... Once you've found the collision point and the collision depth.. that's easy.. get the spring and damp for the tyre and let the physic engine do the rest.. Hope it helps.. Now back to smoothing algorithms for network multiplay.. it'd be great to share some ideas here.. Ashley, Ruud.. Colin.. if he's still around (I know he is, I saw some posts on West's forum)... what about Mr.Randy Cassidy expaining how that's done in Nascar2002??? :-D

> You may also want to use a ray that uses the tire direction. In other > words, the car's body direction more or less (skipping camber > effects). > If you have a car orientation matrix, it's just the Y vector from that > matrix. > Yep, thats what I meant, directly down in tyre co-ordinates :) > >- Store the last hit triangle for each tyre. > > A big timesaver! :) But useless when you want to have the potential of more than one impact point on your tyre (unless you can see a way??) > If it does not, you may want to try the node one level up. In Racer, > when I get no cached-triangle hit, I dive completely anew into the > quadtree. Faster is probably to try the enclosing node first. Hmmm, I think i need to revisit my quadtree code ;) > Indeed, and that's a whole creative area out there (as the splines and > polygons won't match up completely, so you might have to trace twice > to match polygon hit vs. patch hit upto a certain error boundary). This will make track creation alot harder I would think? I havent really looked into getting patches out of max / 3ds (or for that matter .x files). I live in a polygon world and I am a polygon girl.....ahem....oops :D All the best, Ash http://www.siroccoracing.com

Thanks for the response. That kind of makes sense to me. I think I'll have to re-read it and think about it later (when I'm not at work!). The thing that I've been worried about is responding to the change in terrain quick enough to avoid penetrating right through the track. I suppose really, the contact point of the wheel is different to the contact point of the tyre. Therefore.... If the detection realised that the tyre was penetrating the road, then the tyre could be "squished" that amount to make sure it was always above the road, and this would cause a force upwards on the centre of the wheel, which would then cause it to ride above the road.... Hmmmmm..... I think I'll have to put some thought into this tonight. Thanks, nick. "Ashley McConnell" <[email hidden]> wrote in message news:<b1qqa3$srd$[email hidden]>...

Quoted text (33 lines)

> Hi Nick, > > Here is what I have done as a first draft: - > > - I have the track split up into a quadtree > - For each face i have a bounding circle (the track is essentially 2d after > all) - this is used for a very quick rejection test > - I have a ray going from the tyre centre directly downwards. > - Store the last hit triangle for each tyre. > > Ok, so this is what i do, > > - First of all check if we are hitting the last triangle for this tyre ...if > so we are finished! > - If not, go through all the tri's in the current quad doing a circle / > point test (i.e. the bounding circle from the triangle face and the Contact > Point of the tyre) > - If the circle / point test succeeds then we do a triangle / ray test. > This will return the depth that we have sunk into the ground (think of this > as the compression of the tyre). > - Use this depth to calculate a spring force that pushes the tyre up...hey > presto we have a tyre that will react to changes in terrain. :) > > > Of course this is for poly collision, which is just plain wrong for racing > sims - F12002 got away with it though :). You will be wanting to > investigate splines and patches in the future. > > I hope this helps, > > All the best, > Ash > http://www.siroccoracing.com

Quoted text (7 lines)

> > 2 - If it's a "road" triangle get the "smoothed" collision point. Im > using an automatic system derived from a paper I found on gamasutra > about triangles bezier patches.. not related to collisions.. but it > just fired the idea. This "auto-smooth" can be overridden by a spline > patch "a-la-Racer" that I'm using for critical corners (ATM just for > Spa-Eau Rouge... geez all that code for one corner :-( )

I'll try and find that paper, do you have it book-marked? > > I'm investigating a further optimization that could really make it > VERY fast.. the idea is to store the 3 neighbour triangles for > triangle.. if the tyre's not on the last triangle must be around > somewhere close... > Sounds fun :) > Now back to smoothing algorithms for network multiplay.. it'd be great > to share some ideas here.. Ashley, Ruud.. Colin.. if he's still around > (I know he is, I saw some posts on West's forum)... what about > Mr.Randy Cassidy expaining how that's done in Nascar2002??? :-D Yeah randy.....quit hogging the knowledge :)) I have just yesterday sent my first network packet with car position and orientation, I havent quite got the network cars drawing on the screen - but i have all the packets sending nicely :). I'll probably leave it unsmoothed for a while yet until I bring some of the rest of my sim up to standard. If you find anything interesting, let us know! :)) All the best, Ash http://www.siroccoracing.com PS. Its nice to have a physics thread again :~)

On Wed, 05 Feb 2003 13:02:40 GMT, [email hidden] (Ruud van Gaal) wrote:

Quoted text (10 lines)

>On 5 Feb 2003 01:10:45 -0800, [email hidden] (Nick Bull) wrote: > >>I've done rigid body dynamics before, and wrote a simple physics >>engine, but I am wondering if there is any "quick" way of keeping the >>wheels above the track, rather than doing point in poly detection. > >With a quadtree/octree (any-tree) and a simple triangle-ray >intersection algorithm (available on the net) things are not really >that bad (read: slow). Since tracks are mostly 2D, often you can get >away with quadtrees (unless perhaps loopings are prominent).

I'm suing OBBTree, Oriented Bounding Box Tree, to store scene informations . Scene are made of triangles soups, boxes, and ellipsoid. The specification off OBB is that its the minimal bounding volume. So if theres intersection with OBB theres 99% chance that u intersect whats it's in the OBB. All my objects are made with OBBTree. The i had a intersection test between 2 OBBTrees. At the end i have a list of couple of things to test : triangle vs triangle , ray vs triangle, ray vs box etc... My cars are made of boxes and ellpsoids and 4 rays for the wheels. As OBB vs OBB test are VERY fast, and are minimum bounding volumes, there's a lot of intersection rejected without any CPU problem. For exemple , in VR3, got tracks of 65000*15 triangles and 1000*15 boxes or ellipsoid and it takes 8% of PS2 to test ALL intersections contacts with the car at 100hz. U can easly find Obb vs Obb intersection using separated axis theoreme. regards, Sebastien TIXIER - Game Developer Dynamics and Car Physics http://www.eden-studios.fr GPLRank Normal:-44.24 Monster:-124.44 LFS GTI Online 1:31:02 LFS GTI Offline (HLVC) 1:31:38

On Wed, 5 Feb 2003 16:07:37 -0000, "Ashley McConnell" <[email hidden]> wrote: >> I'm investigating a further optimization that could really make it >> VERY fast.. the idea is to store the 3 neighbour triangles for >> triangle.. if the tyre's not on the last triangle must be around >> somewhere close... >Sounds fun :) We used a similar stuff on V-Rally2. All area where cars could ride where made of a regular meshes . So we know wheels positions on the regular meshe wirh row and columns. Then these infos were cached for next frame. Knowing wheel velocity we could easly reduce the number of quad in the regular meshe to test from the cached position. We didn't keep this for V-Rally3 because it's was too much constraint for or graphists :( grrrr... to bad, the OBBTree is way slower :( >> Now back to smoothing algorithms for network multiplay.. it'd be great >> to share some ideas here.. Ashley, Ruud.. Colin.. if he's still around >> (I know he is, I saw some posts on West's forum)... what about >> Mr.Randy Cassidy expaining how that's done in Nascar2002??? :-D you must use quaternions for car oriention, because 1) its heavyly compressable 2) interpolation between 2 quaternion is easy and very smooth when its realy awfull with matrices. >PS. Its nice to have a physics thread again :~) As i start a new project at work with new physics stuff , i'll certainly asks some questions too in the future :) regards, Sebastien TIXIER - Game Developer Dynamics and Car Physics http://www.eden-studios.fr GPLRank Normal:-44.24 Monster:-124.44 LFS GTI Online 1:31:02 LFS GTI Offline (HLVC) 1:31:38

> Oh, and if you want some help with your rigid body application, drop > me an email and I'll see if I can help. Sounds like you're at a more advanced stage than me. Think I might just take you up on that offer of help! Regards.

On Wed, 5 Feb 2003 16:07:37 -0000, "Ashley McConnell" <[email hidden]> wrote: >> 2 - If it's a "road" triangle get the "smoothed" collision point. Im >> using an automatic system derived from a paper I found on gamasutra >> about triangles bezier patches.. not related to collisions..... >I'll try and find that paper, do you have it book-marked? I think that's: http://www.gamasutra.com/features/20020715/mollerhaines_01.htm >> I'm investigating a further optimization that could really make it >> VERY fast.. the idea is to store the 3 neighbour triangles for >> triangle.. if the tyre's not on the last triangle must be around >> somewhere close... > >Sounds fun :) Note that you might have to store 6 tris or sometimes even more; the edges only make 3 polygons but the vertices may be shared with more than 3 triangles. ... >I have just yesterday sent my first network packet with car position and >orientation, I havent quite got the network cars drawing on the screen - but >i have all the packets sending nicely :). Sounds cool. :) The big problem with network code it seems isn't so much the communication; it's syncing the lot, and deciding who's boss and how events are to be distributed. And keeping bandwidth low. Endless possibilities here to compress or limit your data. :( Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On 5 Feb 2003 06:57:58 -0800, [email hidden] (Stefano Casillo) wrote: >"Ashley McConnell" <[email hidden]> wrote in message news:<b1qqa3$srd$[email hidden]>...... >2 - If it's a "road" triangle get the "smoothed" collision point. Im >using an automatic system derived from a paper I found on gamasutra >about triangles bezier patches.. not related to collisions.. but it >just fired the idea. This "auto-smooth" can be overridden by a spline >patch "a-la-Racer" that I'm using for critical corners (ATM just for >Spa-Eau Rouge... geez all that code for one corner :-( ) Does the automatic system overshoot it's smoothness? Seems a shame to need a spline system on top of the automatic system indeed. Gregor uses an automatic normal system as well; it took him quite a bit of time to get right (if he ever really got it right). >I'm investigating a further optimization that could really make it >VERY fast.. the idea is to store the 3 neighbour triangles for >triangle.. if the tyre's not on the last triangle must be around >somewhere close... When hitting kerbs at speed this may still not work and cause a bit of a slowdown. In the end, a tree would help in those cases to keep CPU time down a bit (although I must say it's not bad, even at my ancient PII-400). >Now back to smoothing algorithms for network multiplay.. it'd be great >to share some ideas here.. Ashley, Ruud.. Colin.. if he's still around >(I know he is, I saw some posts on West's forum)... what about >Mr.Randy Cassidy expaining how that's done in Nascar2002??? :-D I'm still doing some bugsquashing, but my idea is to make something like a 'timed' thing to get all computers to have a pretty good idea of what the server time is. And interpolate/extrapolate from there with the orientation quaternions and linear accelerations of the cars. At 20Hz, things are not that bad, even with jumping. And probably big positions offsets should be ignored or something. I think it will mostly depend on tests and visually checking how things look, before I delve into intricate systems. Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On Wed, 05 Feb 2003 17:56:00 +0100, Sebastien Tixier <stixier@wanadoo[NO_SPAM].fr> wrote: ... >The i had a intersection test between 2 OBBTrees. At the end i have a >list of couple of things to test : triangle vs triangle , ray vs >triangle, ray vs box etc... Do you have a triangle vs box one? I still have problems generating (enough) contact points for those. >As OBB vs OBB test are VERY fast, and are minimum bounding volumes, >there's a lot of intersection rejected without any CPU problem. Interesting stuff... It's that I suck at rallying on consoles, otherwise I'd play VR3 a bit more. :) (it looks very good) Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On Wed, 5 Feb 2003 15:01:00 -0000, "Ashley McConnell" <[email hidden]> wrote: >> If you have a car orientation matrix, it's just the Y vector from that >> matrix. > >Yep, thats what I meant, directly down in tyre co-ordinates :) Ah, hehe, ofcourse. :) >> >- Store the last hit triangle for each tyre. >> >> A big timesaver! :) > >But useless when you want to have the potential of more than one impact >point on your tyre (unless you can see a way??) If you mean the left & right side of the tire, there's a big chance they'll hit the same tri as well. Or you could force it to. ;-) (just hit the tri's plane to come up with left/right approximations instead of really raytracing multiple times; good enough for temperature stuff I'd guess). >> If it does not, you may want to try the node one level up. In Racer, >> when I get no cached-triangle hit, I dive completely anew into the >> quadtree. Faster is probably to try the enclosing node first. > >Hmmm, I think i need to revisit my quadtree code ;) It's not that much to incorporate I think; in case of a miss, try the enclosing node. If not, shoot down the entire tree again. Something creative like that. >> Indeed, and that's a whole creative area out there (as the splines and >> polygons won't match up completely, so you might have to trace twice >> to match polygon hit vs. patch hit upto a certain error boundary). > >This will make track creation alot harder I would think? I havent really >looked into getting patches out of max / 3ds (or for that matter .x files). No, I create patches (admittedly helped by TrackEd) from the polygonal data. Those are combined to give a 3D Catmull Rom patch. So I have a bunch of left-right lines, which define the control points of the patch. No need to get this info directly from Max. >I live in a polygon world and I am a polygon girl.....ahem....oops :D Hm? I thought you were the droid from Aliens. ;-) Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On 5 Feb 2003 07:17:30 -0800, [email hidden] (Nick Bull) wrote: >The thing that I've been worried about is responding to the change in >terrain quick enough to avoid penetrating right through the track. That depends mostly on your physics rate. At 1000Hz, things like diving through the track don't happen all that quickly. Also note that my rays do start about 1m above the wheel (and point downwards) to indeed avoid starting *below* the road (and missing it). Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/

On Thu, 06 Feb 2003 15:09:29 GMT, [email hidden] (Ruud van Gaal) wrote:

Quoted text (10 lines)

>On Wed, 05 Feb 2003 17:56:00 +0100, Sebastien Tixier ><stixier@wanadoo[NO_SPAM].fr> wrote: > >... >>The i had a intersection test between 2 OBBTrees. At the end i have a >>list of couple of things to test : triangle vs triangle , ray vs >>triangle, ray vs box etc... > >Do you have a triangle vs box one? I still have problems generating >(enough) contact points for those.

yep , hmm, have to go home send me an email tomorow and i'll send you one :) Sebastien TIXIER - Game Developer Dynamics and Car Physics http://www.eden-studios.fr GPLRank Normal:-44.24 Monster:-124.44 LFS GTI Online 1:31:02 LFS GTI Offline (HLVC) 1:31:38

>Ruud van Gaal" <[email hidden]> wrote in messagenews:[email hidden]...

Quoted text (9 lines)

> On 5 Feb 2003 07:17:30 -0800, [email hidden] (Nick Bull) wrote: > > >The thing that I've been worried about is responding to the change in > >terrain quick enough to avoid penetrating right through the track. > > That depends mostly on your physics rate. At 1000Hz, things like > diving through the track don't happen all that quickly. > Also note that my rays do start about 1m above the wheel (and point > downwards) to indeed avoid starting *below* the road (and missing it).

What happens if the car turns upside down?

On Thu, 6 Feb 2003 20:27:04 +0000 (UTC), "Alex Smith" <[email hidden]> wrote:

Quoted text (13 lines)

>>Ruud van Gaal" <[email hidden]> wrote in message >news:[email hidden]... >> On 5 Feb 2003 07:17:30 -0800, [email hidden] (Nick Bull) wrote: >> >> >The thing that I've been worried about is responding to the change in >> >terrain quick enough to avoid penetrating right through the track. >> >> That depends mostly on your physics rate. At 1000Hz, things like >> diving through the track don't happen all that quickly. >> Also note that my rays do start about 1m above the wheel (and point >> downwards) to indeed avoid starting *below* the road (and missing it). > >What happens if the car turns upside down?

The box of the car body will prevent the car from sinking into the road. At that point, the tires don't matter anymore. Ruud van Gaal Free car sim: http://www.racer.nl/ Pencil art : http://www.marketgraph.nl/gallery/