Open BastiaanOlij opened 1 year ago
I don't remember. If it fixes things for you, then it is probably what's required. You can verify by following the PNG decode path, which explicitly calls something related to bgra conversion (quite unnecessarily, but it's too ingrained into the code now).
Thanks @wolfpld , I guess the question here is, is ETC internally BGRA? Ergo when we supply RGBA data, does ETCPAK convert it to BGRA and save it as such?
I have a suspicion that us loading ETC data and then telling the GPU the data is RGBA, that this is actually where it goes wrong, not in saving, and us flipping the R and B channels on save just works around the issue. Is there any place to find good info on this?
edit hmm, no thats probably not it, we're using VK_FORMAT_ETC2_R8G8B8A8_UNORM_BLOCK
so you'd assume Vulkan is treating the data as RGBA
There is only one way to decode the ETC data (i.e. transform the ETC binary stream into vec4 RGBA fields in shaders). Only input data to etcpak matters.
Then i am happy that our changes in Godot are doing the right thing, does then indeed seem to be the input to ProcessRGB(A)
is BGRA.
Hi,
I'm trying to figure out an issue that we're having where it seems that the ETC compression routines are expecting BGRA input. I'm not ruling out that we are doing something wrong later on in the pipeline and assuming the decompressed image is in BGRA format and thus resulting in it displaying wrong.
Can you confirm whether
CompressEtc2Rgb
andCompressEtc2Rgba
expect data in BGRA format?Cheers,
Bas