Colors too dark after gltf-Export from Blender (again!)

[lari]

Hi there!
I am new and not sure, if it is the correct proceeding to just post here. I am having a similar issue as described by K9Kraken, in so far as the colors in panda3d are way darker than in Blender, though I do not use the Panda shader, but the Blender shader only.

I am using a Principled BDSF shader in Blender, so sRGB should not be the problem, right?
I saved the Blender file as a .blend and then used the blend2bam commandline tool of Moguri with the following options: blend2bam --pipeline=gltf -m=pbr --physics-engine=bullet [my src] [my dest]

I am new to all this, and not sure if this is a lighting issue or an importing issue.

Unfortunately, as a new user, I cannot upload attachments and only one picture, so I crammed all the information into one shot (the blender look, the panda look and the blender shader I used) :

EDIT: I read up about trust levels and now I can!
hook_tip_scaled10.blend (541.4 KB)

Please also tell me about any etiquette the discobot didn’t teach me and that I missd! Thank you!

[serega-kkz]

Of course I’m not up to date on PBR materials. But suppose you forgot to create uv coordinates.

[K9Kraken]

In Blender highlight your model then do Ctrl+A and choose “Rocation & Scale”
See if that makes any difference.

[Moguri]

Regardless of the Blender options, panda3d-gltf and blend2bam (when using a glTF pipeline) will attempt to load diffuse/base_color textures as sRGB, which results in the texture data getting converted from sRGB to linear colorspace. By default, Panda does nothing to convert these linear color values back to sRGB. You either need to use an sRGB framebuffer or write a shader that handles writing sRGB values back into the framebuffer.

You say you are not using the Panda shader. I assume this means you are not using Panda’s auto-shader. Are you writing your own shaders?

[lari]

Thank you. I understand your answer to K9Kraken’s question better now.
I meant that I did not use any shader in panda3d (not even the auto-shader), which I know now do.

I tried the following:
First, adding the following two lines to my code:

  loadPrcFileData('', 'framebuffer-srgb true')
  render.setShaderAuto()

This did not result in any visible change:

Next, I wrote directly into the Config.prc-file, disabling the model cache (because of K9Kraken’s problems, just to be sure) and enabling the srgb-framebuffer:

  framebuffer-srgb #t

This resulted in the predefined environment losing color, but my object stayed the same:

(Also, I realize that this topic might be similar to this one, so I am adding the link for other people looking around.)

[lari]

Thank you for your answer. I tried it, but it did not change the outcome.

[lari]

Thank you, too! I tried your suggestion, I also tried different objects but this didn’t change anything, either.

[Moguri]

Yeah, I agree that this isn’t looking like an sRGB issue. Could you please make sure you are using v0.4 of panda3d-gltf? I realized over the weekend that there weren’t builds of v0.4 available on PyPI and fixed that up.

[eldee]

Looking at your material settings, you have metallicity set to 1.0 and no diffuse texture, that means your object is highly reflective and has no diffuse component (apart from the white color). As panda-simplepbr does not handle reflections, your object will appear pitch black or the diffuse texture highly darkened. (And the white spot you see is the specular reflection)

[lari]

For later reference, I was using:

panda3d==1.10.4.1
panda3d-blend2bam==0.9
panda3d-gltf==0.3
panda3d-simplepbr==0.2.3

I now upgraded to v0.4 of panda3d-gltf, reloaded Pycharm, re-converted the blend-file with blend2bam and got the same result.

[lari]

Hi eldee, thank you for your tip!
I think the reflection might be a factor but not the main problem. To illustrate, let me show another (quickly and dirtily unwrapped) example:

Blender:

Panda:

[eldee]

I think I’ve found the problem, or at least one potential problem: the glTF loader if there is no normal map in the model it applies a fallback normal map using the default value (0, 0, 1) which is not correct.
In the shader, the normal is generated from the normal map using the following formula

N = normalize(2 * tex - 1)

With the current value that generates a normal that is tilted (N=normalize(-1, -1, 1) and so shades the model.

The correct default value is (0.5, 0.5, 1)

[rdb]

Great work tracking that down. I have suggested a fix upstream:

Fix color of fallback normal map

[eldee]

Thank you for creating the PR I wrote this in a hurry and I didn’t had the time to create it.

However this only fixes a corner case (simplepbr is configured to use normal map but parts of the model do not have one) but I’m still looking

[eldee]

I had time to investigate further and I found several bugs related to how the roughness is handled, some minor ones, but a critical one that may explain the darkening of the models:

• The roughness coefficient is in channel ‘g’ of the MetalRoughnessMap and the metallic coefficient in channel ‘b’ and not the opposite. This is the main reason the models looks too dark, as the coefficient are swapped, a rough surface is deemed reflective and so appear darker as there is no IBL.

• The roughness in the material and in the MetalRoughnessMap is the perceptual roughness and not the alpha roughness used in the equations, the alpha roughness is the square of the perceptual roughness. This make the rough surface appears too smooth

• There is no need for a minimum roughness, this prevent purely reflective surfaces. The 0.04 factor is only to be used for F0 for non-metal surfaces. This make purely reflective surface blurry.

• The limit for F90 is usually taken at 2% and not 4% This is just to be inline with reference viewer.

See https://github.com/Moguri/panda3d-simplepbr/pull/3

Note, there are still problems with the orientation of the normals (All the reflections should be in the same direction)