OpenRacing WIP: Difference between revisions

From SpaceElevatorWiki.com
Jump to navigationJump to search
Line 1: Line 1:
= Tasks & Plans =
= Tasks & Plans =


== Achieving OTI ==
== Achieving UTI ==


This is little thinking about torcs/openracing interdependencies..
C# code design was depending a lot on C++ code due to compatibility constraint with Torcs plugins.
The goal of this thinking is to simplify the code, by getting rid of as much C++ as possible, especially if it is useless.


=== Facts ===
However, with time, we finally ended up rewriting almost everything but the car simulation engine (which is the big part of the '''simuv2''' plugin)


* The only ''hard'' dependency that OR does have on Torcs' C++ code is simuv2 ('''simuv2 works with tTrack, tCarElt and tSituation''').
We then removed lot of C++ code, mainly track and robots related code, then their dependencies.
** 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 have C# robots), and 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 ===
The C# code can now be resigned properly (without constraints), starting with the track interface (see Universal Track Interface).


* 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)
=== Killing some C++ ===
* 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.


=== Questions ===
* 1- We got rid of all C++ code not needed by simuv2.
 
** 1. we disabled legacy c++ robots, which in turn allowed to remove learning, robottools, plib (almost completely).
'''Q1''': Should the robot decide the features of his car?
** 2. C# code that needed to access/modify t* struct now do it through an interface (called UTI).
 
** 3. We removed as much C++ code as possible.
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!


=== Killing C++ Howto ===
* 2- Simplifying simuv2
** simuv2 no longer manages collisions, we got rid of solid.


* Get rid of all C++ code not needed by simuv2.
==== Progress indicator ====
** 1. disable legacy c++ robots
** 2. C# code that needs to access/modify t* struct should do it through an interface (will will very probably serve as a base for OTI).
** 3. Comment out and remove as much C++ code as possible.
 
* Simplify simuv2
** simuv2 no longer manages collisions, we should be able to get rid of Solid.
 
==== Disabling C++ robots ====
 
This should allow to disable learning, robottools.
 
==== Separate C# code from current data structures ====
 
Will make changes to those easier.
 
=== Numbers ===


The indicator is the number of lines of C++ compiled in libsimulator.so. Goal is 0 (one day maybe).
The indicator is the number of lines of C++ compiled in libsimulator.so. Goal is 0 (one day maybe).
Line 59: Line 35:
* 26/06, 07:30pm. '''18289''' lines (removed solid and portability)
* 26/06, 07:30pm. '''18289''' lines (removed solid and portability)


----
==== Going further ====
 
Almost half the remaining C++ code is related to parsing XML and storing/managing ''GfParm'' (which is a list of Metadata -- or Dictionnary -- done in C++).
 
A quick ''grep'' approximates that SimuV2 retrieves about '''103 static informations''' about the car from its GfParm files.
If we create a structure in which we store those informations, we can then load them from C# (using far-far less code).
 
When all those 103 informations are loaded from C#, we can drop the txml and tgf c++ modules. Only simuv2 and math will remain (and I guess we then can't go any further except by porting simuv2 to C#).
 
=== Torcs' data structures and C# ===
 
OpenRacing is still relying on a few data structures which are defined in C++, they are used to keep synchronized simulation state between C++ and C#.
 
However, the C++ code is now absolutely free of informations about the track. So, concerning UTI's work, we have nothing to change on that part.
 
=== Alpha UTI ===
 
On the process to remove track from C++, I needed to add a minimal UTI interface in order to be able to run the simulation.
 
AlphaUTI is an extremely minimalist implementation of it. It gives a single starting position (0,0,2) and point its path to the street-1 folder so Ode and Ogre load their data from there.
 
We now need to transfer some ''intelligence'' from Ode/Ogre to UTI (so an UTI is not just a folder!).
 
=== 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!


== Tasks ==
== Tasks ==

Revision as of 18:48, 26 June 2009

Tasks & Plans

Achieving UTI

C# code design was depending a lot on C++ code due to compatibility constraint with Torcs plugins.

However, with time, we finally ended up rewriting almost everything but the car simulation engine (which is the big part of the simuv2 plugin)

We then removed lot of C++ code, mainly track and robots related code, then their dependencies.

The C# code can now be resigned properly (without constraints), starting with the track interface (see Universal Track Interface).

Killing some C++

  • 1- We got rid of all C++ code not needed by simuv2.
    • 1. we disabled legacy c++ robots, which in turn allowed to remove learning, robottools, plib (almost completely).
    • 2. C# code that needed to access/modify t* struct now do it through an interface (called UTI).
    • 3. We removed as much C++ code as possible.
  • 2- Simplifying simuv2
    • simuv2 no longer manages collisions, we got rid of solid.

Progress indicator

The indicator is the number of lines of C++ compiled in libsimulator.so. Goal is 0 (one day maybe).

  • 22/06, 05:00pm. 39223 lines
  • 23/06, 03:00pm. 32984 lines (removed c++ drivers)
  • 23/06, 03:30pm. 31697 lines (removed learning)
  • 23/06, 05:00pm. 31565 lines (tried to remove robottools... but track have a dependency over it. simplifying what can be)
  • 24/06, 05:00pm. 30817 lines (removed gnulinux)
  • 24/06, 06:00pm. 30116 lines (removed simuv2 collision handling code, removed simuv2's dependency over the track format)
  • 26/06, 11:00am. 24528 lines (removed track, finished to remove robottools)
  • 26/06, 12:30pm. 21975 lines (removed most of plib. cleaning some commented lines)
  • 26/06, 07:30pm. 18289 lines (removed solid and portability)

Going further

Almost half the remaining C++ code is related to parsing XML and storing/managing GfParm (which is a list of Metadata -- or Dictionnary -- done in C++).

A quick grep approximates that SimuV2 retrieves about 103 static informations about the car from its GfParm files. If we create a structure in which we store those informations, we can then load them from C# (using far-far less code).

When all those 103 informations are loaded from C#, we can drop the txml and tgf c++ modules. Only simuv2 and math will remain (and I guess we then can't go any further except by porting simuv2 to C#).

Torcs' data structures and C#

OpenRacing is still relying on a few data structures which are defined in C++, they are used to keep synchronized simulation state between C++ and C#.

However, the C++ code is now absolutely free of informations about the track. So, concerning UTI's work, we have nothing to change on that part.

Alpha UTI

On the process to remove track from C++, I needed to add a minimal UTI interface in order to be able to run the simulation.

AlphaUTI is an extremely minimalist implementation of it. It gives a single starting position (0,0,2) and point its path to the street-1 folder so Ode and Ogre load their data from there.

We now need to transfer some intelligence from Ode/Ogre to UTI (so an UTI is not just a folder!).

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!

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.

Driver

  • 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
  • Work on the installation process

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-sep-08, high-quality skybox, back to stencil shadows

  • 2008-feb-12, minimalist main menu

    2008-feb-12, minimalist main menu

  • 2008-feb-25, chasing camera

    2008-feb-25, chasing camera

  • 2008-mar-14, speedometer, tachometer, detect and remove alpha-blended objects

    2008-mar-14, speedometer, tachometer, detect and remove alpha-blended objects

  • 2008-mar-18, free-ride

    2008-mar-18, free-ride


Old tasks

Ogre renderer

  • 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.

Driver

  • Implement user controlled vehicle : DONE.

User interface

  • Port to MyGUI's C# interface : DONE.

Merging Imre's work

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
Retrieved from "http://spaceelevatorwiki.com/wiki/index.php?title=OpenRacing_WIP&oldid=2847"