OpenRacing WIP
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.
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 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
- 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.
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!
Killing C++ Howto
- Get rid of all C++ code not needed by simuv2.
- 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).
- 22/06, 5pm. 29115 lines
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-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
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
