What changed in transparency between 1.1b1 and 1.1b2 - RESOLVED

#1 The top one has transparecny off and is just using alpharef, the bottom one has transparency set to sub ... and those don't look like the same images ... sure the lower one has got an alpha channel?

#2 the materials are the same.

the bottom was just showing the results after trying every setting. even with the setting set identical with the alpharef it didnt change.

So I tried Sub, Lerp, mul, add with no change,

it could be my material is set up wrong, So I just need to know what is different from 1.1b1 to 1.1b2 in regards to transparency so I can try to fix my material.

#3 Same here. Noticed that applying Lerp does not produce the same transparency effect as in Beta 1.

#4 Logged as TQA-781 for the QA team to verify.

We may need a copy of your material to check.

#5 just let me know when you want it and where :)

#6 @Donald
Could you email me the model and material to the address in my profile? That would be the best way to for me to check this one.

#7 Bug confirmed.

#8 @Donald- Took a couple of looks at it.

We changed the .tga to a .png and got it to work as intended. I suggest swapping over while we take some time to look at the issue that changed the way .tga files are processed.

TL;DR- Use .png's for now if at all possible.

#9

Quote:What changed in transparency between 1.1b1 and 1.1b2

The TGA loader was completely rewritten to support more of the functionality available in the TGA format (RLE encoding, colormapping etc).


@Donald: I'm interested in which app you used to create the TGA texture? According to the image header, the texture has 32bits per pixel, but no alpha bits. To a TGA loader, this could mean one of two things:

1. The alpha channel is invalid, and the texture should really be 24bits per pixel. This is what the Torque 3D loader assumes, and so will ignore the alpha channel (making the texture fully opaque).

OR

2. The alpha-bits specification in the image header is incorrect (should be 8 alpha bits per pixel). The loader should override the alpha-bits specification and process the alpha channel as normal.

After giving it some thought, (2) seems much more likely than (1), so I have changed the T3D loader accordingly. Make the following change to gfx/bitmap/loaders/bitmapTGA.cpp (around line 377):

U8 trueBitsPerPixel = header.cmapType ? header.cmapEntrySize : header.pixelDepth;

   // === CHANGE START ===
   // Override the number of alpha bits if necessary
   // Some apps generate transparent TGAs with alphabits set to 0 in the image descriptor
   if ( ( trueBitsPerPixel == 32 ) && ( alphabits == 0 ) )
      alphabits = 8;
   // === CHANGE END ===

   switch( header.imageType )

#10 One more note on this - if I open the texture in Paint.NET, it detects the transparency ok (so must be doing (2) above). If I re-save it the alpha-bits specification in the image header is now correct (8).

So...I still think whatever app created the texture is not quite right, but (2) seems to be the right thing to do in this case.

#11 @Chris,

The textures are from the licensed version of SpeedTree(tm) that I have and some day dream of getting integrated into T3D. But till that day what I do is use the static model and the mesh from the library.

Seems to work well at least it did till B2 :) will try to get your fix in the build and test it


I have been thinking on how I could color the verticies so I could get some animation from the trees using the forest editor but have bigger fish to fry at the moment

#12 @Chris

In my experience TGA is a horrible format... many tools write out the header incorrectly or in incompatible ways.

My advice would be to make the new loader use the same method as the old loader to detect alpha.

#13 Fixed in 1.1 Beta 3.

Transparencies will now work on TGA's even if the header contains incorrect values. You will still have to set the transparency via the material editor though.