glTF draco extension planning

[andreasplesch]

An issue on gathering resources on how to potentially implement the glTFdraco extension

spec: https://github.com/KhronosGroup/glTF/blob/main/extensions/2.0/Khronos/KHR_draco_mesh_compression/README.md

Threejs loader: https://github.com/mrdoob/three.js/blob/dev/examples/jsm/loaders/DRACOLoader.js

glTF sample viewer: https://github.com/KhronosGroup/glTF-Sample-Viewer/blob/master/source/gltf/primitive.js

simple test: https://raw.githack.com/andreasplesch/Library/gh-pages/Examples/gltf2/inline.html

Strategy

Loading

The draco.js libraries are substantial in size. The smallest option is the wasm wrapper (https://github.com/google/draco/blob/master/javascript/draco_wasm_wrapper_gltf.js) at 57Kb plus the wasm binary (https://github.com/google/draco/blob/master/javascript/draco_decoder_gltf.wasm) at 186KB for a total of

ca. 250KB.

The IE11 fallback draco.js (https://github.com/google/draco/blob/master/javascript/draco_decoder_gltf.js) is 495KB, almost double.

The Draco recommended approach is to dynamically load the library on demand from gstatic.

The x3dom approach is that it should suffice to have simple, single x3dom.js and be done.

The current x3dom.js is 825KB, x3dom-full.js is 1.1MB .

Options are:

1a) include the 250KB wasm lib. in x3dom.js 1b) include the 250KB wasm lib. in x3dom.js and load the fallback and demand 2a) include the wasm only in x3dom-full.js 2b) include the wasm only in x3dom-full.js and load the fallback on demand 3) load wasm, or fallback on demand

For simplicity, option 1a) would be the first target. The 250KB is substantial but relative to assets minor. IE11 support is not a priority.

The wasm blob could be an ObjectUrl to be used for the wasm path in the wrapper config.

On demand loading can be added later.

Parsing

The draco data provide geometry, indices and attributes. The spec is written to support mixed uncompressed and compressed data, or allow uncompressed fallback. But in practice it is likely that glb are used which need to be downloaded in a single file and would not offer benefits of mixed access.

One approach is to decompress, and then create new gltf buffers, bufferviews, and accessors from the decompressed data. This is used by the Sample Viewer and code could be reused. But it involves mutliple format conversion: from draco format, to gltf format, to webgl format. There is quite a bit of coding involved.

Another approach is to decompress, and use the decompressed data more directly for webgl. But this involves more x3dom infrastructure which may or may not be feasible.

[andreasplesch]

To include the wasm binary blob it would need to be base64 encoded, and become a dataUrl. This increases the size by 33% from 186KB to ca. 250KB, for a total of 310KB.

[andreasplesch]

Since async loading of buffers is done in binarycontainersetup, it seems best to add a draco field to buffergeometry, and decompress and process in binarycontainersetup. The gltfloader only generates the x3d, in the same way as for all nodes. This way daco buffergeometry could be used outside of glTF. The bufferview node is just the bufferview from extension. The bufferaccessor has just the id of the attribute. webgl buffers are directly generated from the decoder dracogeometry. It might be best to just use the dracogeometry and ignore the attribute ids ?