OpenRacing Universal Track Interface: Difference between revisions

From SpaceElevatorWiki.com
Jump to navigationJump to search
No edit summary
Line 3: Line 3:
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.
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 effort between OpenRacing Universal Track Interface (UTI) 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:  
The UTI adresses three aspect of track creation:  
Line 11: Line 11:


The UTI has also helper functions for managing the tracks.
The UTI has also helper functions for managing the tracks.
UTI supports different level of completeness of the track as defined below:
Stage 1 - complete visualand physical track, free-ride available
Stage 2 - as Stage 1 and robots launching is possible (waypoints and lanes exist)
Stage 3 - as Stage 2 and Track Rules are implemented
Stage 4 - as Stage 3 and Track AI is implemented


== Discussion ==
== Discussion ==

Revision as of 08:45, 3 March 2009

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 (UTI) 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.

UTI supports different level of completeness of the track as defined below: Stage 1 - complete visualand physical track, free-ride available Stage 2 - as Stage 1 and robots launching is possible (waypoints and lanes exist) Stage 3 - as Stage 2 and Track Rules are implemented Stage 4 - as Stage 3 and Track AI is implemented

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 which 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. The easiest way for it is to supply some kind of World Generator (UTI Genesis), that generates most of the track physical parameters, so only some visual make up and attribute setting is required from the part of the trackmaker.

Since a Road Segment is a well defined element of the track, it is advised for artists to generate at least one from each types of segments. Using Road Segments as building blocks

There are different methods to build up a new track:

  • Grid mode :