Showdown! 3D Model Compression at Scale: Draco vs. Open3DGC
This post was written by Ian Kerr, Senior Software Engineer at Box
In the Box web and mobile applications, we enable users to “preview” their files, meaning a user can easily view a file directly in our app instead of having to download the file and open it elsewhere. We also allow developers to leverage our preview technology to display interactive viewers for files in their own web applications with support for more than 100 different types of files. One of the file types we support is 3D models. You can see a demo of our 3D Preview here.
Box’s 3D Preview lets users view several different 3D model formats in their browser: Collada (DAE), Filmbox (FBX), 3ds Max (3DS), Polygon (PLY), Stereo Lithography (STL), and Object / Wavefront (OBJ). These formats are not easily parsed in the browser, so Box converts them to a web-friendly “representation” made up of a JSON file that contains object and material properties, a binary file that contains vertex positions, attributes and connectivity information, and a collection of images.
These representations can be quite large for models with high polygon counts or lots of textures, which leads to long load times when previewing them. To address this, we investigated two geometry compression solutions: Google’s Draco and Khronos’s Open3DGC. We tested both tools with several “high-poly” OBJ files and measured the encode times, decode times and encoded file sizes.
Test Models
We used reconstructed models from the Stanford 3D Scanning Repository for testing:
https://graphics.stanford.edu/data/3Dscanrep/
Each model was converted from PLY to OBJ by Blender, with smoothed normals enabled.
Quantization
Both compression algorithms are lossy due to the fact that they quantize vertex data (i.e., positions, normals, texture coordinates, etc.) to achieve high compression ratios. The quantization level can be set independently for each attribute. For our tests, we chose the following quantization levels: 11 bits for positions and 10 bits for normals.
Performance
The Draco and Open3DGC projects both include command-line tools that allow you to encode an OBJ file while setting quantization levels. We used these tools to measure encode times on a MacBook Pro 2.8 GHz Intel Core i7. To measure decode times, we created a simple web app using the supplied JavaScript decoders. Here are the resulting file sizes and encode/decode times (bold quantities are the “best” in their category):
As you can see, in these tests Draco produces smaller encoded files (except for the two lowest-poly models) and encodes/decodes more quickly than Open3DGC. In particular, the Draco encoder is roughly fives times faster than its Open3DGC counterpart while the Draco decoder is about twice as fast.
Other Considerations
One knock on Draco is the size of its client-side JavaScript decoder: 876 KB vs. 130 KB for Open3DGC’s. When gzipped, the sizes reduce to 147 KB and 18 KB, respectively. There is an open issue in the Draco project for reducing the size of the Draco decoder:
https://github.com/google/draco/issues/49
Lastly, there appears to be more recent activity in the Draco GitHub repository. Open3DGC is part of the rest3d project but, at the time of writing, has not been updated since 2013.
Conclusion
Draco is the winner in terms of encoded file size and encode/decode speeds. It’s JavaScript library is somewhat large, but there are plans to decrease its size. Draco also appears to have a more active developer community than Open3DGC, though it is still relatively new.
Originally published at developer.box.com.
