glTF 2.0 'OPAQUE' mode broken

[emackey]

When alphaBlend mode is set to OPAQUE, glTF 2.0 specifies that source alpha values will be ignored, not pre-multiplied. There is a test model to check this: AlphaBlendModeTest.

This was broken recently. I ran git bisect on this, and I'm sorry @OmarShehata, it narrowed this down to one of your image handling commits here: b772d52 (part of #7579).

[emackey]

Here's a screenshot of the model just prior to the problem, in parent commit 96cbc18:

And here's what happened in b772d52:

Typically this means that the alpha values are being pre-multiplied, when they should be ignored.

[emackey]

It looks like the strength of the blending has noticeably changed in the Blend test here too, on that same commit. I don't know if that's as well defined in glTF, but most viewers treat the alpha channel closer to what's shown in the first screenshot.

[OmarShehata]

Thanks for tracking this down @emackey ! Looks like this is indeed an ImageBitmap issue. One of the major issues with implementing it was that an ImageBitmap cannot be flipped during texture upload. It looks like premultiplied alpha is another setting that would need to be done passed on image decode to get ImageBitmap to work correctly.

Here's my local Sandcastle. This expects the AlphaBlendModeTest folder from the glTF sample models repo to be copied to Apps/SampleData/models/.

Changing Resource.js:1894 to:

Resource.createImageBitmapFromBlob = function(blob, flipY) {
        return createImageBitmap(blob, {
            imageOrientation: flipY ? 'flipY' : 'none',
            premultiplyAlpha: 'none'
        });
    };

Fixes the issue. This potentially impacts imagery as well.

[OmarShehata]

@lilleyse I can't seem to find any logic when loading a glTF to set premultiplyAlpha. It seems to just always be false? Or to be based just on the given pixel format.

[emackey]

I think "always false" might be correct for glTF 2.0, particularly if the BLEND side of the test model continues to work.