Using GetPixel/GetPixels on compressed textures

I have a function that requires access to GetPixel/GetPixels. But, whenever I try to do it on a compressed texture, it fails.

Storing all the textures uncompressed is not a good option for us. Is there any way to use GetPixel on a compressed texture?

Right now, no you can’t do that. What are you using GetPixel(s) for?

Short answer is procedural textures (combining 2 arbitrary parts into a whole).

This is mentioned as implemented in the 2.6.1 changelog but I can confirm this feature is still broken as of now in version 3.0.0f5, at least with DXT5-compressed textures.

On a set of three NPOT, DXT5-compressed textures without mipmaps, I get incorrect results from Texture2D.GetPixel on at least two of them (third one seems to work at human eye level but I didn’t checked precisely each returned bit of data). If those same textures are imported again as, e.g., ARGB32 uncompressed, then GetPixel returns the correct color values.

A bug report has been submitted to the support team.

Sure enough, the 2.6 change log (not 2.6.1, actually) claims:

“Texture2D.GetPixels now supported on compressed textures.”

It would make my day if this were to actually work!

The current docs are clear that this will not work for “SetPixel”, but there is no mention of texture formats at all on the “GetPixel” page.

It seems like grabbing values from compressed textures should work. On mobile platforms, being limited to uncompressed textures makes GetPixel all but unusable in some cases.

Mat - have you heard back on that bug you submitted? We’re in version 3.5 now, and this is still not working/available.

Aras? Any word on why there’s a disconnect between the change log and the actual functionality at this point?

Well, except it does work. I haven’t tried it on iOS, but it does work with compressed textures on desktop for sure.

–Eric

D’oh! Sure enough - it works fine with DXT5 for a desktop build. Thanks for pointing that out, Eric.

Unfortunately, that doesn’t help me - I need it to work with PVRTC_RGBA2/4.

So . . . is that a bug or a feature request then?