Revision as of 12:54, 22 June 2009

Tasks & Plans

Achieving OTI

This is little thinking about torcs/openracing interdependencies... The goal of this thinking is to simplify the code, by getting rid of as much C++ as possible, especially if it is useless.

The facts

The only hard dependency that OR does have on Torcs' C++ code is simuv2 (simuv2 works with tTrack, tCarElt and tSituation).
- This in turn create a dependency over torcs track plugin, which is required to load a tTrack properly.
The robot interface depends on tCarElt for compatibility with Torcs AI, this can be dropped for now, we can find a cleaner solution later on.
- The robot itself is responsible for loading the car informations (via an XML GfParm file).
RaceManager inits tCarElt using informations given by the Robot's XML, then associate the car with the robot (see Q1).
RaceManager inits tSituation.

Quick remainder

tTrack is the logical track as stored and manipulated in C++ by Torcs (i.e. track trajectory and width basically as a list of segments)
tCarElt is the information about a car. positions of elements, wheels, fuel, driving commands, etc... (hundreds of fields in the structs)
tSituation describe the situation of a race. List of cars, the track, some global infos.

The questions

Q1: Should the robot decide the features of his car?

It seems more natural to me to build a car then put a driver into the car (instead of the opposite). Maybe some AI are very specific to drive a particular car, let's forget about that first: we simplify!

Old tasks

Ogre renderer

Automatic car 3D model conversion. (can be called "automatic AC3D to Ogre conversion").
Automatic track 3D model conversion from Torcs-NG's data (starting from trackgen). Should warn about unsupported geometry and such.
~~Make a camera follows a car (from behind)~~ : DONE.

Core engine

~~Load a complete track using C++ plugin~~ : DONE.
~~Initialize OgreDotNet graphic plugins to display the track~~ : DONE.
~~Load cars / physics engine~~ : DONE.
~~Load a C++ driver / create C# interface~~ : DONE.

Distribution

Compile libsimulator from unmodified Torcs-NG repository. No hurry for this. They aren't going to start using our code soon, anyway.

Driver

~~Implement user controlled vehicle~~ : DONE.
Load sharpy's driver, make it run a car : Keith will do

User interface

Make a GUI designed for our needs (load a track, evaluate drivers, run simulation in background, ...) : WIP
~~Port to MyGUI's C# interface~~ : DONE.
Work on the installation process

Merging Imre's work

DONE

~~Order:~~

Identify hardcoded stuffs : WIP
openracing.in -> LD_LIBRARY_PATH=/home/mulder/projects/openracing/cleaned/src/libsimulator/.libs

src/ode/OdeLoader.cs -> mCtx.RegisterResourcePath("/home/mulder/projects/trunk/track/Barcelona/");

my_config doesn't have to be in the repository

src/core/RaceManager.cs -> InitStartingGrid

src/graphic/OScene.cs -> mCtx.RegisterResourcePath("/home/mulder/projects/openracing/cleaned/data/tracks/road/icy");

src/ode/OdeMesh.cs -> XmlTextReader reader = new XmlTextReader("/home/mulder/projects/openracing/cleaned/data/tracks/road/icy/Mesh.mesh.xml");

Full merge

~~Clean~~

Screenshots

Bellow, you'll find some screenshots showing work in progress of Ogre renderer and GUIs.

OpenRacing gallery
2008-sep-08, high-quality skybox, back to stencil shadows
2008-feb-12, minimalist main menu
2008-feb-25, chasing camera
2008-mar-14, speedometer, tachometer, detect and remove alpha-blended objects
2008-mar-18, free-ride

@@ Line 6: / Line 6: @@
 The goal of this thinking is to simplify the code, by getting rid of as much C++ as possible, especially if it is useless.
-=== the present ===
+=== The facts ===
 * The only ''hard'' dependency that OR does have on Torcs' C++ code is simuv2 ('''simuv2 works with tTrack, tCarElt and tSituation''').
 ** This in turn create a dependency over '''torcs track plugin''', which is required '''to load a tTrack''' properly.
-* The robot interface depends on tCarElt for compatibility with Torcs AI, this can be dropped for now, we can find a cleaner solution later on.
+* The '''robot interface depends on tCarElt''' for compatibility with Torcs AI, this '''can be dropped''' for now, we can find a cleaner solution later on.
-** The robot itself is responsible for loading the car informations (an XML GfParm file), which file is then used by the simulator.
+** The robot itself is responsible for loading the car informations (via an XML GfParm file).
-* '''RaceManager inits tCarElt''' using informations given by the Robot's XML, then associate the Car with the Robot.
+* '''RaceManager inits tCarElt''' using informations given by the Robot's XML, then associate the car with the robot (see '''Q1''').
-..
+* '''RaceManager inits tSituation'''.
-=== the questions ===
+=== Quick remainder ===
-What is it the robot which decide the features of his car? It seems more natural to me to build a car, then put a driver into the car (instead of the opposite).
+* tTrack is the logical track as stored and manipulated in C++ by Torcs (i.e. track trajectory and width basically as a list of segments)
+* tCarElt is the information about a car. positions of elements, wheels, fuel, driving commands, etc... (hundreds of fields in the structs)
+* tSituation describe the situation of a race. List of cars, the track, some global infos.
+=== The questions ===
+'''Q1''': Should the robot decide the features of his car?
+It seems more natural to me to build a car then put a driver into the car (instead of the opposite). Maybe some AI are very specific to drive a particular car, let's forget about that first: we simplify!
 == Old tasks ==

OpenRacing WIP: Difference between revisions

Revision as of 12:54, 22 June 2009

Contents