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

(There are pointers below, but this is just sample code)

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.

Terms & Definitions

(other part of this page is not yet updated with here mentioned terms and conditions, please take care! )

• Track: the whole package with UTI interface
•  TVM: Track Visual Model - includes all meshes, textures to build up visuals

of a given track

• TPM: Track Physical Model - includes all meshes, properties to build up

physical entity of a track

• RS: Road segment: larges build segment of a road. It defines the center

lines(s), ports and ports' width of a part of a road to be built.

• Port: "socket" in whicj Road segments are plugged together.
• Lane: One Road Segment can have one or more lanes. Lane has direction.
• DP: Decision point (point, where lanes are split or joined : see picture) DP

might trigger event.

How can it be done? (obsolete section!!!)

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 & implementation

UTI interface is in design state. As long as the structure of a general track is not successfully designed, there can be no interface declared.

Please, stay tuned!