User:Tordanik/OSM2World Development
Adding support for new object types
WorldObjects
A visually rewarding way of getting started with OSM2World development is to add more types of things found in reality to OSM2World's virtual world. In the code, these are represented as WorldObject
classes. For example, "Building", "Tree" and "Fence" are all subclasses of WorldObject.
Most of the methods required by the WorldObject interface itself are related to elevation calculation and should be relatively straightforward to implement.
However, an object implementing only the WorldObject interface is invisible and will not appear in the virtual world yet. Therefore, you will want to also implement one of the variants of the Renderable
interface, most likely RenderableToAllTargets
. The only method of this interface, renderTo, hands you a Target
object - essentially a representation of a drawing space where you can creating triangles, boxes, columns and other geometric objects by calling its draw* methods. (You probably do not need the other methods in your renderTo implementation, stuff like beginObject is taken care of elsewhere.)
Because WorldObjects have a lot of calculations in common, it is usually a good idea to extend one of the abstract subclasses - such as AbstractAreaWorldObject
or NoOutlineWaySegmentWorldObject
- which already take care of many routine tasks. A lot of other useful code is available in utility classes such as WorldModuleGeometryUtil
and WorldModuleTexturingUtil
, among others.
WorldModule
Whenever you implement an new WorldObject class, you will either add it to an existing WorldModule
or create a new one. WorldModules are responsible for the creation of WorldObject instances; due to the close relationship, WorldObjects are usually written as inner classes of the WorldModule creating it.
WorldModules exist because some WorldObjects need to be linked with each other, requiring a somewhat more involved creation process (an example is the RoadModule or other features structured as "networks"). If this does not apply to you and you do not need that complexity, consider extending the AbstractModule
. In this case, typical implementation code may look like this:
protected void applyToNode(MapNode node) { if (node.getTags().contains("man_made", "foobar")) { node.addRepresentation(new Foobar(node)); } }
Finally, if you have created a new WorldModule, do not forget to add it to the default list of WorldModules in ConversionFacade
's createDefaultModuleList.
Adding output formats
OSM2World is designed to support a multitude of output file formats and render targets. Each of these is represented by a Target
subclass. ...