the problem file:
https://raw.githubusercontent.com/issuebox/babylonjs/master/instance/assets/ylw-thumb.glb
This file is compressed,I want to export the glb format after decompression through sandbox, and then open it with blender.
but I can not export to glb in the sandbox.babylonjs.com inspector. but some other file can export.
I don’t know if this is the file problem or a program problem
The asset loads in the sandbox just fine:
And the it looks like there are no errors with the .gltf file.
When trying to import this into Blender I get the following error:
Curious if the draco compression is causing an issue for the sandbox export as well.
@99999 - For the other files that you’ve successfully exported out of the sandbox, are they also using the draco compression extension?
Also Pinging @bghgary our resident .gltf expert to help here as well.
It’s weird. There is no error in the console. It just does nothing. Seems like a bug.
the following is the other compressed file，which can export through the sandbox:
https://raw.githubusercontent.com/issuebox/babylonjs/master/instance/assets/dzl-thumb.glb
they are all exported from blender with the default compressed config.
Strange, I’ll take a closer look tomorrow.
Looks like we’re failing to export some vertex buffers of this mesh:
But that raises the question of why does this asset have an empty uv vertex array…
Oh hey @99999 , I’m starting to suspect that the asset is malformed:
We have some of the compressed data in our mesh primitives that we’re pointing to is pointing to some odd indices, such as the first primitive (which crashes our exporter, I assume we’re able to safely work around this oddity when loading)
I’m somewhat surprised that the glTF validator isn’t validating mesh primitives pointing to invalid draco compressed data indices, inspecting these indices manually via the glTF Tools for visual studio shows that indices 0 and 1 point to valid data, while index 6 for our second primitive does not.
Looking at the working asset (dzl-thumb.glb) the indices look more reasonable:
I assume something regressed in their attribute workflow between v1.0.5 and 1.1.45. Can you try to re-export the asset without compression, and compressing it manually using GitHub - CesiumGS/gltf-pipeline: Content pipeline tools for optimizing glTF assets.?
Also, @bghgary do you know of any other tools for inspecting draco compressed data?
glTF extension for vscode has Draco support. Can you inspect the data with vscode?
Yes, inspecting with vscode works in being able to inspect the raw data, but I was asking more of a tool that visualizes the internal formatting of the draco compressed buffer views, just to confirm my suspicions.
No, I’m not aware of anything like that.
Thank you for your help! I had upload two files.
the raw obj file: https://raw.githubusercontent.com/issuebox/babylonjs/master/instance/assets/YLW_obj.zip
the uncompressed gltf exported with blender from the obj file:
https://raw.githubusercontent.com/issuebox/babylonjs/master/instance/assets/ylw-uncompressed.glb.zip
then I compress the gltf with gltf-pipeline comander:
gltf-pipeline -i ylw-uncompressed.glb -o ylw-compressed.glb --draco.compressionLevel 7
and it can exported from the sandbox
the compressed file:
https://raw.githubusercontent.com/issuebox/babylonjs/master/instance/assets/ylw-compressed-with-gltf-pipeline.glb