RGB values are broken in new BabylonVersion

when exporting from 3ds max to babylon-sandbox a neutral grey has wrong values in the sandbox inspector.

This also happens when setting the value in code. For Example: material._albedoColor = new BABYLON.Color3(0.5, 0.5, 0.5); will not become a neutral grey rgb(128,128,128) in the sandbox.
Here some Screenshots.

I know that in the older Version of babylon everything works fine.


Welcome aboard!

The color you set in albedoColor (and all color properties of the PBR material) are understood by the system as being in linear space.

However, when using a color picker, the color must be in gamma space because it is how users are working with them. So, the (0.5, 0.5, 0.5) is converted to gamma space, and the result is (0.73, 0.73, 0.73) which corresponds to (186, 186, 186) once multiplied by 255.

I don’t know in what color space 3dsMAX is working in the color picker, but it should logically be the gamma space. So the (0.5, 0.5, 0.5) value we see in the screenshot should be in gamma space, and would be translated to (0.22, 0.22, 0.22) in linear space and should be the value saved in the gltf/glb file.

Are you able to provide the gltf/glb file you are using so that we can have a look?

for some reason I am not allowed to upload the glb here - but here is a wetransfer-Link

ok - so 3dsMAX is one thing - but what’s with the issue that if i use specific values in code that they get converted too?
As I said both workflows, 3dsMax and to change values in code directly worked always fine for me in older babylon versions…

i also checked the glb - and the saved value is like it should be. Anyway when I import it to the sandbox the value gets changed.

Here is the according glb-File-Snippet after export from 3dsMAX with the correct value in it:

What we changed is that the inspector now displays the colors in gamma space in the color picker, whereas before 4.2 it was showing the linear values instead. But the actual values in the color property has not been changed.

Having said that, the gltf spec is saying that baseColorFactor is in gamma space and should be converted to linear, something we don’t do (and were not doing in previous releases neither).

So, here’s a PR that corrects this problem:

Note that this PR fixes two problems, hence the wrong title (which corresponds to the first problem fixed)!

1 Like

I guess if the changes are merged it will work again.

Thank you for your help.

Thanks @Evgeni_Popov, I faced the same problem and I can confirm that this is only related to the Inspector (I ran this playground https://playground.babylonjs.com/#2FDQT5#652 with Version 4.0.3 and 4.2 and the actual rendering did not differ).

However, I have a follow-up question regarding what you said on baseColorFactor: I totally get that from your perspective this is “only” a bug fix, but in practice this would mean that each GLTF model with PBRMaterials would look differently after the PR has been finally released. Or do I get something wrong?

I’m pretty sure that quite some people (like us) have “optimized” their GLTF models to look as good as possible with the current interpretation of baseColorFactor and I wonder if there is any “keep-it-as-it-is” switch planned.

1 Like

My bad, it’s the base texture which is in gamma space in gltf (I read the spec wrongly), not the baseColorFactor! So I reverted my change.

So, as we do have (0.5, 0.5, 0.5) in the gltf file, it means either the color picker in 3dsMax shows rgb values in linear space or the exporter does not convert the color to linear… As I don’t know 3dsMax nor the exporter, it’s hard for me to tell.

Pinging @Guillaume_Pelletier who knows the exporter well to get his inputs about this.

@Peregrin It was my mistake, so nothing will change in that regard.

1 Like

@Evgeni_Popov No problem & thanks for the quick answer!

The 3ds Max Exporter works fine as it can be seen in my first post (screenshot).
The values (0.5, 0.5, 0.5) get exported to the glb correctly.
Also the Sandbox shows the right color (visualy) at the Object itself (viewport). The only thing that’s broken is the inspector, showing the wrong color value in the colorbox.

So as I said - If the changes are reverted, everthing should work fine again.

Thank you again.

So I guess everything is correct and the difference you see in the inspector is because of this:

This one is not a bug, it was done on purpose.

1 Like