Verify that the handling of transparency is correct about collada2gltf HOT 4 CLOSED

I agree, this looks sketchy. @tfili do you know off the top of your head if this is what is actually intended:

color = vec4(color.rgb * diffuse.a, diffuse.a * u_transparency);
gl_FragColor = color;

from collada2gltf.

@javagl @pjcozzi Just taking a quick look this is what I've scraped together:

If you look at the COLLADA spec (https://www.khronos.org/files/collada_spec_1_4.pdf) under the section Determining Transparency (Opacity) on page 223. You'll see that for A_ONE opaque mode the color is defined

result.r = fb.r * (1.0f - transparent.a * transparency) + mat.r *
(transparent.a * transparency)
result.g = fb.g * (1.0f - transparent.a * transparency) + mat.g *
(transparent.a * transparency)
result.b = fb.b * (1.0f - transparent.a * transparency) + mat.b *
(transparent.a * transparency)
result.a = fb.a * (1.0f - transparent.a * transparency) + mat.a *
(transparent.a * transparency) 

And in the getTransparency function here we compute the value that will eventually become u_transparency to be (transparent.a * transparency).

So with all that I think there is a bug and the actual shader code should be

color = vec4(color.rgb * u_transparency, diffuse.a * u_transparency);

Does that sound right to everyone?

from collada2gltf.

So with all that I think there is a bug and the actual shader code should be
color = vec4(color.rgb * u_transparency, diffuse.a * u_transparency);
Does that sound right to everyone?

I think that

color = vec4(color.rgb * diffuse.a * u_transparency, diffuse.a * u_transparency);
//                       ^^this^^^

may not be omitted here, depending on where exactly the initial value of diffuse.a comes from (a texture or a uniform), but I'd have to match this with the writer code that you linked to. At least for the case of one of the VC model shaders ( https://github.com/KhronosGroup/glTF-Sample-Models/blob/master/1.0/VC/glTF/VC2FS.glsl ), I think it is necessary for the case that someone set the u_diffuse uniform to something where a < 1.0, and additionally sets the u_transparency uniform to be < 1.0.

Iff this is right, it would be in line with what I wrote in javagl/JglTF#6 (comment) , and I think that this could eventually fix KhronosGroup/glTF#576 . And, just as another pointer: The "Possibly unrelated..." part from KhronosGroup/glTF-Sample-Models#8 is actually related to this issue.

from collada2gltf.

2.0 implementation of shader generation (based on gltf-pipeline) should do this correctly - closing.

from collada2gltf.