glTF loader fails to render some scenes loaded using loader.parse(...)

I have thumbnail server which uses GLTFLoader to load .glb data from Buffer. The server is a node app using headless gl and three-png-stream.

Previously, I’d written a python glTF exporter which generates glbs which load and render successfully on the server. Lately, I’ve been experimenting with glTF files that are generated using the glTF C# loader(@bghgary). I’ve attached one file generated with the C# loader, box.glb.zip, to help diagnose. In each of the following cases, files written using my python exporter load correctly both in the glTF viewer and on the server. The following applies only to models generated using the C# loader.

Files generated using the C# loader visualize perfectly using @donmccurdy’s glTF viewer, but when loading on the server, nothing renders. In an effort to debug, I set the material for all meshes contained in the glb scene to draw to wireframe, and I see a wireframe in my scene where I would expect it. Perhaps there is an issue with loader.parse(...) reading materials. I’ve experimented with including both the KHR_materials_pbrSpecularGlossiness extension and pbrMetallicRoughness, and inlcuding only pbrMetallicRoughness, to no avail.

This is for an architectural application with Z up, so I have tried both setting the Matrix and the Rotation of the root node. Again, everything visualizes fine in the glTF viewer with the scene being properly transformed. And, models which have their Matrix set to make Z up, generated by the python exporter, work fine using loader.parse(...) Perhaps there is a winding issue that is caused by setting a Matrix or Rotation which is causing facets not to render correctly.

I’ve compared the simplest case, a unit box, exported with the python generator and one generated with the C# generator. The only difference that I can see (when diagnosing by saving to .gltf and inspecting the files manually) is that the C# generator does not serialize default values. Perhaps there is an issue using loader.parse(...) with a .glb which omits default values? For example, the C# loader does not serialize mode:4 (TRIANGLES) for primitives, perhaps because this is a default?

This behavior is exhibited when I run the server remotely and locally, so I don’t believe it has to do with the environment.

I did see https://github.com/mrdoob/three.js/issues/14256, which may apply as the server is running node, and I’m doing the rendering in the onLoad callback. But again, this works with models generated from my python exporter.

Three.js version

• Dev
• r93
• …

Browser

• All of them
• Chrome
• Firefox
• Internet Explorer

OS

• All of them
• Windows
• macOS
• Linux
• Android
• iOS

Hardware Requirements (graphics card, VR Device, …)

[ikeough]

Thanks @vyv03354 and @takahirox. I should have reviewed the warnings on headless gl startup more carefully. As this is not a three issue, I’m closing.

[vyv03354]

Apparently the latest headless-gl trunk added support for OES_element_index_uint: https://github.com/stackgl/headless-gl/pull/121

But headless-gl 4.0.4, the latest version from npm, does not include this fix yet.