Path: chuka.playstation.co.uk!news
From: "Nathan Miller" <nmiller@homebrewkungfu.com>
Newsgroups: scee.yaroze.programming.3d_graphics
Subject: Re: race game 3 design: step 1
Date: Wed, 1 Mar 2000 17:46:59 -0800
Organization: PlayStation Net Yaroze (SCEE)
Lines: 66
Message-ID: <89ka7g$6j1@chuka.playstation.co.uk>
References: <38ada944.33392524@www.netyaroze-europe.com> <89hr2n$9dj2@chuka.playstation.co.uk> <38bce729.1480649@www.netyaroze-europe.com>
NNTP-Posting-Host: ABDF962A.ipt.aol.com
X-Newsreader: Microsoft Outlook Express 4.72.3110.1
X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3

I think I didn't explain myself well enough with the previous post.  Let me
try again (and this is LONG)....

You would not need to have a hi and low count model for each piece of track.
Lets say you want those individual pieces of track.  You may do something
like this->

1) Have a spline to represent the track.
2) Create a data structure for widths and banking of the track pieces, lets
say the total track contains 100 segments.
    using this, we could create a link list that looks something like this:

       struct track_piece
        {
            unsigned char ID, bank_angle; (bank angle limited for mem
purpose, could be 256 total steps- also assumes no upside
down pieces)
            int length, width;
            struct track_piece *prev, *next;
        };

    track_piece track;

Let me see, 4 bytes for each pointer and length and width, 1 bytes for id
and bank_angle.  That is a total of 18 I think.  So our track would take 18K
plus the spline and 3 or so track tmds.

Now, that was crude, but it will work for the point.  Since tracks are
linear, we can use the data from the prev track piece as the start of our
current piece.  So we would use track->prev.width to set the current width
of the track.  Then we use track.length and track.bank_angle to flush out
the dimensions of the track.  Now we can work on our track piece.  We
calculate the distance from the viewer and we will call that view_dist.

So we have-

1 view_dist  (used to determine LOD number)
2 prev.width (starting width)
3 curr.width (ending width)
4 curr.length (length of track piece, assuming straight line distance)
5 curr.bank_angle (bank of track on the current direction vector)
6 curve_horz - derived from the spline, the rough estimate of the curve from
the start point to spline+curr.length.
7 curve_vert - derived from the spline in the same manner as above.  Used to
make changes in elevation on the track.

With all of these variables accounted for we can now work on the track
piece.  We could dynamically create the track piece due to the large amount
of variables and calculations involved already.  Or, if we limited our track
design, several of these variables could be deleted and using predefined
pieces would be beneficial.  Also, we could create TMDs to bridge between
two different LODs and reshape them as needed also.

I see where you may want to be dynamic in creation, especially if you wanted
a very stylized track, but if you could limit yourself a little the
calculations would be sped up tremendously and the data structure above
could assist in collision detection.  Anyway, this was just an idea, I hope
it helps some, if only reaffirming your belief in your system.

Have fun coding!

Nathan