by R. Niehoff

1. The vertex coordinates

There are 3 kinds of coordinates that define the course properties. Let's start with the heightpoints defined in the bitmap "elev.png". Each pixel represents a heightpoint, so we get a net of such points (mesh). The size of the bitmap is given by the number of pixels: nx (width) and ny (height). The x-index goes from 0 ... (nx-1), the y-index from 0...(ny-1).

This is the view from the top. You can see that the origin of the bitmap is the upper right corner whereas the origin of the course in a 3D scene is the front-left corner. Of course, real heightmaps have more than 6 x 8 pixels, typically hundreds of them.

2. The quad coordinates

The quad coordinates are discret integer values like the vertex coordinates. They are relating to the quads between the heightpoints. You see that a bitmap with width = nx and height = ny consists of (nx-1) * (ny-1) quads. Accordingly the range of indices is from 0...(nx-2) and 0...(ny-2).

The quads are blue marked, they are relevant for the surface properties like textures. The blue arrows show the correlation between the heightpoints and quads. But since the outer heightpoints are the outmost borders of the course there are more heightpoints than quads. On the other hand a terrain bitmap which contains the textures is of the same size as the elevation bitmap. For various reasons it doesn't make sense to use a smaller terrain bitmap. That means that there is an unused area at the left und lower edge. Additionally a pixel on the terrain bitmap is not the center of the quad which it represents. The course creator has to regard this inconsistency, it's not very adverse.

3. The real coordinates

The bitmap size is not the real course size, a course can be arbitrarily scaled. The scaling factor has two effects. The greater the factor the lesser detailed will appear the scene - and the better will be the performance. You see, we must make a compromise. Approved values are between 2.0 and 3.0.

Real coordinates are real numbers and can be of any value in the interval 0...width or 0...-length. All procedures and states on the course and during a race are measured with real coordinates. Examples: positions, velocity, speed, height levels, slopes etc.

Please have in mind that the y-coordinates of the heightmap are now the z-coordinates in the 3D scene. According to the OpenGL rules the z-coordinates are negative because the standard view direction points to -z.

The triangulation of the course

Basically there are two ways of triangulate a mesh: the regular and the alternating triangulation. For two reasons the alternating method is preferred: steep slopes are a bit smoother rendered, and the mesh can be used for a CLOD algorithm like quadtree. Anyway, at the moment a quadtree is not intended but for future enhancements it might be good to have a base which is capable of being extended.

Result of the alternating triangulation is that there are 2 kinds of quads and 4 kinds of triangles. But it's not much effort to handle those different polygons. You get a quad of type A if the sum of x and y is even, whereas type B hast an odd sum. Remember that the quad coordinates are identic with the vertex coordinates of the upper-right corner. The real coordinates of this vertex define a local coordinate systems which helps to find the triangle type within the quad, cou've only to compare y with z. A hint: the values on the diagonal are equal (quad A, the circumstances for quad B are similar).

Translating coordinates

The real coordinates at the vertices

Width and height are the scaled course size. The height value yreal can be taken from the elevation array where all heightpoints are stored.

Vertex coordinates (quad coordinates) at real positions

All these formulas are trivial, I needn't explain them. You see that the latter translations reduce the results to integer values - just the requested vertex coordinates. It's recommended to test for extreme positions and move them into valid quads:

if (x > nx-1) x = nx-1;
if (y > ny-1) y = ny-1;