Stuck on an issue?

Lightrun Answers was designed to reduce the constant googling that comes with debugging 3rd party libraries. It collects links to all the places you might be looking at while hunting down a tough bug.

And, if you’re still stuck at the end, we’re happy to hop on a call to see how we can help out.

Error when compressing glTF model with DRACO compression

See original GitHub issue

I’ve been researching on how to compress a multi-texture OBJ with DRACO to be able to render in THREE.js. Anyways, after some discussions in this thread, I was advised to convert the OBJ to glTF and then leverage the V2 branch here to compress the glTF with DRACO compression.

Here are my steps:

Generated a 3D OBJ model with OpenDroneMap. You can download a model with WebODM
Converted the multi-texture OBJ to glTF via https://github.com/AnalyticalGraphicsInc/obj2gltf
Tried to compress the new glTF via v2 branch and got the following error:

$ node ./gltf-pipeline/bin/gltf-pipeline.js -i odm/odm_textured_model.gltf  -d --stats

Statistics before:
Total byte length of all buffers: 60397176 bytes
Images: 4
Draw calls: 4
Rendered primitives (e.g., triangles): 193353
Nodes: 1
Meshes: 1
Materials: 4
Animations: 0
External requests (not data uris): 0
1
1
abort(1). Build with -s ASSERTIONS=1 for more info.

Thank you for your help and assistance.

Issue Analytics

State:
Created 5 years ago
Comments:7 (4 by maintainers)

Top GitHub Comments

1reaction

lilleysecommented, May 5, 2018

Fixed the secondary issue in https://github.com/AnalyticalGraphicsInc/gltf-pipeline/commit/734f85d26e766834347cb2ec835a6c694b970734 by adding a stage that splits primitives that share the same attributes but have different indices. This unintentionally fixed the draco crash too. The model now converts correctly.

1reaction

lilleysecommented, May 4, 2018

Thanks @FarhadG

It seems like this is an error from within the draco library. @FrankGalligan would you be to take a look at this? I uploaded the gltf here: https://drive.google.com/open?id=1u8oSGfsDpPTxD41MuJusbPahI126t9qC.

If it helps with debugging, primitive at index 3 is failing at EncodeMeshToDracoBuffer. Also the model converts correctly if MESH_SEQUENTIAL_ENCODING is applied.

This also reveals a secondary issue where mesh data is encoded multiple times when primitives share the same attributes but have different indices. I might have a chance later to look into that. For example the original glTF looks like:

        {
          "attributes": {
            "POSITION": 0,
            "NORMAL": 1,
            "TEXCOORD_0": 2
          },
          "indices": 5,
          "material": 2,
          "mode": 4
        },
        {
          "attributes": {
            "POSITION": 0,
            "NORMAL": 1,
            "TEXCOORD_0": 2
          },
          "indices": 6,
          "material": 3,
          "mode": 4
        },

Possibly relevant: https://github.com/KhronosGroup/glTF/issues/1267