I thought it was worth providing my current view on the status of DX10.
As I see it the DX10 engine was shipped early with 9 significant bugs/missing features (you could also argue that the VC shadow quality was an additional unfinished feature)
The way transparent objects such as bridges disappeared at night. This was a simple shader bug which I have fixed in the free patches and DX10SceneryFixer.
Progressive taxi markers. This was a simple shader bug combined with bug 5. Fixed in free patches and DX10SceneryFixer
Tool Tips – This is I believe unfixable – the only workaround is to not use full screen.
Effects. The bug here is that the first few effects in a scene seem to be initialised with the wrong properties (such as invisibility) and properties leak between neighbouring effects. Typically this affects navigation lights.
I provided some help here in the free patches. DX10 SceneryFixer provides a much more comprehensive work around. Its not quite a 100% solution and in some legacy sceneries a ballast light is needed on the aircraft as well.
No support for non FSDK SDK scenery or aircraft at night
This is the scenery that appears ok in the day but appears untextured at night (and in the case of aircraft during the day)
This is what DX10SceneryFixer mainly addresses – again its not quite a 100% solution but it’s a big step forward.
The Rain Shader
This was poor, there have been some previous good attempts to address this. I think DX10SceneryFixer has a very good solution – I have managed to implement the lighting and so as far as I can tell the rain and snow looks the same as DX9.
Water ToneThe way that water looks a milky white at night is just wrong! This was addressed in the free patches and also in DX10 SceneryFixer
The Light blue texture used for textures that were missing or not loaded
I think this was a texture used to highlight and debug texture loading issues that got shipped. In normal use you want to make such issues be inconspicuous. It wasn’t much effort to create a black texture so this was addressed in the free patches and also of course in DX10 SceneryFixer
The Master Bug.
This is responsible for everything else.
All the AVSIM patches such as flashing runways, fences, Orbx cars address symptoms of this bug. DX10SceneryFixer adds in a new workaround for FTX lighting.
UPDATE!! The Master Bug was subsequently fixed in Release 2.0 of DX10 Scenery Fixer
Now what I wanted to do today was to explain what the Master Bug is and how to avoid it!
The first thing to say is that if that if you create a simple model with any combination of transparent textures it will display perfectly in DX10! There is simply no such thing as a non DX10 compatible texture or a model that doesn’t work in DX10. Yet the Master Bug is still very real!
So what is it?
To explain that we have to talk just a little about how FSX (this applies to DX9 too) draws things. To maximise the efficiency of the GPU the core engine collects together all simple objects drawn with a single texture. This is referred to as Draw Call Batching. What this means is that if you have a simple grass leaf texture and you populate your airport with 8000 instances, then all this grass gets combined into a single write operation passed to the GPU. Now this works fine in DX10, but we are getting close to the problem. There are reasons that mean that not every instance of our texture can be combined into one write operation.
The Master Bug in DX10 then is that in these circumstances the transparency settings are only set correctly for the first write operation and not for subsequent writes.
So what are the circumstances where this occurs?
The most common is that scenery drawing is implemented as a set of square tiles on the screen and writes are not combined across these tiles. The furthest away tile is drawn first.
- More than 64,000 vertices of the texture are used (this is rare but I have seen it once with grass)
- In Legacy the use of Separation Planes (i.e. for PAPI lights) that share a texture sheet.
I am sitting at an airport and in the far distance is another airport which uses the same fence texture. The draw call batching sorts the fence texture draws but the two fences are in different tiles and so cannot be combined. The fence in the furthest away tile is drawn first – so the fence you cannot see has the correct transparency (!) whereas the one in front of you does not.
If you change your viewpoint there may then be no airport in that direction and so the fence appears ok. Even worse, if you fly between the airports at the half way point it will switch and start drawing the airport you left correctly. It really is like the light in the fridge going off!
You can repeat this substituting runways (although it’s strictly actually another property there not transparency), Orbx Car, FTX light etc etc
Sometimes by sheer bad luck there may be a tile boundary running across your airport. In this case items such as lights, shadows, grass will be drawn ok the far side of the airport but will go wrong near your plane…
So how can this bug be avoided?
I believe that it only affects simple objects that have just one texture sheet with transparency. From observation it doesn’t seem to affect more complex objects. I presume that these are deemed too complex for this form of cross instance batching. I am unsure of the precise rule that applies here (since I haven’t had time to run a set of tests).
When talking about a texture I mean a named texture file. If you copy the texture sheet that becomes a separate texture in draw call batching terms.
The first thing to do is to find out where the tile boundaries are – it seems to be based on the LOD10/QMID 14 boundary. If one runs through your airport don’t use the same grass texture file for transparency on both sides.
You can duplicate the texture and the grass model and then use one model on each side.
You can add a second texture sheet into the model (note I am not 100% sure of the rules here).
- For alpha blending DX10SceneryFixer offers a simple workaround without duplicating textures– if you change the transparent material to have a Final Alpha Blend set True and a Blend Factor of 1.0 then DX10SceneryFxier will force on alpha blending in the shader.
The second approach is simple but be aware that your model is no longer rendered in a single write but large number of alternating writes of the two textures. Thus this makes sense for an object that appears a small number of times but not for grass or lights. (i.e. if the model appears say 10 times its ok, more than that it may be performance affecting)
For PAPI lights I think (but haven’t proved) that the workaround would be not to use a single large texture sheet that holds all the variants but one small sheet for each division.
There is a serious bug remaining in the DX10 drawing engine.
But it isn’t random or unpredictable and when you do understand it, it is usually fairly simple and inexpensive in performance terms to work around.
The one exception to that statement would be autogen lights – the only solution there was for me to force the desired behaviour in the shader. People who have criticised Orbx should take note! Without an understanding of what was going on it was impossible for them to fix it, and even then the only solution was to handle it as a special case in the shader itself.