3
$\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$
4
  • $\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
    Commented Aug 13, 2016 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
    Commented Aug 13, 2016 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$ Commented Aug 14, 2016 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$ Commented Aug 14, 2016 at 1:12

1 Answer 1

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 and acknowledge you have read our privacy policy.

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