OpenRacing Universal Track Interface

Important

(Imre, Nagy) Wolf-D had some very important point in comments. They are merged, but not yet published. Stay tune for changes, his comments are worked into the structure published soon.

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.

Track generation

In order to UTI to be a successful open structure for defining tracks, it should provide an easy way to generate new tracks within minutes, but it also should maintain ways to fintune it.