Transparencies Problems

[Guest]

Hello there,I really need help as I am sucked with transparencies issues.I get some issues with DXT3 transparent textures which makes some objects shown behind to disepear as well as even part of the same object shown through the transparencie to not beeing displayed as you can see on the attached image.For information, all the trees shown here are in the same BGL. I give that precision as far as I noticed that sometime it looks like that priority orders are linked with different BGLS usage.Who can at least give me an indication about where I can find an explantation. At least I would like to understand what the problem is to find a way to solve it.Thanks

[jkanold 0]

Different models need different types of transparencies.When it comes to trees, use DXT1 Opague + Alpha textures and your problems will go away.DXT3s cause the effect you show in your pics, DXT1s don't.DXT3s are also very blurry at lower texture settings in FS.Different effects can be rendered using 555-1s and even high res with 888-8s.But for trees, stick with DXT1sHope this helpshttp://members.rogers.com/jkanold/jimlogo.gifhttp://members.rogers.com/jkanold/flyurl.gif

[Guest luissa]

Hello,Imagine a situation. Say that you are looking north and the horizon are "ones". Say that you have 2 polygons (rectangles) between you and the horizon. The distant poly could be a tree with a color of "twos" and the nearer poly a tree with a color of "threes". The zeros are the transparent parts of the trees textures. What I am saying is something like:11111111111111111111111.... 0022222200033300YOU We need to understand the Z-buffer. I think of the Z-buffer as 2 buffers. One is a display-buffer which is filled up during BGL processing and which is copied into the screen at the end of that processing. Associated with this display-buffer, there is also a distance-buffer or Z-buffer. This associated buffer contains, not the color of the pixel but the distance of the pixel to the viewer.In the following I will consider that the display-buffer is already painted with the "ones" and that the Z-buffer has the (long) distances of the horizon pixels to the viewer (YOU). I will consider 2 cases:1) the poly of "twos" comes first than the poly of "threes" in the BGL code When the engine reachs the poly of "twos" it evaluates the distances between the viewer and the points that make that poly. It compares the distances with the corresponding ones in the Z-buffer. Since the evaluated distances are all shorter than the stored distances (the horizon ones), the display-buffer is updated with this poly and the Z-buffer updated according. You will have at this stage:11222222111111111111111111....note that the 0's are not copied into the display-buffer.Now the BGL code reachs the poly of "threes". The buffer will be updated to:13332222111111111111111111....which is correct! The problem comes when:2) the poly of "threes" comes first than the poly of "twos" in the BGL codeNow, after the processing of the poly of "threes", the buffer-display will have:1333111111111111111111 .... Note that this is not copied to the display as this is not complete yet. When BGL processes the poly of "twos", if finds that the first 6 positions in the Z-buffer already contain nearer points (from poly of "threes"). So only the last 4 positions of 0022222200 are updated to the buffer which will become:1333112211111111111111 .... WHICH IS WRONG!The solution is:1) to place poly "twos" and poly "threes" in different perspectivecalled objects so that FS (FS2000 at least) sorts their drawing order2) if several transparent polys are in the same object, make sure that distant ones appear first in the code. As the viewer position is not known at designing time, the only solution is to use VectorJumps or SeparationPlanes.Kind Regards,Luis

[Guest]

Thanks a thousand Luis for that very detailed explanation. I think I understood most of it. Thanks again for your time answering my question.May I ask you what is the best way for me to understand how to achieve solution N

[Guest]

Thanks Jim for your answer. I am using so far DXT1 and you are right it works. But my aim was to be able to have a less sharpen edge for the trees to blend them more with their environment. I tried also to apply a Gmax transparency on the DXT1 texture (I know it is strange) and when I do that the issue is the same as the one with DXT3.Anyway, I also have the usage of DXT3 for transparent windows and so on and the problem is the same.How do you do ? How do you use DXT3 ?

[Guest luissa]

Hi Florent,Speaking in terms of SCASM you can have:Area()PerspectiveCall( :tree2 )PerspectiveCall( :tree3 )Jump( :enda ):tree2PerspectiveRefpoint()...Return:tree3PerspectiveRefpoint()...Return:endaEndAand the drawing order of the 2 objects is sorted out by FS so that the distant tree is drawn in first place.However if you have:Area()PerspectiveCall( :trees )Jump( :enda ):treesPerspectiveRefpoint()...; code here both for tree2 and 3Return:endaEndAIn this case you have a single 3D object made of 2 trees. The order here becomes important.Regarding solution 2 I think you should not consider it. VectorJumps were the way to make 3d models for FS98 and before. With FS2000, Z-buffering greatly simplified this task, except on some circunstancies as the ones worrying you (eg transparencies).I did not investigated how transparencies are affected by different image formats. Since you and Jim say that the problem goes away with DTX3, may be there is a different explanation and I can be totally wrong. I can only be sorry if that is the case.Regards, Luis