OpenRacing WIP

From SpaceElevatorWiki.com
Jump to navigationJump to search

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

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!

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


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.