WorldMap interface: Difference between revisions

From SpaceElevatorWiki.com
Jump to navigationJump to search
Line 31: Line 31:
But the world is no more two-dimensional, is it manageable by the driving robot? Yes he can just ignore the "z" of the polygons.
But the world is no more two-dimensional, is it manageable by the driving robot? Yes he can just ignore the "z" of the polygons.
Later, if the robot handles the 3D, it become possible to make bridges, etc.
Later, if the robot handles the 3D, it become possible to make bridges, etc.
(WDB:) Note: There are TORCS tracks having bridges and tracks beeing non planar (i.e. wheel-2). This is handled by the physics simulation, not by the robot itself.


== Option 3 ==
== Option 3 ==

Revision as of 15:18, 13 July 2008

If you read this, please notice I write it as I'm thinking about how the world can be defined. (so we forget about working only on tracks)

The two options bellow try to take into account the "car park" problem, since car parks can't really be defined as a network of roads.

Option 1

2.5 dimensions, vectorial definition of road areas and other areas.

  • The ground is an height-map.
  • By default, everything is covered with a given default material (for example "grass").
  • Then we define layers of other materials' areas:
    • an area is a 2D polygon projected onto the ground from above.
    • it has properties:
      • Is it drivable?
      • Physical properties
      • Graphical look
  • Then we add 3D models of buildings, parked vehicles, [...] on top of the height-map .

Option 1b: we can discretize the areas of materials by making a "material map".

note for readers:

  • an height-map gives the height of the ground for every x,y.
  • a material-map gives the material of the ground for every x,y.

Option 2

  • The world is a big 3D mesh (including ground, buildings, everything).
  • Roads are triangles of this mesh which are applied a material with flag "is_drivable"

But the world is no more two-dimensional, is it manageable by the driving robot? Yes he can just ignore the "z" of the polygons. Later, if the robot handles the 3D, it become possible to make bridges, etc.

(WDB:) Note: There are TORCS tracks having bridges and tracks beeing non planar (i.e. wheel-2). This is handled by the physics simulation, not by the robot itself.

Option 3

(WDB:) Combine Option 1 and 2: Use Option 2 as base for viewers and for "offroad" driving, but use the vector based description of roads for the simplifying of the physics simulation of road based driving. Why? Option 2 should be the natural way for the graphics part. Here we can use the collada format and all the code existing for it. For offroad driving we can use a physics simulation based on the ODE engine. The vector based driving is for many (real world) situations a good description, easy to connect with the algorithms of navigation systems, urban driving, traffic rules etc. We can use a physics simulation based on the TORCS engine. We can use a program like trackgen to get the 3D-mesh of the vector based track description. Option 2 doesn't mean one 3D-mesh, it is possible to have a set of 3D-meshes, easily to switch on/off parts of the world being relevant for vision systems but not for the collision calculation of the physics system. With this approach we can combine the best of both worlds. We can make robots switch between roadbased and offroad driving. In fact we could scale down the vector based description to be defined one to one on the triangles of the 3D mesh, if needed to make complex transitions between road based and offroad regions/driving.