• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

FS2004 DXT3 alpha isues

Messages
1,268
Country
us-hawaii
In another fs site, there is a great deal of discussion concerning BMP files with DXT3 compression and "no alpha channel". I guess this started with aircraft and spread to scenery objects. The claim is made that these bmp textures are causing stutters. I suppose that could be true but I'm surprised if it is that it isn't widely known.

Dick "rhumbaflappy" checked out some of these "alphaless" DXT3 files. The first thing, is that what is meant by alphaless, is that when the bmp is opened in imagetool, imagetool reports "Alpha: None" (the actual bmp does contain valid DXT3-format alpha data). What Dick found was that imagetool is setting this "Alpha: " data based on the value of byte x3F in the bmp file. When set to x01 it causes imagetool to report "None".

I did some tests with fs9 imagetool. I created three texture bmps in GIMP. The first was a straight 24 bit RGB. The second I created an all-white (255) alpha channel and saved as 32 bit RGBA. For the third I applied a gradient to the alpha channel from 0-255, again saved as 32 bit RGBA.

I then opened all three in fs9 imagetool. For each I set image format to DXT3 and then did "create mipmaps" and saved the file. All three were reported in imagetool (and confrimed with DXTbmp) as valid DXT3 with mips. However, imagetool reported texture 1 and 2 as "Alpha: None", while the third was reported "Alpha: Alpha". So it appears that fs9 imagetool when converting textures into DXT3 will create a "white" alpha channel if none exists, and if the alpha channel is "white" it will flag the bmp as "no alpha" and byte x3F is 01. I repeated the test except using DXTbmp, and for all three fs9 imagetool reports "Alpha: Alpha" and byte x3F is set to x04.

Now aside from the question of the possible performance hit if a DXT3 BMP has the "Alpha: None" set, I wonder the application issue of having or not having alpha data that's all white in an fs9 material (it was suggested at the other site that DXT1 with no alpha should be used instead of all-white alpha DXT3). The sdk seems to suggest that DXT3 is used for diffuse map, though I don't suppose the case of the alpha being all-white was considered. So I wonder if there is any problem using DXT1 no alpha in this case or if it is beeter to use DXT3 even with all-white alpha (in this case either using DXTbmp instead of fs9 imagetool to convert or hex-edit byte x3F to x04)?

scott s.
.
 
Messages
607
Country
france
Well, I don't design planes and for sceneries my rules are :
- always compress and mipmap
- if alpha is black and/or white, then DXT1
- if alpha is grey leveled, then DXT3
I never have had any trouble.
So I wonder why focusing on that byte ?
 

hcornea

Resource contributor
Messages
2,388
Country
australia
Dxt3 textures are larger than Dxt1. .... Check filesizes to confirm this.

If you don't need an alpha channel ... Then why include it in the texture.

I can't see the advantage if you don't need a multibit alpha. But then I develop mainly for FSX
 

arno

Administrator
Staff member
FSDevConf team
Resource contributor
Messages
32,859
Country
netherlands
Hi,

I agree with the comments above. If you don't need an alpha channel you better use DXT1. The DXT3 format always stores an alpha channel, that's why these files are twice the size. So even if ImageTool says none, there is still alpha data stored.

So only if you need more than a 1-bit alpha channel, you should use DXT3, else DXT1 is normally the best choice.

Not sure how much performance hit it will give, but the textures are twice the size, so also use twice the memory on the graphics card.
 

n4gix

Resource contributor
Messages
11,674
Country
unitedstates
The simplest solution to the issue of an "all white" Alpha not having the flag set properly by Imagetool is to insure that at least one pixel in the Alpha is "not-white." :D
 

rhumbaflappy

Administrator
Staff member
Resource contributor
Messages
5,932
Country
us-wisconsin
I'll second what Bill indicated. A single gray pixel will allow the rest to be pure white or black. (A trick to use with placing autogen on an invisible photoreal.)

Dick
 
Messages
1,268
Country
us-hawaii
Thanks. I understand DXT1 with alpha is sometimes not wanted due to loss of color information in compression. Can it be said that where the sdk (either FS9 or FSX) says a material has an alpha channel, it's OK to omit it if not needed (I suppose N/A for bump map as I can't see how one would work without the alpha)?

scott s.
.
 
Messages
607
Country
france
The simplest solution to the issue of an "all white" Alpha not having the flag set properly by Imagetool is to insure that at least one pixel in the Alpha is "not-white." :D

Hi Bill,
What does it actually change for the design and/or the user ?
 

n4gix

Resource contributor
Messages
11,674
Country
unitedstates
Hi Bill,
What does it actually change for the design and/or the user ?

Properly speaking, nothing at all. The presence of at least one non-white or not-black pixel simply guarantees that Imagetool will correctly set the bits in the compressed image file such that the Alpha information will be preserved and work as expected... :D

It's long been my habit to make the pixels at the upper-left corner and the lower-right corner some level of gray. This also insures that if I use Ctrl-A to select the image, it will grab the entire image such that Ctrl-V will paste it precisely on a new layer.
 
Last edited:
Top