|
|
| Line 4: |
Line 4: |
|
| |
|
| [[Achieving UTI]] | | [[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 redesigned properly (without constraints), starting with the track interface (see Universal Track Interface).
| |
|
| |
| === Step 1: kill 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)
| |
| * 26/06, 10:00pm. '''17949''' lines (removed lot of raceman, cleaning)
| |
|
| |
| ==== 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!).
| |
|
| |
| === Step 2: Conception ===
| |
|
| |
| ==== Plan ====
| |
|
| |
| # Solve the problems
| |
| ## What informations needs each modules?
| |
| ### Ode?
| |
| ### Ogre?
| |
| ### Robots?
| |
| ## How blender can define those?
| |
| ## How UTI should present this to OpenRacing's modules, in an ''abstract'' way?
| |
| # Provide class specifications.
| |
| ## For physics
| |
| ## For graphics
| |
| ## For robots
| |
| # Implement AlphaUTI and/or tools (depends where the methods goes)
| |
| ## .OTF (pseudo collada) loader
| |
| ## convert .OTF to OGRE
| |
| # Adapt
| |
| ## Ode to use UTI
| |
| ## Ogre to use UTI
| |
| ## Robots to use UTI
| |
| # Enjoy the new track made with blender!
| |
|
| |
| ==== Basic design ====
| |
|
| |
| [[Image:UTI-Integration.png]]
| |
|
| |
| ==== Ode needs ====
| |
|
| |
| Ode needs:
| |
| * a list of meshes
| |
| ** with physical properties
| |
| ** with normals
| |
|
| |
| ==== Ogre needs ====
| |
|
| |
| ==== Robots needs ====
| |
|
| |
| ==== Blender exports ====
| |
|
| |
| ==== UTI's interface ====
| |
|
| |
| ==== AlphaUTI ====
| |
|
| |
| === 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 == |
