Plugin always assumes that compressed texture has not premultiplied alpha

[krtr]

Is it intentional?
For example texture packer supports dds/dxt5 with premuliplied alfa:

[ivanpopelyshev]

https://en.wikipedia.org/wiki/S3_Texture_Compression

DXT5: not premultiplied.

Even more, I didnt see any formats with premultiplied alpha that are supported in webgl.

@CodeAndWeb any comments?

[krtr]

btw with little hacking, mainly by removing method: https://github.com/pixijs/pixi-compressed-textures/blob/master/src/CompressedImage.ts#L63

I get it to work as expected
(and solved my issue with too many drawcalls coused by interleaved different blend modes)

[ivanpopelyshev]

with little hacking

That's how, like, everything works in PixiJS :)

(and solved my issue with too many drawcalls coused by interleaved different blend modes)

do you use SpectorJS?

[ivanpopelyshev]

btw codeandweb is author of texturepacker, I asked him for clarification here

[krtr]

do you use SpectorJS

yes

I'm rendering interleaved png/dds files

screenshot from before hacking:
blendFuncSeparate is for dds, blendFunc for pngs

[ivanpopelyshev]

If your png's are extruded in transparent places - you can just use alphaMode = NPM for them too :) for each texture you load, set it before its rendered first time.

[krtr]

thats clever 👍
some of the textures are in fact with alpha values from set {0.0, 1.0} but unfortunately I have a lot of overlay like effects in textures

[ivanpopelyshev]

What do you mean? it should be the same if you use usual blendmodes and not custom shaders.

[krtr]

woudn't BLEND_MODES.NORMAL_NPM change how semi transparent portions of texture look like? (if those texture are already alpha premultiplied)

[ivanpopelyshev]

That's the whole point of NORMAL_NPM.

Yes, theoretically, it could have another meaning - that the result is not premultiplied. In webgl there is no way to do that. Thus, all PixiJS draw operation results are premultiplied.

=====

The only downside - you have to extrude colors using texturepacker or photoshop, so there wont be "transparent black" in the picture, linear filtering doesnt like it.

[CodeAndWeb]

I currently don't see why the data should not be pre-multiplied. TexturePacker applies the pre-multiply before packing the image data. This is why we can also put pre-multiplied data into PNG files (even if they “officially” don't support this) — the packing algorithm does not “see” that it is pre-multiplied. It's just valid pixel data.

The dangerous way is working with non-premultiplied-data and relying on information in the transparent pixels after applying lossy compression. E.g. if you use a normal map in RGB and put a specular map in the alpha channel. A packing algorithm might easily set the transparent pixel's RGB values to 0.

If the data is pre-multiplied, all transparent pixel's RGB values are already 0... so there should not be any problem.

The shaders don't care about the compressed data — just the RGB values after unpacking the pixel data.
So it's a matter of blend modes / shaders how the pixel data is rendered.

[ivanpopelyshev]

Yes, but as a result, quality for smooth alpha does have a problem: https://knarkowicz.wordpress.com/2009/11/18/premultiplied-alpha/

[krtr]

@CodeAndWeb I wonder if it would be possible for texturepacker to put information about alpha premultiplication to spritesheet manifest/definition file so loaders could decide to fix premultiplication on their side or not