by R. Niehoff

1. Standard types

model

The 3D models are the standard objects. They are drawn with their polygons, and the collision is detected at all polygons (faces, edges and vertices). The geometry is described in a modeldescription, each model has its own description. Examples: houses, bridges, trees with plane branches, stones, signs, walls, fences etc. A typical entry in object_types.lst:

tree

This is a special kind of objects though it is used very often. A tree is drawn as a sprite by positioning a texture (with alpha channel) crosswise on the surface. Sprites can be drawn much faster than real models and so they are suitable for an environment with many trees. A real collision is not possible and also doesn't make sense. An approximated collision is realized in this way: The trunc is replaced with an unvisible model, so Tux collides with it in the same way as with a model. The treetop is cloned with some unvisible triangles. When hitting these triangles the speed is reduced and the direction is changed at random. A typical entry:

sprite

This is the simplest object, only a texture, drawn once (not crosswise) on the surface. There is no collision with a sprite. A typical entry:

2. Derivated objects

These objects are based on the standard types and have some properties which differ from the default properties.

boundary

A boundery limits the area of motion. There are two boundaries automatically set, on the left and right side of the course in respect to the course param "playwidth". You can define further boundaries e.g. for locking pathes or for keeping the player on the track. Notice that a boundary is a full collidable model, mostly a flat quad. Like other models it can be rotated, scaled etc. Since boundaries are unvisible and needn't be drawn you have to set the [visible] property to "false" or "no". A typical entry:

herring

A herring can be a model or a sprite. The main property is that it can be collected. When Tux approaches such an object, it disappears and the program increases the internal counter. You can define the number of points in the [collect] property, default is 0 - not collected. Typical entries:

3. Functional objects

These objects are unvisible points on the course. They are linked with predefined functions in the program.

sound

The sound will be audible when Tux is close to such an object. A typical entry:

reset point

The wellknown reset point on the course. A typical entry:

starting point

The starting point allows to define the position where Tux starts his race. By the way, a finish point is not necessary since it can be better defined with the option "playlength". A typical entry:

4. The params and their defaults:

Notice that a missing entry is set to default

[name] is for linking the type to an object instance (items.lst)
[type] is for identifying the object. It's an enumerated integer value.
[modeldesc] the file with the model description
[texture] the file with the texture bitmap
[visible] only used for objects which should not be drawn (default: yes)
[collect] number of points if collected (default: 0 = not collected)
[friction] friction coeff of an object face (default: 0.5)
[depth] how much Tux dives into the face (default: 0.0)
[mat] material index for predefined materials (default: 0)
[radius] radius of bounding cylinder (default: 0.6) (see note 1)
[billboard] texture file for billboard, only for models (see note 2)

note 1: Although trees use a bounding cylinder, too, they don't need an entry. The bounding radius is calculated from the texture.

note 2: 3d models are only drawn if not very far - und perhaps might be collided. For farther appearance the program uses a simple texture.

5. Supplements

The described object types are necessary and implemented in any case. Additionally the following types are possible:

[type] nicemodel

For collision a model shouldn't have many polygons - as few as possible (up to 40 faces). For nicer models you can create a second model with the same size and shape but more details (up to 300 faces). For drawing the program uses the nicer model whereas the collision occurs with the simple model. Also have in mind that each model has a lot of faces which can't be collided. So it might be a good idea to reduce a collision model to the collidable faces.

[type] combitree

A combitree is similar to a normal tree. The difference: the trunc is a real 3D model, whereas the treetop consists of crossed textures. A combitree needs a modeldescription for the trunc.

The object_types list is read after the program start but before the first course is loaded. It is available during the runtime of the program. Some unvisible object types (boundaries, startpoints, resetpoints) are trivial and can be predefined in the program code. Probably they won't appear in the object_types list.