Using images and explicit binary container for efficient and incremental delivery of declarative 3D scenes on the web

Abstract

JSON, XML-based 3D formats (e.g. X3D or Collada) and Declarative 3D approaches share some benefits but also one major drawback: all encoding schemes store the scene-graph and vertex data in the same file structure; unstructured raw mesh data is found within descriptive elements of the scene. Web Browsers therefore have to download all elements (including every single coordinate) before being able to further process the structure of the document. Therefore, we separate the structured scene information and unstructured vertex data to increase the user experience and overall performance of the system by introducing two new referenced containers, which encode external mesh data as so-called Sequential Image Geometry (SIG) or Typed-Array-based Binary Geometry (BG). We also discuss compression, rendering and application results and introduce a novel data layout for image geometry data that supports incremental updates, arbitrary input meshes and GPU decoding

Streaming compressed 3D data on the web using JavaScript and WebGL

“…We also include results from the X3Db codec provided in [Behr et al 2012]. We can observe that our compression rate is quite similar to these two recent concurrent approaches.…”

“…Recently, several interesting compression methods, allowing decompression in the web browser, have been proposed: Google introduces webgl-loader [Chun 2012] (http://code.google.com/p/webgl-loader/), a WebGL-based compression algorithm for 3D meshes in the context of the Google Body project [Blume et al 2011]; it is based on UTF-8 coding, delta prediction and GZIP and produces compression ratio around 5 bytes/triangle (for encoding coordinates, connectivity and normals). Behr et al [2012] propose to use images as binary containers for mesh geometry within the X3DOM framework; they obtain compression ratio around 6 bytes/triangle in the best configuration. These two latter approaches produce interesting compression ratio and a fast decoding mostly on the GPU.…”

“…Indeed, after decoding only 10% of the elements (this corresponds basically to decoding 10% of the P3DW file, which represents around 1% of the original ASCII file size) we already have a nice approximation of the object. Table 2: Comparison with X3Db, Google webgl-loader [Chun 2012] (UTF8 codec) and the X3DOM's image geometry approach [Behr et al 2012] (SIG PNG codec). File sizes are given in kB.…”

Web-Based Scientific Exploration and Analysis of 3D Scanned Cuneiform Datasets for Collaborative Research

“…This motivates the use of web-optimized 3D formats that offer features like data streaming, geometry compression and progressive model loading. Some noteworthy formats in this regard include X3D [10] and XML3D [11] as human readable text based formats and the X3DOM Binary Format [12] that externalizes the mesh data in form of directly GPU compatible binary blobs while still containing text based descriptions. The OpenCTM format [13] addresses the large data sizes with entropy reduction and LZMA entropy encoding, which, as a side effect, adds a decoding overhead on the client side.…”

Big Data Analysis for Media Production

“…This approach takes advantage of decompression methods inherently available to all browsers (thanks to HTML standards) yet is limited, from a big data perspective, due to restrictions in the UTF-8 data format, which requires the mesh to be broken down into various smaller chunks. Behr et al [128] adopted a different approach to the transmission of binary data, storing them in the pixels of lossless Portable Network Graphics (PNG) format images. This also has the advantage of fast decompression and a further one of pushing much of the mesh reconstruction work to the GPU.…”