[ARSPR]

While testing DaBrain's new MediaVPs compilation I've noticed that a lot of effects and background nebulas have FULL white alpha channels. So I thought: "this is going to cause 'black boxing' effects". But then I notice they work fine so I just don't understand how alpha channels are handled.

What I thought:

• Ship Textures. Alpha sets transparency if present. White is opaque.
• -shine maps. Alpha sets environmental reflectiveness. White is full mirror effect.
• Glow point, background, laser, explosion textures and so on as a general rule. If there's no alpha, black dots are transparent. But if there's alpha channel, white is opaque and black is transparent

This is what I thought because of:

• The problem I mantised about blue_glow4. In the original VP 3.6.8. effects one, a full white alpha caused a black box to appear.
• Newest planetxx textures. They have a white alpha with the shape of the planet, the rest is black.

But then, looking in vps I discover that explosions, weapons and other background nebulas have full white alpha channels and don't show black box effects. As an example, I upload one screenshot taken with DaBrain's new VPs. Prometheus R bitmap (PrometheusR_AniBitmap_0000.dds and so on), the red nebula (neb01.dds) and the green nebula (neb05.dds) have full white alpha channels. And as you can see, the black portion of the bitmaps is fully transparent, there's no black boxes.

So, please, can any coder explain me how alpha channels actually work?

[attachment deleted by admin]

[taylor]

The game will ignore DXT1 with an alpha layer.  It will instead just use it as if it didn't have any alpha.  Other than just wasting memory by having to load 32-bits worth of color data instead of 24-bit there isn't any real harm in it, but technically, if we ever do support alpha on DXT1, all of those old images will break.  So, if any of the effects are DXT1 then an alpha layer isn't going to affect how they work since they are forced to 24-bit and therefore aren't subject to the new blending mode.  Perhaps that is what you are seeing here.

And one more point, something that I've noticed lately with images that I create, is that sometimes an alpha layer is added on file read with some apps.  For instance, GIMP with the DDS plugin (newer versions of it anyway) will identify DXT1 as having an alpha layer when it doesn't, even going so far as to create an all white alpha channel for the image automatically.  But if I go look at the file header directly then I can easily tell that is doesn't have an alpha channel.  The behavior does make things very confusing though.

[ARSPR]

Thanks Taylor

The strange issues with born-from-nowhere alpha channel also happens to me with Photoshop and DDS pluging (although as I don't really know how to use this software I thought it was something I was doing wrong...)

Do you know if there's any utility to show which kind of DDS a file is? In all these 'conflictive' textures, and using DDS view, I get they are 32 bit, although seeing how they behave, they must be 24+1 (DXT1a).

It would be great to have a viewer which tells you which kind of DDS you have. White 8 bit alpha means trouble and white 1 bit alpha doesn't, but in a graphic view you just see the same, a full white square.

OTOH, I suppose that DXT1a 1bit alpha channel is also ignored in ship maps and -shine maps. Am I right?


BTW, I've added this info to Wiki: Texturing (Effects textures and Alpha Channel management). Please check it is alright.

[taylor]

Do you know if there's any utility to show which kind of DDS a file is?

Yeah, but it's Linux, which might not help you out very much.

There is a command called 'file' which will identify most files and tell you what they are.  It uses a 'magic' file which has identities in it for various file types.  I have a customized magic file for dealing with FSO types, which can give me something like this:

Code: [Select]

[taylor@dragon data]$ file *
aeolus-htl.dds:         DirectDraw Surface (DDS), 1024 x 1024, 11 mipmap levels, DXT1-alpha
ast01.ibx:              FS2_Open Index Buffer eXchange (IBX) file, version 1
bomber05-01.dds:        DirectDraw Surface (DDS), 1024 x 512, 11 mipmap levels, DXT1
bomber05-01-shine.dds:  DirectDraw Surface (DDS), 1024 x 512, 11 mipmap levels, DXT5
bomber05.pof:           Volition Polygon Model (POF), version 2117 (Freespace 2), 8 models, 4 textures
fighter2s-02a-glow.eff: FS2_Open Effect Animation (EFF), DDS, 37 frames at 25 fps
shieldINFFighter02.ani: Volition ANI, 112 x 93, 5 frames at 15 fps, 1 key frame
I'm not sure that there is anything that provides similar functionality for Windows.

OTOH, I suppose that DXT1a 1bit alpha channel is also ignored in ship maps and -shine maps. Am I right?

Right.

[ARSPR]

Taylor, another question after looking in Adobe photoshop and nvDXT:

Is 1bit alpha from 1:5:5:5 DDS also ignored? (if this format is supported, I mean).

[taylor]

Is 1bit alpha from 1:5:5:5 DDS also ignored? (if this format is supported, I mean).

That format is supported, and the alpha bit is used.  Technically that format is the same as PCX when used by the game.  Once an 8-bit PCX is loaded it's converted to 1:5:5:5 format, with all green pixels converted to alpha bits.  Obviously the benefit with 1:5:5:5 DDS over PCX is that you get to use green (it doesn't get converted to alpha since you have the option of alpha initially) and you get the full 64k colors rather than just 256.

The DDS code supports the following formats btw:
1:5:5:5 -- 16-bit, 1-bit alpha, BGR format
8:8:8 -- 24-bit, no alpha, BGR format
8:8:8:8 -- 32-bit, 8-bit alpha, BGR format
DXT1c/a -- 24-bit, alpha ignored, DXT1 compressed format
DXT3 -- 32-bit, 4-bit alpha, DXT3 compressed format
DXT5 -- 32-bit, 8-bit alpha, DXT5 compressed format

I am looking to add support in 3.7 for the following additional formats (loading them is easy, using them is where the work comes in):
4:4:4:4 -- 16-bit, 4-bit alpha
3Dc -- 3Dc compressed normal maps
DXT5nm -- DXT5 compressed normal maps (not as good as 3Dc though)
fp16/32 -- 16 and 32 bit floating point formats


The 8-bit paletted formats will load, but can't be used properly by the game.  I started code for that, but never completed it since I considered it a personal waste of time.

Also, note that I used "BGR" rather than "RGB" there.  The game uses BGR pixel order since it's a native format for graphics cards and therefore is a bit faster.  If you create an image that has it's color obviously wrong when seen in-game, then make sure that aren't using a R->B switch, or if you aren't using it, turn it on for that image.