Spatial data structures for accelerated 3D visibility computation to enable large model visualization on the web

Abstract

The visualization of massive 3D models is an intensively examined field of research. Due to their rapidly growing complexity of such models, visualisation them in real-time will never be possible through a higher speed of rasterization alone. Instead, a practical solution has to reduce the amount of data to be processed, using a fast visibility determination. In recent years, the combination of Javascript and WebGL raised attention for the possibility of rendering hardware-accelerated 3D graphics directly in the browser. However, when compared to desktop applications, they are still fighting with their disadvantages of a generally slower execution speed, or a downgraded set of functionality. We demonstrate the integration of spatial data structures, computed on the client side, using latest technology trends to mitigate the shortcomings of the 3D Web environment. We employ comparably small bounding volume hierarchies to accelerate our visibility determination, as well as to enable specific culling techniques. This allows for an interactive visualization of such massive 3D data sets. Our in-depth analysis of different data structures and environments shows which combination of data structure and visibility determination techniques are currently the best fit for the Web

Animation on the web

“…One approach to reduce the vertex buffer switches, is to have all the mesh data in a single image (either a texture atlas or map) and create one VBO on the JavaScript layer and bind it with this single image geometry and have all the other data directly uploaded as textures in the GPU. This is similar to the technique used in [Behr et al 2012], [Schwartz et al 2011], [Englert et al 2014] and [Stein et al 2014]. This allows the GPU to store more mesh data, and calculate all the decoding and vertex coordination on the fly.…”

“…Some of the major features include occlusion queries -which tries to reduce the rendering load on the graphical system by eliminating objects from the rendering pipeline which are hidden by other objects; transform feedback -capturing primitives generated by the vertex shader and recording data into a BufferObjects, thus allowing to preserve and resubmit data multiple time; Multiple render targets -allows a single draw call to write out to multiple targets (texture or renderBuffer); and , vertex array objects (VAO) -VAO allows us to store the vertex/index binding information for set of objects in a easy to manage manner. Stein et al [2014] demonstrate using spatial data structure on the client end using the latest features of WebGL 2.0 to improve upon the shortcomings of the current 3D web environment. They render an interactive visualization of large 3D data sets, by employing small bounding volume hierarchies to accelerate visibility determination.…”

glTF streaming from 3D repo to X3DOM

“…Such formats were later superseded by the Shape Resource Container (SRC) where rendering buffer is specified as multiple buffer chunks allowing data to be progressively transmitted over a network. To cope with large models online, they further introduced bounding interval hierarchies (BIH) which are spatial data structures calculated on the client to accelerate visibility culling [Stein et al 2014]. Similarly, [Sutter et al 2014] defined a format called Blast; a generic container dedicated to efficient streaming of binary data in self-contained chunks.…”

“…In order to restore this feature on a submesh level, the information about bounding boxes needs to be added to X3DOM separately. The algorithm used here, unlike in [Stein et al 2014], is based on kd-tree [Bentley 1975] and adapted for bounding boxes. It starts with the bounding box of the entire scene, and for each iteration, the bounding box is partitioned at the median value of the midpoint of all submeshes that currently reside within the section.…”

“…Although certain spatial partitioning structures can be computed client-side, c.f. [Stein et al 2014], the static nature of the version controlled models means we need to prepare the kd-tree only once.…”