Transparency/DXT3/drawing order issue

[JonPatch]

I'm busy converting objects to FSX, and have found drawing order issues with DXT3 textures (surprise!).

With these settings I get one result (drawing order messed up (cannot see inside framework), but transparency OK)

Source Blend: SrcAlpha
Destination Blend: InvSrcAlpha
Emmisive mode: BLend
Z-Test Alpha: unchecked
Set Alpha at render: unchecked
Z-Write Alpha

With these settings I get another (drawing order correct but DXT3 shows as 100% transparent):

Source Blend: SrcAlpha
Destination Blend: InvSrcAlpha
Emmisive mode: BLend
Z-Test Alpha: checked
Alpha Test Level : 128
Alpha Test Mode: Greater
Set Alpha at render: unchecked
Z-Write Alpha: checked

I've mucked around with a few settings (eg Alpha Test Level, Alpha Test Mode) and I've also tried to set the alpha value at render time without success.

The model has an exterior roof/glass object, an interior roof/glass object, and a "greenery" object.

Ideas?

Jon

 

[martin_ktpa]

I have been fighting with similar issues for a while and found no solution. The best chances of success are if your object is a single MDL. When there are several MDLs involved with various placement refpoints it gets messier.

This setting: Alpha Test Level seems more or less useless to me. The DXT3 obviously has 8 bit alpha. What Alpha Test Level will do is cap the alpha under or above the slider value, without actually affecting the texture file. This seems useful in theory, but in practice it basically castrates our alpha channel giving the same effect as if we used 1 bit alpha (DXT1) to begin with... Thats of course not what one wants when using 8 bit alpha.

Alpha value at render time: appears to be the exact same thing as lowering the Max opacity value as we did in FS8 and 9.

I hope someone can shed some light into the proper use of semi-transparent parts in FSX, I am still completely lost.

 

[JonPatch]

Hi Martin,

I know of two solutions, which have worked for me:

- in this instance my FS9 model works fine in FSX. I have to give up using the global environment map, which would have been nice. But I can live without out it.
- if the semi-transparent parts are separate objects, FSX figures out the drawing order. Works fine for windows, not so fine for my greenhouse

Jon

 

[arno]

Hi Jon,

I'll have to do a few tests, but I guess this is not a new problem. When using DXT3 textures you had the same trouble in Fs2004 I guess. Only there is was much easier to control the drawing order with a little ASM code tweak .

 

[martin_ktpa]

I think I may have found another thing that was sort of messing things up for me.

I tend to have a lot of stuff within my Max scene, basically whole airports not just every single object = separate Max file. Now within my scene, some materials were standard, others FSX. When exporting from a scene with mixed materials the FSX exporter gives a warning where one answers "yes, export FSX materials". Seems all fine and dandy, but apparently its not. Having noticed different results when exporting from other small single object Max scenes, I am quite sure now that when one exports from a mixed material scene, even if just "exporting-selected" objects that have FSX materials assigned and setting exporter to FSX materials, things can get messy.

I went on to delete all non-FSX materials and more importantly objects that had such non-FSX materials assigned to them, and the results are definitely different (better) then before. I will try to reproduce it tomorrow but from what I saw today having a lot of standard materials in a scene, even if no object with such material is selected during export, can mess up the results. Will report back when I am 100% sure.

PS: I am testing with a scene of 5000 objects and 50 FSX materials + 50 Standard materials, not sure if this also applies for less complex scenes.

 

[arno]

Hi Jon,

How many materials are you using on that object? I did some tests with a single material with DXT3 textures and to my surprise I have less drawing order trouble then I expected. I used a double sided cube for the test and all polygons just showed fine.

I'll try to do some more tests with multiple materials to see if I can reproduce what you are seeing.

 

[JonPatch]

Hi Arno,

It's a very simple object with a single material (although I duplicated it as an experiment). I've sent you a copy offline.

Yes, in FS9 we could tweak the .asm, but what worked better for me was to control the drawing order in gmax, would could be defined by the order in which objects were created. We've lost both of those capabilities.

Jon

 

[arno]

Hi Jon,

Thanks for sending me the object to test with. The shape of the roof on this specific objects makes things a bit harder, as their is no optimal drawing order, the best drawing order depends on the position of the user. So unless we can dynamically change the drawing order I don't think there is one perfect solution. This reminds me of designing scenery for Fs98, back then you had to control the drawing order for each object yourself.

I got the best results for your object when I used a material for the inside that has the Z-Write alpha enabled and when I use a material for the outside that does not have this material set. I did not change other default settings during these tests (apart from the one to enable the transparancy of course).

 

[martin_ktpa]

Sorry if this is off-topic, perhaps it will be useful info to others nevertheless.

The problem I reported earlier, with exporting from mixed material scenes, does not seem to be a major issue afterall. The following however is an issue:

Within my FSX materials I pre-assigned night, specular and normal textures linked to dummy blank 32x32 textures. The idea was to create the actual shader-textures later and test/develop only with diffuse. I assumed that having night and shader textures assigned wouldn't be a problem even if these texture files did not exist at runtime and that FSX would simply render the diffuse texture okay and ignore the rest (tex files not found). Like FS9 would render the daytime texture okay regardless if the night texture is present or not. Thought wrong.

What happens when the night and/or shader texs aren't found is the whole model renders with the diffuse tex but pops semi-transparent (ghosted) at certain angles and the overall Z sorting gets completely messed up.

Lesson: Never test any FSX models without all assigned textures actually being present at runtime.

 

[Andrew]

Another step forward

Guys,

I just got a good result with the windows in a control tower. Actually this is the first time I get the windows right. For each of the four windows I used a polygon for the inside (normal pointing in), and one for outside, normal pointing out. Did this by cloning the window and turning the normal. I used one material for the inside, and one for the outside, with different properties. The texture used is a DDS/DXT5 with gradient alpha and a slightly coloured glass. Before exporting the model, I welded the windows 32 vertices down to 8.

Material properties for the inside:

Framebuffer blend set to Default Alpha.

Emissive mode: Blend.

Z-Test Alpha checked. Test level 128.

Alpha test mode: Greater.

Z-Write Alpha...unchecked.

For the outside:

Same as the previous parameters, but with Z-Write Alha checked.

This is the opposite of what you did, Arno. But seems to work fine as well. Or did you get a better result with Z-Write checked for the inside?

EDIT:

Did a new test with a bridge. Z-Write for inside and no Z-Write for outside gave same material colour (finally!) but see-through from the outside. So I swapped parameters on the materials: Z-Write (checked) for outside and No Z-Write (checked) for the inside (as with my tower). Ahh finally...everything is now perfect, also from looking inside out. And: Darn, darn...now I gotta re-array all those main spans!

Cheers,

 

[JonPatch]

Thanks for the tip, Andrew, will give it a shot on the new tower I'm building.

Jon

 

[joeysipos]

This does not make sence

I wanted to test the drawing order and try and make sence of it. What I found makes no sence at all. Now please try to hang in with me while i describe this situation. For my test I created 7, 1 sided square objects with dxt3 alpha textures all placed going around in a circle. If you look at my attachment - a drawing, you can see how I set up things.

Each square (labled 1-7 on the picture) was see through and had a solid line going down the middle. Now on my drawing I went through each square and drew an arrow to other squares in which were visible behind it. I notice only 2 of the squares blocked out other squares - the others didn't block out anything. 1 of the 2 "blocker boxes" (#4) blocked out olny 1 square while the other (# 7) blocked out all the squares behind it. This really through my for a loop. Does any one have any idea of how the drawing order thing works? It is driving me crazy. And please tell me if my words are confusing you. I really want to find out whats causing this.

 

[Tamiya]

it is now working with andrew's tip

thanks andrew
i had same problme about alpha texture in fsx
i followed your tip, now it is working good
it is nice tip

 

[Andrew]

Thanks! Your feedback is highly appreciated

Ain`t easy to to extract this stuff from the SDK...found out thx to Jon, Arno and a lot of trial and error.

Cheers,

 

[hcornea]

Could I suggest this be posted in the wiki?

I'm not sure I understand it well enough to do it myself - but it looks like a great solution.

 

[Andrew]

Agreed. I`ll start to write a draft, and post to the Wiki when ready.

Cheers,