World Simulator: Difference between revisions

From SpaceElevatorWiki.com
Jump to navigationJump to search
No edit summary
Line 1: Line 1:
== 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 in C# ==
== Torcs in C# ==



Revision as of 06:11, 6 July 2008

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 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 :-)