3
$\begingroup$

Pretty much as the title states. I have a material that I've exported as a GLB file. The roughness texture is originally black and white, but when I re-import the GLB back into Blender, it's turned into a coloured image. I'm just wondering why this may be.

The exported material

The imported material, now coloured

$\endgroup$

2 Answers 2

3
$\begingroup$

This is by design, and is not a bug.

The glTF format is intended for rapid delivery of 3D assets to remote rendering systems and GPUs. There are no Blender "material nodes" stored in glTF, instead the format offers a well-defined PBR material with standardized channels for particular textures.

The roughness texture, as you've discovered, is stored by glTF in the green channel of the corresponding texture, with the blue channel reserved for metallic, and the red channel optionally for occlusion. When you export a greyscale roughness image from Blender, it must be packed into the green channel. The unused channels are left as white, and the exporter makes use of glTF's "factors" (in this case, metallicFactor: 0) to control non-textured amounts of metal. This is a design choice to make use of the glTF metallic factor, to avoid spreading a fixed metallic value across a whole texturemap. Full white (1.0) is used in the channel, such that it can correctly multiply with the user's chosen metallic factor without altering the factor's value.

This behavior is intended to run efficiently on GPUs using existing PBR shaders. If you later re-import such a glTF back into Blender, a whole new set of nodes are constructed, to reflect the situation found in the file. The result will not be as pleasing as the original, because the new nodes must reflect the channel assignments and various factors encoded in glTF. There's no ability to recover the original node arrangement, as it is not needed for rendering and so was not stored in the file.

Generally if you want to keep the original Blender node arrangement, you should keep the original Blender project around. But the auto-generated arrangement you get from loading a glTF will round-trip in the sense that it can be exported to a second glTF file without any further alterations.

$\endgroup$
1
  • $\begingroup$ Ok wow, not a bug. We treated it as such, because we had this surprising behaviour in another workflow using re-importing (not Blender) and we needed to fix it. $\endgroup$
    – taiyo
    Jul 17, 2023 at 22:08
2
$\begingroup$

This is pretty much an export bug of the glTF exporter. In the glTF specification, an ORM texture is produced on export (Occlusion, Roughness, Metallic). It expects the channel values as grayscale and packs them together, roughness goes into the green channel and metallic into the blue channel. If you check the produced texture with a glTF/glb viewer (for example Babylon Sandbox) you will notice the following:

enter image description here

the blender material has Metallic set to 0 and Roughness set to texture -> but the blue channel of the ORM texture is white! Hence the pink appearance. The generated blue channel should have contained zero's because Metallic was set to 0. It seems that the exporter ignores bare values and only consumes textures correctly. Therefore you should add a completely black texture into the Metallic slot. This is ofc better because you can change the metallic texture to your liking and dont need to "multiplicate away" the wrongly imported metallic values (in your second screenshot).

$\endgroup$
1
  • $\begingroup$ Perfect, thank you. $\endgroup$
    – Ben
    Jul 13, 2023 at 22:16

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .