Unfortunately, I don’t recall in which way I was exporting it. It was created quite some time ago as a test asset and today I just decided to try something with it.
That’s actually not a problem creating a working scene with a cube .
My understanding is that this asset should be imported correctly in BJS as long as other libs are able to import it.
There might be some flaw in the importer or an issue in the data itself which still would require a workaround.
Thanks for clarifying that. I still would prefer BJS to import this thing somehow because in the project I work on we won’t have control over what is being imported. Users will decide what to upload and I expect complains about not being able to use some of the assets.
I believe this can be an issue in other user-oriented projects. So if in some [distant] future you decide to be less strict with imports, It’d help us quite a bit.
If I take your asset and convert it to .glTF, it passes validation, and indeed it loads in Babylon.js. If we convert it back to .glb, it is no longer corrupted. Therefore your issue is in the original .glb encoding. I suspect that a bug in Blender’s .glb exporter caused your file to be malformed. Here is the specific error:
{
"code": "GLB_CHUNK_LENGTH_UNALIGNED",
"message": "Length of 0x4e4f534a chunk is not aligned to 4-byte boundaries.",
"severity": 0,
"offset": 12
},
I did some checking and you’re right, many other 3D viewers do accept the original .glb file. Unfortunately, I would argue that they are probably the ones in the wrong here. Accepting and displaying invalid .glbs is harmful to the glTF ecosystem overall, as it allows broken exporters to fly under the radar and it leads to deviations from the spec.
It’s probably possible for us to create a non-strict mode that would accept .glb files with faulty encoding, but I’m not sure this is something we want to do. I definitely understand your concerns about users not being able to load files that they believe are valid; I just don’t know if the right fix is for us to make our loader deviate from the spec by accepting invalid files. I will check with @bghgary when he returns to the office in a couple of weeks.
In the meantime, I would recommend that you add an error message when the file isn’t able to load. You can point your users to the glTF validator so they can find the reason for the issue.
We discussed it a bit further and we’re considering adding a relaxed mode to enable loading these types of files, with warnings. I’ll keep you updated.
The issue is that, due to the incorrect encoding, there’s a binary buffer with a byte offset which is not a factor of four. Since it’s a Uint32Array, the offset should be some multiple of 32 bits, but it’s 990. This is why you see the error:
/accessors/0: RangeError: start offset of Uint32Array should be a multiple of 4
I am not very familiar with the binary encoding that glTF uses, so I’m not sure what the right approach would be to get around this issue. I’ll discuss with @bghgary on Monday and let you know what we come up with