Hello,
I have opened the same .gltf file with 3 different viewer and can’t figure out why results are different
It seems some part are not displayed in Babylon playground
This is weird and I’m sure there is a reason
Best regards,
Ph
Hello and welcome!
Here is what I’ve got from your model from PG:
Sandbox - did you try it? Your PG has no environment, maybe this is the reason
Microsoft Viewer
Hi @labris,
Many thanks for your time and advice.
I have downloaded the gltf file from repo and find out that my repo was not synced. Sorry for the inconvenience and many Thanks.
Anyway after having synced the gltf repo, results in ThreeJs and Babylon are still different :
versus BabylonJS playground :
https://playground.babylonjs.com/#NXT1DQ#2
The problem is that the alpha component of the baseColorFactor properties of all materials in the gltf file is 0. If you set alpha to 1 for all materials it does work:
https://playground.babylonjs.com/#NXT1DQ#3
I think it’s a problem on our end: according to the spec, if alpha mode = OPAQUE, we should ignore any alpha value. In our case, that would mean we should set it to 1 whatever its original value is. What do you think @bghgary ?
Thanks for your answer,
To be complete in my desciption, the original model comes from a Collada file converted with this. When doing so, the “alphaMode”: is set to “BLEND” but then all parts appear transparent.
It is visible here :
https://playground.babylonjs.com/#F46UPW#1
Maybe transparency are simply inverted from Collada to Gltf (1.0-transparency)
So I decided to set to “OPAQUE” by hand in gltf file directly.
But by doing so I have the issue you noticed in Babylon.
So it seems either ms-viewer or ThreeJs viewer are not handling this parameter in a strict manner and the error is not seen.
If you simply replace BLEND by OPAQUE it will work.
In the other PG, you did not simply replace BLEND by OPAQUE, you also added:
"baseColorFactor": [
1.0,
1.0,
1.0,
0.0
]
in all materials, which sets an alpha value of 0.
As said, I think that should still work, waiting for @bghgary inputs about that.
Hmm, this is a weird case. The glTF shouldn’t be written this way since it doesn’t really make sense, but it should render correctly as @Evgeni_Popov points from the spec. This is a bug either in core engine or the loader depending on what the proper behavior is for the engine. The loader sets alpha to 0 for this asset, but it also sets transparencyMode to OPAQUE. We added transparencyMode for glTF, so I would expect that setting this to OPAQUE would ignore the alpha property, but that appears to not be the case.
@sebavan What do you think? When setting transparencyMode = OPAQUE, should we always set alpha=1 to albedoColor when passing it to the shader (we would also need to get rid of the alpha from the albedo texture/opacity texture)? Currently, it seems the behaviour when alpha < 1 and there is no blending defined at the webgl level is that the browser is doing a blending with the background color of the canvas. Note that changing this behaviour would be a breaking change (I don’t know if people are using this possibility or not…).
I would prefer to do it at the GLTF loader level if possible ? like forcing it to 1 if opaque but not in the pbr itself
We can definitely do it at the loader level. I still think it’s weird to have a transparencyMode of opaque but alpha still does something.
This should already happen.
Indeed, it seems the current shader code does not update the alpha value when transparencyMode = OPAQUE, its value is only coming from the alpha component of the albedoColor.