In order to design and implement a 3D geo visualization system, it is important to understand how the scene graph concept and the rendering pipeline in modern graphics hardware work. Software
for creating 3D animations, CAD, scientific visualization, and game engines uses a hierarchical structure for assembling parts and grouping geometries to higher level elements. Mainly, 2 types of nodes can be distinguished: leaf nodes representing geometries, switches, behaviors, and triggers, and group nodes grouping and transforming leaf nodes and other group nodes to higher entities. Geometries have local object coordinates, i.e. they are relative to a local origin. The actual position in world space is computed by multiplying each coordinate with the Local2World matrix, which is the cumulative transformation matrix of all group elements from the geometry node up to the root node. Using local coordinates makes is possible to adjust parts of a model by modifying the transformation of the according group node. In this way, also animation paths and automatic behaviors can be specified. An example from within the GIS world is a model of a wind turbine with rotating blades (Figure 70). The rotor shaft, the blades are attached to, is centered at a local origin. A time loop modifies the rotation values of the transformation group of the spindle. The origin of the whole wind turbine model is at the base of the tower. The model is geo- referenced by an additional group node with e.g. UTM coordinates and orientation angles.
Another important aspect of many scene graph implementations is the possibility to re-use parts via cross references. Extending the above example, a whole wind park could be modeled by defining the wind turbine model only once and adding group nodes including a reference to the model for all remaining locations. In this case the scene graph is not strictly hierarchical. From a mathematical viewpoint, the structure is called a Directed Acyclic Graph (DAG), allowing branches of the tree to merge. Such references can be used to apply Geometry Instancing techniques, which result in a drastic reduction of memory footprint and CPU – GPU traffic, thus greatly increasing rendering performance. These dependencies must be taken into account when performing spatial operations such as CRS transformations on scene graph data.
Hardware accelerated graphics using OpenGL or DirectX have a major shortcoming. All vector and matrix calculations on the GPU are done in 32 bit single precision floating point arithmetic. This is insufficient for representing geo coordinates directly. In case of a globe we have coordinates with a magnitude of approximately meters. The 23 bit mantissa of IEEE binary32 (float data type) gives us an accuracy of about 0,8 meters ( / ( )). Although it might seem enough to represent simple building geometries, it also affects matrix computations of transformation groups and causes jitter, severely reducing rendering quality. This design was copied by many popular 3D formats, including Wavefront’s obj format, Autodesk’s 3ds format, and X3D, all specifying vertex data and vectors as floats.
Some recent developments might help reduce rounding problems and increase rendering quality of 3D geospatial systems. Support for 64 bit double precision floating point numbers in shaders has been introduced with OpenGL 4.0, released in March 2010. However, only few hardware components support the new extensions coming with 4.0 as of today, and rendering engines, scene graph APIs and 3D modeling software would require a major update. Currently, 64 bit operations on the GPU are mainly used for off-screen computations and analysis, for instance simulations, due to the incredible throughput and massive parallelization.
The need to have increased precision for implementing 3D geospatial applications was already identified by numerous publications. Within the Web3D Consortium, developments led to the GeoVRML extension for VRML, specifying a couple of node types for defining geographic content, for example GeoLocation, GeoOrigin, GeoCoordinate, and GeoViewpoint (Reddy et al. 2001). All of these node types encode coordinates as strings with arbitrary precision along with a CRS identifier (supported are geodetic, UTM, and earth-fixed-geocentric). The GeoVRML
extension was later incorporated into X3D as Geospatial Component explicitly using double precision vectors. Especially the GeoLocation node can be very useful for geo-referencing arbitrary models and importing them into 3D GIS. Unfortunately, the Geospatial component is ignored by all 3D editors, converters, and authoring tools so that it cannot be relied on during content creation and editing phases. But it can be used for import and export tasks and for deploying 3D servers.
Using scene graph data structures for GIS imposes higher requirements compared to traditional GIS concepts. Current 2D GIS standards do not use grouping and transformations; each coordinate is described directly in map (geodetic or projected) coordinates, according to the OGC Simple Feature Specification (Herring 2006) or ISO 19107 (Andrae 2009). This makes CRS transformations and computation of screen coordinates for display straightforward. 3D formats that extend the basic concepts of 2D GIS (CityGML, 3D Multipatch Shapefiles) are very well suited for GIS authoring tools and offline data exchange, but cause some troubles when being used for Virtual Globes with a uniform reference system.
The previous considerations lead to a system design for implementing Virtual Globes based on the following principles:
a) All geometries have local object coordinates with limited precision.
b) Geometries may be grouped to complex models, also including scene graph specific elements such as billboards, shared nodes, text, and animations. The group node transformations have limited precision.
c) Model units are metric, not geodetic, allowing easy import and publishing.
d) The actual geo-referencing is done with high precision translation, scale and rotation vectors. e) At some point, scene graphs must be transformed into a geocentric Cartesian reference
system, because this is actually used by the renderer.