OpenRacing WIP: Difference between revisions
No edit summary |
|||
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 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'''). | * 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. | ** 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) | ** 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 | * '''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 == | == Old tasks == |
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.
-
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