Racing game second approach

Hello guys!

So, I am planning on make my own racing game and have a few
questions about
my approach.

The idea is to use 4 ModelsUnderRays, one from each corner
of my car aiming
down towards the ground. These MODs will be used for the car
to follow the
ground and also work for collision detection with other
cars. Before the
MODs are casted everything in the 3Dworld will be removed
except the ground
and one simple #plane for each car (that is located on the
ground beneath
the real cars). If a ray hits one of those planes then it's
a collision with
that car. If the ray doesn't even hit the ground then the
car is outside the
track (i.e hitting a wall or something).

My first question is: Does this sound like a good idea at
all (both
practically and for good performance), or are there any
direct faults that I
haven't thought about (since it's my first 3D game)?
Question two: Is there an easy way to get the position of
each corner of a
#plane?

Thanks!

/KC
_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l

Monday, March 27, 2006, 3:09:59 AM, Karl wrote:

KC> The idea is to use 4 ModelsUnderRays, one from each
corner of my car aiming
KC> down towards the ground. These MODs will be used for
the car to follow the
KC> ground and also work for collision detection with
other cars. Before the
KC> MODs are casted everything in the 3Dworld will be
removed except the ground
KC> and one simple #plane for each car (that is located
on the ground beneath
KC> the real cars)

Instead of removing and replacing models, I strongly advise
you make use of the newer modelsUnderRay method of passing a
list of specific models to check against, in this form:

argList = [#maxNumberOfModels:n,
#levelOfDetail:#detailed,#modelList:modelList]   
rayResult = scene.modelsUnderRay(rayStartPos, rayVector,
argList) 

Where "modelList" is simply a list of models
references to check against.

For my car code, I generally separate up the wall collision,
the floor collision, and the car-car collision into entirely
separate systems. For the floor, I generally cast one ray
downwards, to get the ground's height and angle. If you're
doing 4 raycasts for the purposes of suspension, it might be
worth remmebering that it's only worthwhile to do this for
cars that are near enough to the camera for the effect to be
worth it.

For wall collisions, I generally cast two rays diagonally
forwards, to check for walls, like this:

 
  ray 1      ray 2
    \         /
     \       /
      \ _A__/
       |    |
       |    |
       |    |
       |    |
       |____|

With the rays being cast to the left & right of the
current direction of travel.
 
I add a few tricks to optimise all of this and make sure it
works properly:

1) I specifically designate certain items as being
collidable for 'walls' and other items collidable for
'ground'. This means I can cut down on the objects to
check against for each type of collision.

2) I build a space-partitioned collision tree before play,
which contains references to my static collidable objects
(i.e. the walls & floor). The division can be a simple
evenly spaced grid, or something more fancy like a BSP tree.
The important thing is that it functions as a quick look-up
table of what objects might be collidable within a certain
area of space. You can then easily use the contents of the
correct cells in you tree as the input for the "model
list" parameter for modelsUnderRay, as shown above.

2) all the walls in my scene are 'proxy' walls, which
means they're much simplified versions of the actual 3d
objects. They also often extend up and down an extra
distance than the real visible version of the object, when I
want to make definitely sure a car can't ever go beyond a
barrier (eg, crash barriers around a racetrack).

3) there are no collidable objects that are smaller than the
gap between the rays, at point 'A' on the diagram above,
otherwise they'd be able to embed a certain way into the
car.

4) For the 'forward' wall checks, I use a system which
only casts these rays at variable intervals. The interval is
determined by a number of factors including: how far away
the result of the last wall check was, how far the car has
moved since the last check, how much the direction of
movement has changed since the last check. This means that
as you get closer to a wall, the check intervals become more
frequent - similar to how a bat's sonar noises click mroe
frequently when it flies near objects, if you've ever seen
a nature documentary about bats you might know what I'm
talking about (which is where I got the idea!)

As for the car-car collision, you really shouldn't need to
raycasting at all to do this at all, unless your cars are
particularly unusual shapes. You should be able to perform
what is essentially 2d collision for this (with the
exception being if your cars come way off the ground a lot,
and you want better handling of when one car lands on top of
another!).

If it is safe to assume that your cars can be roughly
approximated to a rectancle shape, or some other simple 2d
polygon, you can use a few simple bits of mathematics to
determine if they are intersecting - check if any point of
one car's rectangle falls 'behind' all the lines that
make up the other car's rectangle (you can use vectors and
the 'dot' function to do this). If a point is found to be
within another car's rectangle, you can use a 'distance
from point to line segment' algorithm to find the distance
you need to mvoe the cars away from each other to resolve
the collision.

Sound complicated, but it'll turn out a lot faster than
using raycasting to detect car-car collisions!


- Ben

_______________________
 duck_at_robotduck.com 
   www.robotduck.com   

_______________________________________________
dirGames-L mailing list  -  dirGames-Lnuttybar.drama.uga.edu
http://nuttybar.drama.uga.edu/mailman/listinfo/dirgames
-l