4
$\begingroup$

I am making an engine with 2D volumetric transparent objects and need advice how to store transparency data. There are 3 requirements:
- The transparency textures need to be easily editable with common tools (e.g paint.NET, so .png preferred)
- Since a pixel value will determine the light transmittance 8 bits are not enough - in this case lights could travel maximum 256 pixels in non fully transparent textures.
- It should be clear what each pixel means when looking at the texture.

I've tried using the HEX values from RGB pixels. For example heres a strip with HEX values from 0 to 0xFFFFFF:

RGB strip

While this gives enough values (256*256*256), looking at the image its not clear what each pixel means (=if I'd pick a random pixel from this image you could not tell approximately the alpha value).

Does anyone know a good method how to represent >256 values in an RGB texture, where its clear what each pixel means?

$\endgroup$
  • $\begingroup$ You could use a 16 bit image format, but then paint dot net wont cut it. Though quite many other editors would work fine. $\endgroup$ – joojaa Aug 13 '16 at 8:19
  • $\begingroup$ @joojaa and how well do GPUs cope with 16 bit textures? This game needs to run on mobile too. $\endgroup$ – sydd Aug 13 '16 at 9:25
  • $\begingroup$ What are you trying to accomplish with a 16-bit or 32-bit alpha channel? The human eye can barely distinguish 64 levels of any given color, so it's unlikely that more bits for your alpha channel will be noticeable. $\endgroup$ – user1118321 Aug 14 '16 at 1:11
  • $\begingroup$ To answer your question above, modern desktop and laptop GPUs should have no problem using 16-bit half float textures. Mobile will be another story. Some may support it but most probably won't at this point in time. $\endgroup$ – user1118321 Aug 14 '16 at 1:12
1
$\begingroup$

A normal argb image has 8 bits per channel and therefor 32 bits per pixel, the size of an integer. That's why it's stored in an integer a lot of the times.

Floats are also 32 bits.

Something that you can do, is to have a separate image that has only 1 channel, for the transparency. If you make that a float type (or for 16 bit, another type that uses 16 bits instead of 32 bits), then it will take about the same room as an extra normal image.

After a quick google, I found out that most programs are limited to 8 bit per channel, but there should be programs that have 16 bit per channel. This gives you at least more precision.

When loading in the normal 16 bit image (your texture, if you use 16 bits per channel), you could convert the normal rgb part to 8 bits, and load that in and then create a new image that has 1 channel that is 16 or 32 bits, and then store the alpha value in there.

This way it should be similar to having an extra image, and you do, but instead of 2 textures, you have the transparency in another image.

What would then also be possible to do, is to store the transparency in a normal rgba image (inside your program as a texture), as you were talking about, and then in the shader, you manipulate the rgba values to restore the transparency value. This way you wouldn't need a floating point image.

This is just a quick idea. As far as I know, this should work. (This is my first answer here! whoop! whoop!)

Hope it helps and good luck!

https://developer.mbed.org/handbook/C-Data-Types

(^for the data sizes)

$\endgroup$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.