Thin Client visualization

The Thin Client implementation is based on the visualization as a service technology called instant3Dhub. It is composed of multiple software components, i.e., a central client-side web application called webVis and multiple server-side services which support the webVis.

instant3Dhub provides two modes for rendering 3D content, i.e., either client-based or server-based rendering. The server-side rendering is intended to accelerate the visualization for small devices with low rendering capabilities, e.g., handheld devices like tablets or smartphones. However, in the scope of the IQmulus project, servers with GPUs were not intended. Therefore, we restrict the visualization method to client-side rendering only.

For client rendering, the server has the following two tasks:

  • Transcoding: The 3D content which will be visualized is somewhere located outside of the instant3Dhub infrastructure. For IQmulus, the data is usually stored on the HDFS filesystem. For efficient rendering, the 3D content is transcoded into multiple geometry containers equipped with a spatial index. The partitioning of the geometry and the accompanying spatial index can either be generated by the transcoder itself or be provided by the external data. The transcoded results are then stored in an internal cache and therefore need not be transcoded again.

  • Streaming: The client web application webVis is fed with streamed geometry by the server. Starting with a new scene, the server first streams the spatial index and additional metadata to the client. In the next step, the geometry packages are streamed by the server, whereas the client application decides which packages will be requested. The decision which packages must be downloaded with which priority is determined using the spatial index and the current camera location.


We use two different methods to deal with large data sets. For point cloud data, we use an external tool which sorts the point data into an octree. The resulting octree is then given as input to instant3Dhub, transcoded, and then visualized. The geometry packages are directly derived from the octree structure with its referenced files. For triangle data, we use Kd-trees which are created inside the transcoding process. The triangles are split into smaller objects, to enable a better balancing, and then sorted into the Kd-tree. The partitioning is done in two steps. In the first step the triangle mesh is split into connected components. If a connected component is too large, it is further subdivided into smaller objects. This is done using geometric splitting, i.e., the geometry is recursively bisected along the longest axis, respectively.

Large data sets in the Web application. Rendering large point clouds is a challenging task mostly due to the substantial size of the data, which may be much larger than the total system memory on the target machine. In particular, in the context of web applications, the available memory is not communicated to the applications running on the web browser. Typically, once an arbitrary limit (which depends on the particular web browser, the operating system it is running on, and other factors) is reached, the application will simply crash with no previous warning. This can only be avoided by imposing conservative limits on the maximum memory the application can use, which implies that the application will also have to deal with memory management and keep track of its memory usage.

The Thin Client is based on the webVis/hare3d framework which has been developed for visualizing massive 3D models on the Web. It provides all the necessary base technologies including memory management, data downloading, and iterative rendering as described below.

Data download. The client decides which patches of points should be downloaded based on the relative area they will occupy when drawn on the screen. Patches that are not visible or would appear smaller than a defined threshold are not downloaded. This simultaneously reduces network traffic and memory usage on the client.

The visible patches with a screen size above the defined threshold are downloaded. The order in which the patches are downloaded is also dependent on their size so that the most relevant data is available first, providing better user feedback.

Iterative rendering. To achieve a pleasant user experience, the application must feel interactive at any given moment. This interactivity is achieved by limiting the time the application uses to render each frame, in order to keep a consistent frame rate.

The Thin Client has a target frame rate of about 15 frames per second. This is accomplished by setting a limit of 60ms for the time spent traversing the spatial data structures for determining which point patches should be drawn and the drawing itself.

With larger amounts of data, it is not possible to draw all the points at once. The Thin Client will iteratively render the point patches, using a time budget to limit the number of patches rendered per frame. Similarly, when data has is not available, it is composed with the currently displayed image once it is downloaded and processed.

The patches are prioritized according to their screen-space area, given the current view point, so that larger or closer to the camera patches are rendered first.

The Figure above shows two visualizations using the Thin Client. Two basins of the region of Liguria are shown in the top image. One basin is represented by a point cloud, the second one by a triangulated surface. The bottom image shows time-dependent rainfall data. Besides the rainfall itself, also maxima and the rain gauge stations are visualized.