GPL Track Creating - Altitudes and Traces

From Grand Prix Legends Wiki
Revision as of 07:00, 24 April 2009 by David Fletcher (Talk | contribs)

Jump to: navigation, search

Authored by the GPLEA

Overview

In this tutorial I will try to explain how to make elevation changes in GPL-tracks. Therefore I will start by writing a little theoretic part about the structuring of altitudes in GPL. This is followed by a close inspection of the formulae that are used in altitude definitions. After this, we should be able to explain the working of the XLS sheets, and how to import and export stuff in there. By then you will have learned enough to start messing around with it in a track, so you might want to have some tips about the use of altitudes on camber, kerbs, roadsurface, hills and so on. This is concluded with a list of DO's and DON'T's, and a list of frequently asked questions on this subject.

Introduction

Welcome to the Altitude Tutorial. I hope to guide you to being able to modify GPL tracks so that your tracks have nice elevations, banking, kerbs and hills and so on. For this it is necessary to have a little background in the fileformat, for which you will need some basic maths. With a few tips and an explanation of the tools used, I think you should be well on your way to make a track with nice elevations.

Credits

The whole business of editing tracks the way we do it, would never be possible without the dedication and labour of Phil "Guru" Flack, who started researching the GPL track-file format a long time ago, persisted when others gave up, and now can sit back and enjoy all tracks that are created using his tools, by people who may never know what a hexeditor is for. Furthermore I'd like to thank Paul Hoad for his part in making editors for GP2 and GPL. And last but not least Randy Cassidy, Dave Kaemmer and all the guys at Papyrus that gave us what I consider the best piece of software I've ever used. I could go on and on about how much I love it, but I think the time dedicated to so many people to learn GPL, and make additions to it, gives a much clearer signal.

Theory

In GPL the altitudes of the track are defined by traces. You should see a trace as a line that runs parallel to the centreline of the track. The trace follows its own up-and-down path, independent of other traces. The drivable area is a sort of "filler" between the defined traces. The shape and behaviour of this drivable area is defined by the surfaces and walls, of which there is another tutorial.

The maximum number of traces is 16, while you need at least two. To be able to define every surface and wall, it has to be entirely within the outmost traces. So make sure the maximum lateral distance of a wall is smaller than the distance from centreline of the trace. Trk23dow will crash or fail when you screw this up.

All traces are separately defined for every tracksection. This definition consists of a description of the height*function* of the trace, in the form of a 3rd degree mathematical function, this is a function of the type altitude = at³+bt²+ct+d Where T is a counter that goes from zero to 1, depending on the fraction of the section you have already driven.

So to describe 8 traces on a track of 45 sections, you will have to define 45*8=360 separate functions. A sequence of a few sections and one trace could look like this, theoretically:

As you can imagine, it's very hard to drive on something like this, as the start and end don't meet up in the first 2 section transitions. The second transition causes some concern as well, as there is a sharp bending point in the track. The car will do a wild bounce probably. Not desirable. The third joint is no problem however. So we can formulate the rule:

In order to have a smooth track with no sudden altitude transitions, the end altitude of one sector needs to be equal to the start altitude of the next sector, AND the end steepness of a sector needs to be equal to the start steepness of the next sector.

Now we go back to dissect the function. With some elementary maths, you can see that; 

                           For t=0 (startaltitude), altitude = d 
                            For t=1 (end altitude), altitude = a+b+c+d

The gradient is the first derivate of this height function, so we get the function Gradient = 3at²+2bt+c where t goes from 0 to 1 This gives: 

                            For t/dt=0 (startgradient), gradient = c
                            For t/dt=1 (end gradient), gradient = 3a+2b+c

Now, remember that this function is relative (in X) to the counter T from 0 to 1. In reality, some sections are longer than others. That means that a mathematical function may be the same on a long or short section, but that the actual sideview of the shorter section, reveals a sort of "compression" in it. This compression causes a higher end-steepness value on the shorter section, relative to the longer section. So we need to bring the section lengths in the calculations to know how steep a section really is (measured in degrees or percentages).

By multiplying the sector length by T, we know the real amount of X-units that the car is from the start of the sector. This way we can calculate the real steepness of the section, by dividing the gradient by the length of the sector. The formulae become like this: 

                            For t/dt=0 (startsteepness) steepness (degrees)= arctan (c / SL(n) )
                            For t/dt=1 (end steepness), steepness(degrees) = arctan (3a+2b+c / SL(n) )
                            In which SL(n) is the section length of this sector (n)

To be sure two adjoining sectors have a smooth transition, the rules described above can be mathematically formulated like this: 

                            Altitude rule: 
                            D(n+1) == A(n)+B(n) + C(n) + D(n)
                            In which (n) is the first sector, and (n+1) is the second sector

                            Steepness rule:
                            arctan (c(n+1) /SL(n+1) ) == acrtan (3a(n)+2b(n)+c(n) / SL(n) )
                            this can be recalculated to
                            c(n+1) == 3a(n)+2b(n)+c(n) * (SL(n+1) / SL(n) )

Note that now on both equations, the unknowns are on the left, and can be calculated from all the known variables on the right side of the equation.

From this we can conclude that, when you're entering the altitude values of a section, you're not entirely free to do so. The rules of the smooth track surface prove that basically, only 2 out of the 4 variables are user-customizable.

A third degree cubic function is completely defined by a start altitude, end altitude, start steepness and end steepness. As the start altitude and start gradient are defined by the previous section, you would only need to define the end altitude and end steepness in order to give enough data to calculate the parameters. Alternatively, you can define the function completely by using start-altitude and start-steepness, and manually enter the values for A and B, after which a new end-altitude and end-steepness can be calculated.

Now might be a good time to explain parameters A and B to you. Then again, these values are very hard to visualize in a function. If you're familiar with the cubic functions, you'll know that B is the "rate of change of steepness". A is the derivate of this value. Cool huh?

So we have explained the A, B, C and D of the cubic functions. In GPL they are labeled d1 ,d2, d3 and "altitude", respectively. In some writing or sheets you might also encounter d4 and d5. These last two are simply multiplications of d1 and d2, to avoid having to recalculate this number every time (saves frames!).

Now this is a whole lot of calculation going on. Fortunately, we don't have to do that all by hand. There are ways. The method that will be described in the next chapter, uses an Excel sheet to do the calculations.

Using the XLS sheets

Introduction

As we have seen in the last chapter, there is an awful lot of parameters that make up the trace data. It's the number of traces * the number of sections * 4 parameters per trace. For a track like Solitude, that totaled to over 7000 parameters. In order to handle these, I made an Excel sheet on which I designed all the altitudes. Because its such an extensive excel sheet (of 125 columns and over 1500 rows), this chapter is here to explain to you what the sheet does, how it is set up, and how you can change things on it. This all assumes that you have Excel and know how to work with it on a basic level.

The sheet

Or rather... sheets, plural. There are two basic versions of the XLS altitude sheet. One of them edits height using the d1-d2 parameters, and one uses the start-alt / start-grad parameters. Which one you use is a matter of preference. Because you cant have a workable sheet with multiple edited interrelated equation thingies, these two methods are written as two separate sheets.

Load up one of the sheets in Excel, and look around a bit. Notice you have multiple worksheets. One is called "import", one is called "Modf", and one is called "export". The purpose of these worksheet is as follows:

Import_data - this sheet is used to copy the output of GTK2xls in. This data can then be read by the other sheets, so you can load a current-state into the sheet and work from there.

Import_result - this sheet displays the resulted calculated d1,d2, start gradient and start-altitude of the centreline of the imported data. It also produces the relative differences in altitude and gradient from this centreline for all the traces. More on that in paragraph 2.3.

A) Modf_d1d2 - this sheet is used to modify the altitudes. The centreline is defined by d1 and d2, while the start gradient and start altitude are the result of the previous sections. With this method you can quickly update many tracksections if for instance you want the entire track to be 2 metres higher, or if you want to make the altitudes a little more extreme.

B) Modf_eheg - this sheet is used to modify the altitude traces, based on the method of defining the end height and end gradient of every section. The start height and start gradient are the result of the previous sections. This method may be a little more comprehensible and intuitive then the previous one, to some. It has the drawback that all changes are done only locally for one section.

A) Export_d1d2 - this sheet is used to display the results of the settings that you made in the Modf XLS sheet. These results are formatted so that you can easily "copy" the sheet, paste it into a new sheet, save it as CSV and import it into the GTK with Xls2Gtk. Easy.

B) Export_eheg - this sheet is used to display the results of the settings that you made in the Modf XLS sheet. These results are formatted so that you can easily "copy" the sheet, paste it into a new sheet, save it as CSV and import it into the GTK with Xls2Gtk.

Importing, section lengths

You start out with an empty sheet, where all height settings are zero. This structure is flat for the entire track over all the traces. To set up the sheet correctly for inserting altitude data, you have to tell it exactly how long the sections of the track are. As explained in the previous paragraph, this data is used to calculate what the end gradients are. If you get this data wrong, weird things happen.

Anyway, because we're very lazy, we're not going to type in 200 9-digit values so we use the export tool GTK2Xls to export a list of parameters out of the GTK. The output of GTK2Xls looks like this:

[GTK2xls output]

In the first column is the sector number. The second column is the length of this sector, in GPL-units (one unit is 1/19685th of a metre) The next columns are d1, d2, d3 and start-altitude for trace 0 of this section, and the next columns are d1, d2, d3 and start-altitude for trace 1, etc. All you need for now, is to copy the sector length column out of the exported data and into the main XLS file (pick one). But because it's just as easy, we rather copy all data from the export to the XLS, the Import worksheet of course.

Centreline

In order to limit the number of free variables and make the definitions of the traces more comprehensible, the height of the traces are defined relative to the centreline of the track. That means that you first have to define the up-and-downs of the centreline, and then you can adjust the single traces. Note that this centreline acts as a "virtual trace" now. There doesn't have to be a trace at lateral value zero, but this centreline has the properties of one.

As you define all traces relative to this centreline, it's very easy to make, i.e. a large part of the track a little steeper. Instead of having to do that trace by trace, you can simply make the centreline a little steeper there. Even when all traces get updated at that point, the structure of that section (banking, kerbs, hills) is retained. So you can see the value of doing it this way, I hope.

Editing by adjusting d1-d2

So, now you understand how the centreline concept works, but we're still stuck with an empty spreadsheet. Best way (imo) is to first make the definitions of the centreline, and after that (or a little parallel, most likely) the relative heights of the individual traces.

Personally I like to edit the d1 and d2 values of the centreline, instead of defining the track using gradient and altitude. This is for a number of reasons;

1) I was used to this from GP2 *.

2) Editing d1 and d2 makes it very easy to make changes that affect many sectors, as its possible to change a parameter in the first corner, and that change is calculated through to all the next sections. I.e. if you like the altitude sections you've designed, but have a certain altitude mismatch at the end of the track, you can simply change the first corner to make the entire track 0.1% steeper that will result at the end of the track in perhaps 10m difference, but is unnoticeable when driving.

3) D1 and d2 are directly influential on the behaviour of the car. If for instance you make too large a height difference or steepness difference within a (short) sector, the d1 and d2 data will show you relatively large numbers, so you should be aware then that the car behaviour will be affected more.

So how to edit d1 and d2? Well if you understand what the numbers mean (see chapter 1), it should be possible for you to make some hills and so on. Play around with it a bit. You can always see what the resulting gradient and end-altitude are, in the column in the sheet. You can match this with real life data if you're fortunate enough to find any. Personally I try to leave d1 to zero, and work only with d2 to make the track go steeper and flatter. The D1 value can be used though to create altitude effects that you'd otherwise would need to define another section for (like a "step", where the track goes steeper then evens out again, within 1 sector).

Make sure though that at the end of the track, the end altitude and end gradient have to correspond with the initial altitude and gradient of the track.

Editing by Adjusting Gradient and Altitude

Alternative to editing d1 and d2 I made another sheet that allows you to define the traces by giving for every section an end height and end gradient (steepness). The other parameters are then calculated out of the data you enter. The main advantage of this is that it's a little more obvious what you're working with, less abstract. The disadvantages are obviously that one sector is defined independent from the rest and you can't change anything globally. Also it can be hard to spot what exactly causes a certain steep bump that you experience while driving.

To edit the centreline definition using this method, you simply fill in the gradient (in degrees (?)) and the altitude of the track (in metres above "sea level"). Again, make sure that at the end of the track, the end altitude and end gradient have to correspond with the initial altitude and gradient in the first section of the track.

Editing Relative Trace Data

So now that we have defined the altitude function of the centreline, we can do the individual traces. This is initially done by entering for every trace, the height of this trace relative to the centreline, at the end of a certain section. The sheet then looks at the centreline definition, grabs the start- and end gradient of the centreline, and uses this for the trace. It also grabs the start- and endaltitude by adding the centreline-altitude and relative height together. With these 4 values, the parameters for the heigthfunction of this particular trace are calculated.

For example, imagine a banked right turn. All you need to do to make the turn banked, is to make the trace at the left (out)side of the track higher then the trace at the right side. Simply add 20cm of banking to one trace, and -20cm to the other. Note that now, when you change the general altitudes of the track so that this corner becomes uphill or downhill, the banking is unaffected. Take note however that traces can be very widely spaced apart or very close together. Where traces are very close together, the drivable area starts acting like a wall when you put in a lot of height difference between them. You can imagine the situation by drawing a cut-through of the track, with traces at specific points. See picture 2.3

For most cases it is sufficient to define the traces as said. However in some cases you may want to fine-tune the relative gradient also. For instance on a short banking transition from left to right. For this purpose a section is made with which you can adjust the gradient of a trace relative to the gradient of the centreline. Be careful with this however, for when you enter a large value here, the trace sometimes has to become very steep or curvy to fit the definitions you gave it. See examples in 2.4 

                            <2.4, examples of relative trace gradients>

Exporting

Well all this intelligent trace-data generation stuff isn't much use when there is no way to put it all back into a GPL track. That's why we also thought of a "export" function. But because of the use of excel for handling the traces, the exporting function isn't a matter of 2 keypresses, but a few more. In order to get trace data into a GPLtrack, we use the program Xls2GTK. This program merges a table of data into a GTK file, so you can edit it further. Ofcouse the table of data has to be in a fileformat that xls2GTK understands, and that is a CSV (comma separated value) fileformat, the same as we found when importing in paragraph 2.3. To make this CSV sheet, you simply "copy" the contents of the "export" worksheet from the main Excel sheet, into a new empty sheet. Save this file in CSV format. Remember the name. Now merge this CSV file into the GTK using Xls2GTK. And voila, all of the data you defined in the XLS is now in the GTK. Run Trk23dow to see where you messed up this time around.

More importing

This section will be added later. It will describe how to import all altitude data from a GTK into a XLS sheet for further processing.

Overview

In pic 2.5 is drawn which functions you have to go through and which way the sheets and programs interact. Its OK if you don't understand this, its just my weird way of trying to explain simple things with complex unintelligible graphs and words.


2.11 FAQ (F***ing Annoying Questions)

What is Excel?

- It's a Microsoft spreadsheet product that its pretty useful for, say, calculating altitude functions.

I don't have Excel, can you send it to me/ rework the sheets for [insert program here]? - No. Get Excel. Or go away. Or both.

I don't understand any of this as I don't understand Excel, and I never used it before! - Err.. that can be a problem. Ask your friends around for help on this. Don't bother me with simple questions that have anything to do with operating Excel. Making a simple if/then/else or formula is considered required pre-knowledge.


Updated 20-Mar-2001

Transfered to the wiki: 15.04.2009

Retrieved from "http://wiki.grandprixlegends.info/index.php?title=GPL_Track_Creating_-_Altitudes_and_Traces&oldid=1620"