Yo @Evgeni_Popov … I got a question about lightmaps…
Right now, i currently PACK my lightmaps into a RGBD/PNG image.
Is there ANY advantage to further encoding those lightmaps as KTX2.
Without using lossy compression that ktx2 image file can be quite large… i am assuming because of the full mipmap chain.
Should i keep lightmaps as RGBD packed PNG files or should i go ahead and convert those lightmaps to KTX2 with toktx.exe ???
I don’t really know…
I think the best way is to test. You should try to use etc1s which compresses better than uastc. I think it should work ok for a lightmap.
Or maybe the easiest: just give the choice to the user to use rgbd/png or ktx2 for lightmaps, that way it’s up to the user to decide what they want to use.
hmmm…
@Evgeni_Popov
If i just use –uastc 2 as the args… the light maps look crappy, not anywhere as clean as RGBD packed png.
What would be the toktx to create a mipmap ktx2 with LOSSLESS compression so that lightmaps dont look like crap… Or i guess i could always keep lightmaps as PNG.
There’s no lossless compression with uastc/etc1s I think, that’s the point of the format, to have lower texture sizes. You can try to use other levels for uastc and see if that helps (the 2 in --uastc 2).
It seems ktx2 lightmaps are working ok for him: GitHub - 0beqz/lightmap_interior_test: three.js lightmap interior test
I will try without RGBD packing the png before converting to ktx2
Also , I thought the point of ktx was preparing the texture for GPU… like pre mipmapoing… and the compression was another feature
But I understand if everything has some compression on
Maybe this doc will help shed some light:
@MackeyK24 not sure if this was the case for you but the texture doesn’t need a vscale of -1 when converting to ktx2 from tools like toktx. That solved it for me.