The following runtime error occurs when reading a Draco compressed GLTF file.
What is the problem?
This does not occur if the file is not Draco compressed.
Draco compression is done with [gltf-pipeline](https://Draco compression is done with gltf-pipeline.). glTF Sample Viewer - Khronos Group can view it without any problems.
The file in question is attached. (I am also attaching an uncompressed file of the same model.) DracoCompressed.glb (158.8 KB) Uncompresed.glb (1.1 MB)
RuntimeError: Failed to load model: https://****/filename.glb
Failed to load glTF
Failed to load structural metadata
Cannot read properties of undefined (reading 'buffer')
Original stack:
Original stack:
Original stack:
TypeError: Cannot read properties of undefined (reading 'buffer')
at ResourceCacheKey.getBufferViewCacheKey (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:81488:31)
at ResourceCache.getBufferViewLoader (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:81891:47)
at loadBufferViews (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:89050:56)
at loadResources4 (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:88940:34)
at GltfStructuralMetadataLoader.load (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:88965:21)
at loadStructuralMetadata (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:91398:37)
at parse (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:91574:23)
at loadResources5 (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:90027:21)
Handler stack:
Error
at new RuntimeError (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:12845:13)
at ResourceLoader.getError (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:74426:26)
at loadResources4 (https://sandcastle.cesium.com/CesiumUnminified/Cesium.js:88957:20)
at async Promise.all (index 10)
This seems to be a bug somewhere, either in CesiumJS or in gltf-piepline (or… maybe in both…).
But could you provide more details about how you are applying the draco compression?
I tried it out with gltf-pipeline -i Uncompresed.glb -o Compressed.glb -d
(using all the defaults for Draco, with the -d parameter), and this is the resulting GLB:
This seems to be caused by the materials of the resulting glTF containing semi-transparent colors. When manually changing the alpha mode of the output glTF from "BLEND" to "OPAQUE", then … this is the result:
Yeah… the geometry is there, but … it’s still not right. Why is everything red? I don’t know for sure, but the input glTF contains vertex colors, via the COLOR_0 attribute, so I assume that the fact that everything is rendered in red is what already has been described in Problem with Draco and unnormalized vertex colors · Issue #6561 · CesiumGS/cesium · GitHub
The parameters for gltf-pipeline were almost the same.
The version of gltf-pipeline was out of date, so we tried it with the latest version and got the same result.
We continue to see the issue of transparency and display in red.
This seems to be caused by the materials of the resulting glTF containing semi-transparent colors. When manually changing the alpha more of the output glTF from "BLEND" to "OPAQUE"
If Draco compressed, does it not support rendering of translucent models?
I think that both problems are somehow connected: There seems to be a general problem with Draco-compressed vertex colors in CesiumJS, and this might be the reason why 1. some parts are not displayed (because they are below the alpha threshold) and 2. the parts that are shown are only shown in red.
It might be possible to “fix” the given model - roughly:
detect all vertices/triangles that have the same vertex color, and convert them into a new mesh/primitive
assign a simple, plain material to that mesh primitive
This would probably also reduce the size of the resulting file. (Storing plain, constant colors as vertex attributes is not ideal to begin with).
But… I don’t know whether there is an “easy” way to do this, and this might involve some manual work. Maybe there is an option for avoiding this problem right from the beginning: The ‘generator’ of the uncompressed glTF says ‘3DFT’. Is this generated directly from iTwin, or with some post-processing? Maybe there is an export option to not export the colors as vertex attributes, but simply as standard glTF materials…?