pixi-compressed-textures
pixi-compressed-textures copied to clipboard
pixijs
Plugin always assumes that compressed texture has not premultiplied alpha
Is it intentional?
For example texture packer supports dds/dxt5 with premuliplied alfa:
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?
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)
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?
btw codeandweb is author of texturepacker, I asked him for clarification here
do you use SpectorJS
yes
I'm rendering interleaved png/dds files
screenshot from before hacking:
blendFuncSeparate is for dds, blendFunc for pngs
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.
thats clever :+1: 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
What do you mean? it should be the same if you use usual blendmodes and not custom shaders.
woudn't BLEND_MODES.NORMAL_NPM change how semi transparent portions of texture look like? (if those texture are already alpha premultiplied)
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.
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.
Yes, but as a result, quality for smooth alpha does have a problem: https://knarkowicz.wordpress.com/2009/11/18/premultiplied-alpha/
@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