glTF-Blender-IO: `Emission` materials not exporting, throwing Traceback

Fixed here: https://github.com/KhronosGroup/glTF-Blender-IO/commit/50654eaf0cb62889cab711762f1b5355f2776b1c

Following node setup export is now working again:

Thanks, @emackey!

So, just for clarification:

• A Separate RGB node should not be needed in order to export Metallic/Roughness.
• Using an image editor such as GIMP or Photoshop should no longer be required to combine the RGB of the ORM texture as this will be done automatically by the exporter.

Is this correct?

EDIT: Sorry, it seems we went off on a tangent from the main issue, but Metallic/Roughness appears to be working in the latest Blender build! (Look, Ma! No image editor!) So I’m thinking my questions have been answered.

In addition to @donmccurdy’s point, users may also keep around a few different variations of the shader(s) with different settings disconnected in the same node graph. I sometimes do this when I find a combination I like, but still want to experiment, so it may not be all that extraordinary.

It’s possible that the connected shader would completely override the disconnected; I haven’t tested that yet, but I’d imagine it’s better to rule it out by limiting to what is actually connected.

That’s something that could potentially be fixed, but, is that a common use case for Blender artists, to leave such a dangling node there?

Not high priority, but I would vote for fixing this eventually — can definitely imagine an artist wanting to create both unlit and PBR versions of an asset for different devices, and swapping a node socket seems like a very reasonable way to do that.

does that mean that in the exporter’s analysis of the node graph, it doesn’t necessarily discern between connected and disconnected nodes?

It follows links where it needs to, for example to detect which image nodes are connected to which sockets on the Principled node. But I doubt it pays much attention to whether the Principled node itself is plugged into an output or not. That’s something that could potentially be fixed, but, is that a common use case for Blender artists, to leave such a dangling node there?

So does that mean that Separate RGB should not appear in the node graph at all since it is automatic? Or were you referring specifically to the importer?

I meant the importer, specifically, places that node there on import, otherwise Blender can’t understand the contents of the glTF ORM texture. I believe the exporter will kind of reverse-engineer the node hookups there to see which channel is being sourced from where.

But the exporter should also be willing to take for example a pair of grayscale images, separately connected (one to roughness, and one to metallic), and blend them together into a combined image for glTF. This case wouldn’t require a special node, because the exporter is well aware of how glTF specifies its textures to be packed.

If you make the base color black it won’t be affected by lights. Otherwise emissive is added to the normal PBR output. Same should be true in Blender I think. Think of it as a PBR material that also emits (some) light.

Is now merge with Blender repo, will be available next build