osgEarth 2.0 Planning

Version 2.0 is the next Major revision of osgEarth. This release will represent an evolution of the SDK that we believe is necessary in order to support the long-term goals of the project.

Goals

• Present an API that is more "natural" to users of mapping software.
• Make the API clearer and more deterministic.
• Reduce QA and troubleshooting effort by creating a more modular, maintainable central architecture.
• Clarify the approach to using different major classes of content (imagery, elevation, features, and annotation).
• Improve visual performance (frame rate, frame drops).
• Improve loading/streaming performance.
• Reduce the complexity of tuning for different platforms/systems.
• Introduce more flexibility for multi-view systems.
• Support the objectives of the Godzi project.

Objectives

• API
  • Clearly separate initialization options from controller interfaces. In 1.x, heap-based "Options" classes set the initial properties of objects, but also include runtime controller interfaces in some cases. Rules as to when you can set various properties are implicit; this is bad. We will clearly separate the initialization options (as stack objects) from the runtime controller interface (which will be integrated into the object itself).
  • Create a clear, explicit data model for map layers, including first-class objects representing image, elevation, feature, and annotation layers. In 1.x, the MapLayer? type represents both images and heightfield layers; and feature/vector layers are defined as specialized model or image layers depending on the driver. All this needs to be more explicit and straightforward.
  • Abstract out the concept of a feature layer being a "specialized" model/image layer, at least at the top API level. Let the driver determine exactly how to make the attachment under the hood.
  • Get away from artificial constraints (like limiting the number of image layers) and instead introduce automatic fallback positions. The new Capabilities class will support this, not only measure OpenGL capabilities but general system capabilities as well (e.g. number of cores). The new StateSetCompositor idea is a prime example of this approach.
  • Mix and match Maps and Layers in predictable ways (like adding a Layer to multiple Maps, or having a "Map View" concept so that different views can show different layers on the same map...)
• Performance and Interoperability
  • Support a wide range of platforms. Use the new "services" approach to create fallback implementations of rendering engine - for wide platform/graphics support.
  • Introduce GPU support from MapNode?- and TerrainNode?- level uniforms down to the driver implementations.
  • Reduce locking requirements wherever possible. Emphasize the use of immutable, non-referenced objects in the data model.
  • Come up with a design for altering the map at runtime without stalling.
• Integration
  • Reconsider the design approach to osgSymbology in light of our experience so far and our needs for Godzi. Set some specific needs for symbology and create a design that meets those needs.
  • Provide hooks for shader composition, letting the developer "augment" osgEarth's shader-based rendering pipeline.
  • Update or remove some of the osgEarth::Util helpers (Graticule, ElevationManager?, etc.)
• Maintainability
  • Restructure core facilities in terms of "services" that can support multiple implementations if necessary (general). This includes things like a "tile factory" and a "StateSet? compositor" and an "Elevation Service", e.g.
  • Modularize the terrain engine function, separating the MapNode? from the terrain graph, and refactor the terrain engine into a driver plugin.
  • Rework the CMAKE setup to be clearer and more maintainable (prob use the Godzi setup)