OpenRacing Universal Track Interface

Background and goals

Most people think that the base of moderns simulators are about the vehicle they represents. But actually the heart of the simulation is how the track made of. It defines the visual context, the physical parameters of the whole application. One problem might arise during the developement of a simulator: the physical part of track modeling is done the way that it is so deeply integrated to the application that it sticks the whole simulator to one physical engine.

The effort between OpenRacing Universal Track Interface (ORUTI) is to address the above mentioned issue. By creating a well defined universal interface between the simulator and the physical engine those parts can be separated as well. So one is able to change the Physical engine under OpenRacing or create and apply a new track without knowing anything about the structure of Openracing code. Simply knowing interface makes possible to create new tracks as long as the necesseary functions are implemented.

The UTI adresses three aspect of track creation: visual - that is how a track looks like for the player physical - describes the physical attribute of the track (invisible, that is how the physical engine calculates what would happen) gameplay - defines the tracks and goals for the player to achieve (what route the car should be driven and so on)

The UTI has also helper functions for managing the tracks.

Discussion

As far as I know, the current concept of defining a track is to calculate the center line and then the body of the track is calculated knowing the width. It is sufficient as long as you have only two lanes. It also calculated for the physical part (height, collision,etc)

What I would suggest is separate the track model (TM) as physical surface from the track path (TP) as logical. The TM describes the physical attributes of the track: height,friction, surface, obstacles and so on. The TP defines what to do on that track. Imagine a big track for rally cross. It has a small village, a road serpentine, some beach part and so on. There is need to create the TM once, and you can make different types of races on it by providing different type of TP over it, like: (1) race from beach to serpentines through the forest. (2) race from the serpentines to the city through the beach. You can revert the direction on the track too.

How can it be done? We should define the concept of WayPoint (WP). It is a logical point in the world coordinate. We have an array of WP define a "lane" on the track: it is a series ow WP that follows the path of the lane (it is like the current TrackGen solution) What it has more that all WP can have the following attributes (just a brainstorming, not a completed, finished stuff yet):

• position: 3D position of WP in world coord
• next, prev : the next and prev WP in the path (the next: where should the car move. If the car leaves WP but enters to the zone of prev it means that the car is in wrong direction.
• enter/stay/leave: pointers for callback when car enters, stays or leave the WP's zone. (WP's own zone is the area where the WP is the closest WP regarding to the car)
• firendpaths: array of path the car can move on from that point: it's for intersection, or going out to pitbox.
• attributes: different attributes for the WP zone (e.x. speed limit)or type: on_track, off_track WP

There are some helper functions:

• findNearestWP(car *) : it gets through all WP's to find the nearest WP.

Possible extensions: I have talked about multiple TPs to define the way a car should go. The same method can be used to define the optimum way(s) on the track. So if someone builds a robot, it can be measured how it performs related to the optimal way. Since WP can have a wide range of data, the optimal way can store the optimum speed, steer angle and so on for a track.

Possible caveats: Defining a TP for a TM can be time consuming, but I think that could be done by a small generator. But, since we could define the track as a bunch of triangles, the creation of TP is the same for all Physical engines.

Formats

The UTI uses XML format. From the three aspects, only the gameplay part is defined by UTI interface. The physical and visual parts and its related files are taken care of the plugin using the interface.

.UTI format

- described later -

Requirements

Which informations are needed by OR modules.

Graphics

• 3D model and textures of the track.

AIs

• Graph of drivable segments connected together.
  • [...]

Physics

• [...]

API - Data structures

• TrackManager - discovers, loads, unload, checks tracks
  • scan(directory) - scans directory recursively to find track definitions (*.uti) files
  • list() - list of tracks found by scan()
  • load(filename) - loads a track to the simulator (visual, physical, gameplay)
  • query(filename) - queries info about a given track (length, dificulty, and so on)
  • check(filename) - check the integrity of a track (all part of the track is accessible, no missing files, constraint checks, version, checks and so on)

• TrackVisual - main interface for a loaded tracks' visual attributes and functions
  • defined later

• TrackPhys - main interface for a loaded track's physical attributes and functions
  • double trackheight(double x, double z) - returns the height of the track at the given world coordinate
  • (OBS) extern tdble TrackHeightL(tTrkLocPos *p) - obsolete function from simuv2
  • (OBS) extern void TrackGlobal2Local(tTrackSeg *segment, tdble X, tdble Y, tTrkLocPos *p, int sides) - obsolete function from simuv2
  • (OBS) extern void TrackLocal2Global(tTrkLocPos *p, tdble *X, tdble *Y) - obsolete function from simuv2
  • (OBS) extern void TrackSideNormal(tTrackSeg*, tdble, tdble, int, t3Dd*) - obsolete function from simuv2
  • vector3 TrackSurfaceNormal(double x, double z) - returns normal of surface at the global world coordinate
  • surfaceInfo TrackSurfaceInfo(double x, double z) - returns surface info at the given world coordinate

• TrackPlay - main interface for the gameplay structure

(continue from here)