First of all, thank you for developing and maintaining this excellent Unreal plugin. I discovered an issue related to Draco compression during use, which may help improve code quality. The problem description is as follows:
Draco-compressed glTF models processed by the same gltf-pipeline tool show inconsistent behavior in Cesium for Unreal:
GLB output: Works perfectly
Separated GLTF + .bin output: Fails with "Draco bufferView extends beyond its buffer"
Key facts:
Identical input model → same compression settings
Only difference is container format (GLB vs separated)
Draco data content is byte-for-byte identical
This indicates a container-specific parsing bug in Cesium for Unreal’s Draco loader.
error details:
Draco-compressed glTF models processed by the same gltf-pipeline tool show inconsistent behavior in Cesium for Unreal:
GLB output: Works perfectly
Separated GLTF + .bin output: Fails with "Draco bufferView extends beyond its buffer"
Key facts:
Identical input model → same compression settings
Only difference is container format (GLB vs separated)
Draco data content is byte-for-byte identical
This indicates a container-specific parsing bug in Cesium for Unreal’s Draco loader.
It may be worth checking which version of Cesium For Unreal you are using (maybe it is an old one that does not yet include this fix?).
If it is a recent one, then it may also be worth checking whether other viewers can load this data. So maybe as a quick test: When you drag-and-drop the glTF (together with its external BIN files and textures and such) into https://gltf-viewer.donmccurdy.com/ , does it work there?
The goal would be to make sure that the glTF is not ~“invalid” in some way. If the glTF was invalid, then maybe it’s not an issue of CesiumForUnreal/cesium-native, but of gltf-pipeline. If the glTF works in another viewer, then maybe one of the issues has to be reopened. In this case, it could be helpful if you could provide one of the glTF assets (attached as a ZIP here), but let’s see what the result of the first test is.
Thanks for the info! To clarify the context: the Draco-compressed glTF files load successfully in CesiumJS(Web), but fail with the “bufferView beyond buffer” error only in Cesium for Unreal.
Validation Report
Format: glTF 2.0
Generator: Khronos glTF Blender I/O v4.5.49
Stats:
1 draw call
0 animations
1 material
2844 vertices
1438 triangles
Extensions:
KHR_draco_mesh_compression
NOTE: The extensions listed above are present in the model, but may or may not be recognized by this viewer. Any “UNSUPPORTED_EXTENSION” warnings below refer only to extensions that could not be scanned by the validation suite, and may still have rendered correctly. See: three-gltf-viewer#122.
Report generated by: KhronosGroup/glTF-Validator 2.0.0-dev.3.10
Validation Issues:
Info: UNSUPPORTED_EXTENSION
Message: Cannot validate an extension as it is not supported by the validator: 'KHR_draco_mesh_compression'.
Pointer: /extensionsUsed/0
Info: UNUSED_OBJECT
Message: This object may be unused.
Pointer: /bufferViews/0
Additionally, I successfully loaded and rendered the model in both CesiumJS and Blender. Besides gltf-pipeline, I also tried compressing the file with other Draco-enabled tools (like gltf-transform), but encountered the same validation errors.
Environment:
Cesium for Unreal plugin version: 2.21.0
As a new user, I’m unable to upload files. Could you please provide an email address so I can send it to you?
With the given information, it strongly looks like the file should be valid, and this might be a new instance of the issues that I linked to. The plugin version is very recent (I assume that it already contains the supposed fix, and would be surprised if it didn’t). So maybe one of the issues has to be reopened.
If you send the file to marco at cesium.com, I’ll probably try to have a look (maybe not “immediately”/“in the next few days”, but will try to check soon).
I haven’t done anything with cesium-native for a while, so I’ll need to update my local development environment. It could be good if someone from the Cesium For Unreal team could have a look as well, and even if it’s just to confirm that one of the issues has to be reopened. Otherwise, I’ll try to allocate some time for that.
Someone from the @cesium-nativeruntime team will have to take a closer look at that.
Right now, it does not seem to be one of the issues that I linked to. If that was the case, then it should be possible to reproduce this error with cesium-native alone - this is loading the glTF after all. However, when loading it with the CesiumGltfReader::GltfReader in a small, standalone command-line application based on cesium-native, then it loads just fine, and can print the positions that have been read from the draco buffer.
I tried your models in Cesium for Unreal v2.22.1, and they seem to be working just fine there. The only thing I had to change was that the tileset.json in the gltf-pipline/draco-gltf directory was accidentally referencing a_draco.glb instead of a_draco.gltf. Other than that, both the transform and pipeline versions of the draco-gltf model are loading and displaying well for me in Cesium for Unreal.
We definitely had a bug with Draco-compressed external buffers, which should have been fixed in v2.21.0. You said that’s the version you’re using, so it’s not obvious to me why you’d still be having trouble. I think there are two things worth trying:
Double-check that you’re on the official v2.21.0 release (or later).
Even if you are, try v2.22.1 and see if that works better for you.
Thanks for the initial investigations on this @Marco13!
Thank you both for your quick help and suggestions.
Following Kevin’s advice, I upgraded to Cesium for Unreal v2.22.1 and corrected the tileset.json reference. The Draco-compressed glTF with external .bin file now loads and displays perfectly.
The issue does persist in v2.21.0 even after the correction, which suggests this version indeed contained edge-case bugs that were resolved in v2.22.1.
Thanks to Marco for verifying with cesium-native, and to Kevin for testing in the new version. Your help saved me a lot of time and effectively solved the problem.
Works perfectly
Fails with 