rec.autos.simulators

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.

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

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.

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

A big timesaver! :)

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.

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/

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).

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.

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/

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

Yep, thats what I meant, directly down in tyre co-ordinates :)

But useless when you want to have the potential of more than one impact
point on your tyre (unless you can see a way??)

Hmmm, I think i need to revisit my quadtree code ;)

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

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.

I'll try and find that paper, do you have it book-marked?

Sounds fun :)

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 :~)

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

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.

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

Sounds like you're at a more advanced stage than me. Think I might just take
you up on that offer of help!

Regards.

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.

...

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/

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).

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/