Opaque of AlphaBlendModeTest.gltf has not passed

[cx20]

I tried to display AlphaBlendModeTest.gltf in RedGL.

However, Opaque of AlphaBlendModeTest.gltf has not passed.
RedGL + AlphaBlendModeTest.gltf result:

three.js + AlphaBlendModeTest.gltf result:

[redcamel]

@cx20
Before this problem is solved, the normal interpretation of the double side must be processed first. #470

[redcamel]

@cx20

Currently solved some part.
But I still did not know the reason for the red box part.
Could you give me some advice on this?

[cx20]

@redcamel I can not advise because of lack of understanding.
@emackey Do you have any advice?

[emackey]

In this image, it appears the alpha values are being multipled by the base color image prior to rendering, turning that color black when the alpha is zero. glTF defines the alpha channel as being completely ignored when "alphaMode": "OPAQUE" is set, so the base color should not be multiplied by the alpha channel here.

The same effect can be seen on the blue-and-yellow striped part. In the above screenshot, you can see the stripes fading away to black as the alpha values become lower. But in the ThreeJS screenshot at the top of this thread, the stripes remain constant, independent of the alpha values, which is correct for glTF.

As a separate issue, take a look at the middle card, "Cutoff 0.25". We shouldn't see any marble texture from the background leaking through this card. glTF's alpha-masking mode is considered opaque, with blending disabled and depth-writes enabled. It just discards fragments that fall below the cutoff value, but does no other "transparent" type operations.

[redcamel]

@cx20 @emackey
I am still working on this problem.
But I will surely solve this problem.

[redcamel]

Current research situation.

• resolved blend and mask.
  

• but opaque mode is not yet.
  The red box area has not been resolved yet.
  It may be because the primitives tangent has not yet been parsed.
  it will be fixed soon.
  

[emackey]

I haven't looked at your code, but I don't think the tangent vectors would be the problem here. The most unusual thing about that checkbox is that the texture there intentionally has all zeros for the alpha channel, to test if the engine will discard zero-alpha fragments in opaque mode (which it should not). In the screenshot, they're not being discarded, but they are turning black, probably as a result of being multiplied by zero someplace.

[redcamel]

@emackey @cx20
As you said, it has nothing to do with tangents.
and so checked Texcoord. move the uv.y value slowly over time, the texture color is output correctly.
so I suspect that there is a problem with uv parsing.
But currently I can not find any problem. ㅠ_ㅠ
It will take more time maybe resolve this problem.

Are there any problems you anticipate?

origin

time base move texcoord.y

[cx20]

Although it may not be an accurate advice, how about trying tracing WebGL with Chrome extension SpectorJS?

The following is the result of tracing WebGL processing of Three.js with SpectorJS.

[cx20]

The following is additional test data.
https://github.com/KhronosGroup/glTF-Asset-Generator/tree/master/Output/Material_AlphaBlend
https://github.com/KhronosGroup/glTF-Asset-Generator/tree/master/Output/Material_AlphaMask

Some seem to be different from assumed results.
If you clear these tests one by one, I think that the problem of AlphaBlendModeTest.gltf will be solved as well.

[redcamel]

@cx20 @emackey

RnD Result

Finally found the cause.
This is because we used window.createImageBitmap.
RedGL supports 'OffscreenCanvas'. So I load the image via window.createImageBitmap. However, 'premultiply' is enforced at when use window.createImageBitmap. (And because of the browser flipY option.)

There is an option in the MDN document not to run premultiplyAlpha, but it is inferred that it does not work as intended.

I will decide on this part and update it soon.
I came back very far, but I learned many things ^^