World Simulator

Overview

Assuming that we want a vision system to do the "Object Detection" later (instead of gamers), we have to separate the world into two parts. The first part is all, what the "Object Detection" should recognize and classify correctly. This is our track, lanes on the track, opponents (driving cars), obstacles (parking cars), traffic signs (and later crossings etc.). The second part is all the stuff building the surroundings. It is just background for the "Object Detection" making the recognition harder.

If we use a own world viewer, we are free to do it like we want, except the track and the track's boundaries. If we don't want to use the track.ac file for version 1.0 to get the track's mesh, we have to write a new trackgen saving the data in an other format, but this are details we shouldn't think about now. Instead looking for a 3D-program (blender, AC3D, K3D, ...) to create objects manually we should think about the Object Generator, to do this work for us, based on parameters (Building size in X,Y,Z, Traffic sign's type (Stop, Turn left only, ..., Parking cars along the track from to etc.). Let's use a target file format, used by the world viewer and later by an own physics modul, but let's create things as we can do it fast and transform it to the target format if needed.

To make our work usable to real problems, the visualization should look "realistic". But what means realistic here? One point is the light. It should be possible to use different light (position, intensity, color etc.). If we assume we would use High Dynamic Range cameras with a wide range of light intensities mapped nonlinear to a given number of steps (8 Bit, 10Bit, ...), we have to use special settings for our world viewer to display the image, like such a camera would see it. Here realisic doesn't mean natural as seen by men's eyes!

An other point is the size of the visible part of the world. To be perfect, we should have a 360 deg round view or more cameras (to be able to drive fair being lapped, to know when to come back to the racingline while overtaking/overlapping etc.).

Most often the RGB color system is used for displaying purposes. But for us it would be good to use an other system instead. If the colors aren't mixed from the three basic colors red green and blue (RGB) but from the hue, it's saturation and the intensity (HSI), we just can drop channels like the intensity, to deal with different lights or use only one channel (hue) to get all blues we have in our current image.

Torcs Today

TORCS is a road-based car simulation (not an offroad one). TORCS uses only one road (track), in a closed loop. It needs the information about the track's geometry and properties (which comes from track.xml.) It contains no meshes, only the segment's parameters like type, length, friction etc. Track.ac or track.acc (holding meshes) is used only to display the TORCS world to a gamer. A track is build from segments of variable length. In cross section a track is build from a main segment in the middle and side segments at each side.

Segments types

• Left barrier (Limit of the area a car can drive on: Fence, wall, etc.)
• Left side (Drivable area, but can have bad parameters: Sand, grass, etc.)
• Left border (Used to display an imperfect or progressive junction to the sides material)
• Main segment (This is the only part used from simple robots to drive on!)
• Right border (A border also can be curbed)
• Right side (A side can be road too)
• Right barrier (Again a limit not to overcome with a TORCS car)

For pitting in a race, TORCS provides only one type of pitlane, a side of the main track with a fixed lateral offset.

Example:

• Left barrier
• Left side
• Left border
• Main segment
• wall,
• pitlane
• door of pit

It is up to the robots to switch between the main track and the pitlane at the correct places (and back). For the physics simulation it is like normal driving on a side segment.

Each segment (and side segment) can have it's own parameters for the surface (friction, rolling resistance, ...)

Example:

• Left barricade: Tirewall
• Left side: Sand
• Main segment: Asphalt
• Right side: Grass
• Right barricade: Fence

Till now, all the main segments of a TORCS track have the same width. The side segments usually have individual width, defined at the segement's start and end. Changing the side segments width from start to end is done linear.

The TORCS simulation doesn't know obstacles except other cars. The collision detection from TORCS is working with boundary boxes for the cars and for the wheels of a car, rolling on the track. To get obstacles, we had to park cars on the track (ok, we are free to give it a form we want it to have, but for TORCS it has to be a car).

Torcs in C#

Preliminary tasks:

• Compile torcs as a library, with very high interface: TorcsLaunch().
• Make a C# wrapper to it.
• Launch torcs from Mono.

(see linux/main.cpp)

Secondary tasks:

• Start plugging in other engines with C# APIs

New Physics Engine?

http://www.ode.org/ode-latest-userguide.html

ode.net

Torcs 3D Engine.

Reasons to throw away Torcs 3-d Engine

Here is the list of improvements we can get, mainly by making use of OpenGL 2.0 features (Shaders, Buffers Objects).

Without too much work we can achieve:

• Per-pixel lighting [1]
  • Phong
  • Fake sky reflections on coachwork and metallic parts (my personal algorithm) [2]
  • Bump-mapping
• High-quality illumination model
  • HDR rendering [3]
  • Realistic atmospheric effects (FIXME. can't find illustrations.. watch this if you're not afraid of maths [4])

Big work:

• Shadow Maps [5]
• Real reflections [6]

New engine

Modular architecture already make this possible. The 3D engine implements an interface (defined in interfaces/graphic.h), it is given the high-level information about the track and cars and have to build and display its own geometry from this.

Make it in C# ? For now making a C# wrapper for the renderer would imply calling C# from C, is that possible? If possible, the whole src/interfaces headers have to be wrapped to C# then. (Cf Torcs in C#)

Notes by Jeko for Jeko

It's almost pure OpenGL, so very easy to tweak.

Main work is done in src/modules/graphic/ssggraph/grmain.cpp

It builds a list of "screens" (main screen, mirrors, etc)

Each screen set up the opengl parameters he like and render track, then cars, etc..

Rendering of the car is done here: src/modules/graphic/ssggraph/grcar.cpp, grDrawCar()

(WDB: there is an error in the code used to display car's lights. The number of calls to the displaying routine is incremented with the number of lights defined for the car! So if you define all lights (front lights, rear lights, brake lights) you loose the transparency you had, using only the brake lights. Also it's implementation isn't effective, because in every timestep first all work is done to be able to display the light's and later it is canceled, because the lights wouldn't be seen. Instead you could first decide, wether the light's are visble or not, see [[7]]).

Future stuff

Live simulations

It would be cool to be able setup a situation where a car is following a series of rules, and you can play God and add or subtract parts of the world while the system is live and watch how it behaves. (Saving changes, so that this can become the track for next time...)

I'd like to be able to add barriers, or stop signs, or whatever and test how the driving engine handles it.

Networking

I'd like to be able to have different robots race on different computers. This would be a nice feature for the world simulator in about 6 months :-)