Rendering in the eeGeo SDK


The eeGeo 3D maps SDK provides an optimised internal rendering system, which reduces costly operations, such as state changes and overdraw. Adding your own objects to this system is easy, through the use of renderable objects and filters. This article introduces these objects and outlines their roles in the rendering system.

In this section:

Renderable Objects

As with any 3D application, we need an object that represents our 3D data on-screen. In the eeGeo world, we call these objects ‘renderables’. Everything you see in the eeGeo world is a renderable, from the towering skyscrapers of New York City, to the gridlocked traffic of downtown San Francisco.


Whether it’s a building or an airplane, the Empire State or the Golden Gate, at their core they’re all RenderableBase objects. The RenderableBase class is an abstract class at the foundation of the rendering system. Anything that is to be rendered using the internal rendering system must be of this type, whether it is directly from the base class or from one of the subclasses shown in the inheritance diagram.

Implementing your own Renderable

In order to create your own renderable, you’ll need to inherit from one of the classes as detailed in the above step. You’ll also need to provide an implementation of the Render() method for your renderable.

Your Render() method will be the place that you write your OpenGL draw calls. This method takes a reference to a GLState object, which should be favoured for OpenGL operations where possible:

This allows better internal OpenGL state monitoring and helps reduce the number of redundant state changes. A comprehensive reference of the GLState class can be found here.

A working example of a bespoke renderable object can be seen in the Modified Rendering example.



Renderable Filters are a mechanism for both filtering/queueing renderables. Any class can become a renderable filter by fulfilling the IRenderableFilter contract.


The EnqueueRenderables method provides an opportunity to filter out any renderables that shouldn’t be renderered and queue any that should. The filter criteria will depend on your requirements, but this method provides a RenderContext to aid in the filtering. Filtering at this stage can help reduce the number of draw calls in your application.

Any renderables that should be rendered should be added to the RenderQueue, which is passed by reference to this method. This will submit them for rendering to the internal system.

In a simplistic example, you may wish to omit renderables that are further than 100m away from the camera from rendering:


The EegeoWorld object maintains a list of renderable filters and calls the EnqueueRenderables method on each one during the render loop. This can be retrieved through the rendering module.

As such, you should never call EnqueueRenderables explicitly. Instead, you should register your renderable filter with the list maintained by EegeoWorld. When you destroy your renderable, you should also remove your filter from the list.


The RenderQueue is the complete list of renderables composed by the EnqueueRenderables methods of all of the registered renderable filters. Aside from adding to the queue in your EnqueueRenderables method, you should require no further interaction with this object.

Once the complete list of renderables to draw has been constructed, the render queue will optimise the list for rendering by sorting in a manner that reduces the likelihood of OpenGL state changes. It will subsequently call the Render method on each of these renderables.