eeGeo SDK structure
The eeGeo world is composed of various Modules. Modules are responsible for the lifetime management and initialisation of various resources. They also break down the code into logical sections, allowing a clearer and more structured approach to development. This allows users of the SDK to gain an understanding of the internal structure of the EegeoWorld class.
A module may contain objects or other modules. For example, the Map Module contains the EnvironmentFlatteningService object, as well as several other modules for other map related features, such as the WeatherModule.
Retrieving a module is a simple as using EegeoWorld.Get*Module method that corresponds to your required module. Individual elements of a module can then be obtained from the module themselves:
Modules::Core::RenderingModule& renderingModule = theWorld.GetRenderingModule();
Rendering::GLBufferPool& glBufferPool = renderingModule.GetGlBufferPool();
EegeoWorld contains a reference to a platform abstraction module and creates core, map and ‘other’ (see the last section of this document) modules. The core and map modules also create additional modules. The best way to get an overview of how these modules are structured is to refer to the Modules.h file, which contains the forward declarations for the module classes.
Platform Abstraction Module
Working on multiple platforms inevitably means that there will be the need for platform specific code. In our modular structure, we create any object apposite to system specific implementations in a Platform Abstraction Module.
A Platform Abstraction Module is created through a concretion of the IPlatformAbstractionModule interface. An implementation of this interface is injected into EegeoWorld as a dependency during construction. Note that this is special behaviour for a module: all other modules are platform agnostic and are created within EegeoWorld.
The Core Module contains objects that are critical to core system functionality, such as rendering. This roughly describes anything that needs to be instantiated before the geographical world is created. For example, before we are able to create renderable filters for our map resources, we depend on the rendering system being initialised.
The Map Module contains objects and modules relating to the geographical world within the SDK, such as modules to stream terrain or building resources or a module that controls the weather.
The structure of the Map Module can be broken down further by considering the different types of resources that are streamed into the SDK. We call these resources ‘Layers’ and layer modules exist as a subset of modules inside the Map module.
In total, there are five different types of layer module representing the types of resources that are streamed; Terrain, Building, Transport, Placenames and Shadow. In most cases, these different types are further broken down into three distinct modules; Model, Presentation, Streaming. These are closesly related to Model, View, Controller respectively if we were to think in terms of the MVC pattern.
Model modules typically contain data storage objects, such as repositories. Presentation modules contain objects that are pertinent to how the resource looks, for example renderable filters. Streaming module contain objects that controller the streaming and subsequent building of resources.
In addition to the Core and Map module layouts, there are a final set of modules that can be created after the geographical world has been created. These modules contain objects that exist on top of the world but are not strictly part of it, such as traffic or animated objects. These types of modules are created as individual modules within EegeoWorld and are not nested in a larger module structure.