From: Jasmin Patry <jfpatry@mu...>  20000303 16:47:03

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 thirdparty 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 intersectionofhalfspaces 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 > Tuxsized 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 timestep ODE solver, which takes many steps in general for each rendered frame. > This isn't 'perfect' in a collegecourse 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 userdata 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 (worldspace) 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 offlist, or was that unintentional? > > It was unintentional  I thought I just hit reply...weird. Ok, taking it back to the list... Cheers, Jasmin 
From: Steve Baker <sjbaker1@ai...>  20000318 13:26:06

(Apologies for slow reply  I've been on vacation for two weeks and have >2000 emails to catch up with!) Jasmin Patry wrote: > > 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 thirdparty > library wasn't possible. Prohibiting the use of 3rd party libraries is silly  and nobody could possibly stick to it. What about Mesa? glibc? That's a silly rule. > 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. It shouldn't be too hard. > 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. Yes  you would certainly need to use C++ but since C++ can compile C programs just as well as C can, the implications of switching to C++ is no more than a couple of lines in a Makefile. These days, C compilers are often just C++ compilers with some parts turned off. There is really no need to stick with C anymore. > > 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 > > Tuxsized 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 timestep ODE > solver, which takes many steps in general for each rendered frame. Yep  just try writing code to intersect hemispherecapped cylinders with arbitary geometry! > For testing collisions with the SSG objects, I might instead add > bounding (worldspace) 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?) No  only spheres and lines.  Steve Baker http://web2.airmail.net/sjbaker1 sjbaker1@... (home) http://www.woodsoup.org/~sbaker sjbaker@... (work) 
From: Jasmin Patry <jfpatry@mu...>  20000318 14:57:38

On Sat, 18 Mar 2000, Steve Baker wrote: > (Apologies for slow reply  I've been on vacation for two weeks and > have >2000 emails to catch up with!) Welcome back! I hope your vacation went well. > Jasmin Patry wrote: > > :) Since the game was written as a school project, using a thirdparty > > library wasn't possible. > > Prohibiting the use of 3rd party libraries is silly  and nobody > could possibly stick to it. What about Mesa? glibc? I didn't mean *any* thirdparty library. I meant one whose functionality would overlap with my objectives (i.e., stuff I was supposed to write myself). Cheers, Jasmin 