[tuxracer-devel] Re: Polygonal objects.

[Jasmin P. <jf...@mu...>]

On Fri, 3 Mar 2000, Steve Baker wrote:

> Jasmin Patry wrote:
> > 
> > Ah, very cool.  I hope to check out PLIB over the weekend -- I'd
> > already been meaning to look at it for its text capabilities.
> 
> ...and GUI, sound and music :-)

:-)  Since the game was written as a school project, using a third-party
library wasn't possible.  I'm encouraged by your description of how SSG
works -- it doesn't sound like it will be hard to use it to insert
additional objects into the track.  

Do you foresee any problems caused by the fact that PLIB/SSG is C++ and
Tux Racer is written in C?  I'll have to include at least some C++, I
guess, for the classes in SSG that I subclass, but I should be able to
abstract the functionality that I use SSG for behind a C interface.

> > I take that back -- convex polyhedra aren't really necessary in a game
> > context.  I was thinking of a general collision detection algorithm --
> > to be able to use the intersection-of-halfspaces approach to handle
> > the case in which one object is completed contained inside the other,
> > the objects must be convex.  In a game where the time steps small, an
> > object will almost surely intersect the boundary of the other object
> > first, so the approach you describe below is fine.
> 
> Yes - it's also possible to intersect a bunch of lines that start at the
> position of tux at the beginning of the frame and end at the position
> he hopes to be at at the end of the frame.  Using a set of lines that
> outline his profile, you could even use my approach to detect high
> time step motion.
> 
> In my Tux game, I did get problems with a fast moving Tux starting the
> frame completely on one side of a polygon - and ending it completely
> on the other.  To fix that, I intersect a bunch of slightly overlapping
> Tux-sized spheres at intervals along his motion.

Right, I had problems with this too. The correct way to do it in Tux Racer
would be to stretch out each sphere into a cylinder with hemispherical
ends, but instead I basically use the approach you use: the set of
physics equations in Tux Racer is solved using a variable time-step ODE
solver, which takes many steps in general for each rendered frame.

> This isn't 'perfect' in a college-course kind of a way - but it's pretty
> good for things like video games where people are quite tolerant of
> small problems.

Yes.

> In PLIB/SSG, a "material" is represented by a class derived from 'ssgState'
> (which represents the OpenGL state required to render polygons with that
> material).  Currently, ssgState is an abstract base class with the only
> commonly used concrete derivced class being ssgSimpleState.
> 
> When you do an intersect test, you get back a pointer to the ssgLeaf node
> that you collided with. There is API for ssgLeaf to fetch it's ssgState -
> if that's not enough, you can attach a user-data structure to
> ssgState\which could contain stuff like your friction coefficient.
> 
> In my Tux game, it contains friction (I have slippery ice too) - and
> also things like temperature (Tux gets hot if he stands too long near
> to hot lava - and has to walk into a nice cold refrigerator to cool
> down).  I also have a 'lethality' field so that the mouth polygons of
> the Killer Whale can marked as being basically fatal for small
> Penguins.

Yup, that sounds great.

> > My collision detection is a bit more complicated; I check for
> > collisions with each part of Tux's body.  Instead of checking each
> > triangle that makes up Tux, though -- that would be horribly slow -- I
> > transform the object I'm testing down the tree structure representing
> > Tux.  Each leaf of the tree is a unit sphere, centered at the origin,
> > and it's easy to check for a collision between this sphere and an
> > arbitrary polyhedron.  This is reasonably fast currently because the
> > polyhedrons are octahedrons (the trees).
> 
> Wow!  That's pretty fancy.

It gives pretty accurate collisions.  The idea is just an extension
of the ray intersection code for a ray tracer I wrote -- as you traverse
the hierarchical model, you need to transform the ray using the inverse
of the transforms stored in each node, and then do the intersection in
model space.  

For testing collisions with the SSG objects, I might instead add
bounding (world-space) spheres to the Tux model, and then perform
collision tests with each of these spheres.  That should give reasonably
accurate collisions.  (Or can SSG do the intersection tests with
arbitrary ellipsoids?)

> > P.S. Any reason why this was taken off-list, or was that unintentional?
> 
> It was unintentional - I thought I just hit reply...weird.

Ok, taking it back to the list...

Cheers,
Jasmin