2 channel diffuse textures


Just a simple tutorial on how to pack diffuse textures into two image channels:


Nice technique. Seems like you could use the red and blue channels for your diffuse and your green and alpha channels for normal and get two textures for the memory cost of one. I’d be interested to see a comparison between compression artifacts using this technique vs a standard dxt1 diffuse texture.



This is when I lament the loss of palletized textures as a standard. All of these images would hold up quite well as an 8-bit texture. Sure the palette take up 768 bytes, but that’s usually fine. You can do this with a LUT in a 1x256 pixel texture on modern hardware I suppose.

On the right is the 8 bit version of the same image.

EDIT: BTW, I realize that a 4 bit DXT image is half of 8 bits, and that you’re probably packing additional data in the other channels…


bcloward: Very good point, I’ve just updated the article with thoughts on
what to put where and also added artifact comparisons.

btribble: That’s an interesting thought… Now I wonder if we could store
4, pseudo palettized diffuse images in a high res texture and a LUT. I’ll
do some research on this.


Wow - your update is great! Nice work.


[QUOTE=Zoltan;24194]Now I wonder if we could store
4, pseudo palettized diffuse images in a high res texture and a LUT. I’ll
do some research on this.[/QUOTE]

You’ll have to make sure that the palette is well sorted so that the errors you’re going to get when the image is compressed still finds a reasonably similar value. Also, you might be able reduce the number of pixels in the palette to 5 or 6 bits depending on which channel you’re working with. My biggest concern would be that the cross talk between the channels when the DXT block compression kicks in is going to be noticeable.


Yeah… crosstalk ruined all the ideas I had so far. /shakes fist


I’d be interested in seeing this using LAB colors, with L in green and A/B in alpha (high bits and low bits), plus two extra channels for masks. LAB does an even better job at preserving luma than HSV, plus I suspect the sat range would be better even though it may make the images slightly more saturated than they are.


The tricky part is storing two values in a single channel. Bit operations are non-GPU friendly
and the data would be very sensitive to compression artifacts. Maybe putting a and b into
alternating pixels, checker board style… Yeah, needs research but an interesting idea.