Gltf-blender-io: Cannot load a .glb authored with glTF-Blender-IO in 3D Viewer for Windows

[SurlyBird]

As noted in the title, .glb files authored with the current glTF-Blender-IO exporter will not load in the 3D Viewer app for Windows 10 (formerly 'Mixed Reality Viewer'). The .glb will load in BabylonJS (sandbox.babylonjs.com) and Godot Engine v3.1.alpha.

Importing the .glb into Visual Studio Code with glTF Tools enabled generates the following error in the 3D Preview pane:

/accessors/4: RangeError: Invalid typed array length: 36

To repro, export a default scene cube as a .glb in either the latest stable Blender 2.79 build or the latest experimental 2.8 build (I realize 2.8 is still pre-Beta, but I want to provide feedback in order to address problems as soon as possible).

Worth noting that exporting the same cube using the exporter from glTF-Blender-Exporter does not fail in 3D Viewer. It loads just fine.

[donmccurdy]

When loading the model on https://gltf-viewer.donmccurdy.com, (1) does the model appear correctly, and (2) do you see any warnings or errors in the lower right hand side?

/cc @bghgary

[SurlyBird]

Hi, Don.

Model does appear correctly in the viewer and I get the following warning/errors:

MESH_PRIMITIVE_UNUSED_TEXCOORD | Material does not use texture coordinates sets with indices (0). | /meshes/0/primitives/0/material

NODE_EMPTY | Empty node encountered. | /nodes/1

[bghgary]

@SurlyBird can you attach the broken glb as a zip to this thread?

[SurlyBird]

Hi, Gary.

I sure can.

Just to explain the naming of the files in the zip:

The files with '_io_' are using the glTF-Blender-IO exporter (one for Blender 2.79 and one for Blender 2.80). The file with the '_exp_' uses the glTF-Blender-Exporter exporter (for 2.79)

glb_cubes.zip

[bghgary]

The reason why the glTF-Blender-IO files don't work is because they use embedded binary data and there is a bug in the glTF-SDK. I will submit a PR to fix it, but it will probably take a while before the fix makes it back to the 3D viewer app.

[emackey]

Seems out of place to be storing base64-encoded binary data in a GLB's JSON, when a proper binary chunk is available. It may be legal but it doesn't seem like best practice. Is that a bug in the exporter?

[UX3D-becher]

Now the binary data isn't stored as base64 encoded string in the buffer url but at the end of the glb.

This should also resolve your issue with 3D Viewer for Windows

[SurlyBird]

Indeed, .glbs authored in Blender 2.8 now load in Windows 3D Viewer. Thanks for taking care of this, everybody.