Orbx and DX10

[Argharg]

Hi, 

 

I know that the official answer from Orbx is that DX10 preview is not supported and we should stick to DX9, the thruth is that more and more simmers are switching since the release by steve of the different patches ( http://stevesfsxanalysis.wordpress.com/

 )

reasons to switch:

1) better fps

2) better graphics

3) far less oom (for stuff is pushed to the GPU, so less memory under 4GO is used), but far the main reason peeps are switching.

4) recent GPU are far more optimised for DX10 than DX9

 

With the recent announcement by steve of a payware that would include functionalities like addon converter x, my guess is that the overall sim population will have switched in a year from now.

 

Now my question:

 

I realise that porting Australia to a DX10 compliant mode is not economical, so fine we will stick to fs9 there

But recent scenes are still not compatible, and I really dont see any justification for that, I was flabbergasted to see that the grass in EGFF Cardiff is not compliant. (I guess is an alpha channel which isnt properly compiled under SP2 and the grass was just ported from an old SP1 or fs9 development).

 

Please insure that futur release are DX10 compliant as your customers are heading that way.

 

Keep on the good work.

 

Etienne

 

 

 

[bonchie]

As you said, Steve's new program will fix most (if not all) DX10 texture issues.

 

But yeah, Orbx will probably need to think about supporting DX10 down the road as more switch.

[pmb]

As a side node, I would not exclude a few customers to directly switch to DX11 using Prepar3d 2.0 expected around the end of this year either, which sure will be supported by ORBX.

 

Regards, Michael

[Ian Routley]

Etienne,

Can you explain how one does not compile an alpha channel properly?

Can you further explain to me why this results in 'DX10 incompatibility' ?

It is terrific that much of DX10 has been fixed, but baffling as to why the things that remain unfixed are necessarily faults in the scenery.

Is it possible that 95% of DX10 is fixed and you are reporting part of the other 5% ?

Of course, if there is another way of compiling an alpha channel, that may well be the solution.

[Argharg]

I Ian, thanks for coming back to me so soon.

 

I am not 100% sure of the technical details, but I happen to have done some freeware scenes and yes, it is possible to do semi transparent textures that works perfectly well under DX10, (aka grass).  As an example, one of steve's patch corrects the transparent texture issue of some the orbxlib car's lights under DX10.

 

In the case of EGFF Cardiff the grass appears to be not DX10 compliant, the transparency is failling - at least on my PC -  but works perfect under DX9. so someone could probably recompile this object. Nb I am not blaming anyone here - neither the developper or the beta tester - as orbx awlays been clear that so far it isn't supporting DX10.

 

I tend to create object under sketchup, a bmp texture with 32 bits created under paint.net size and an alpha channel works fine under sketchup. then I tend to click the "set default transparent" under model converter X (the transparent looks white under model convertor), and pass on a transparent initital texture that works under sketchup (not the one recompiled by model convertor), the results works under DX10 and DX9 if compiled with the SP2 SDK. But I guess everyone as a different receipe.

 

this is what it looks like under dx10:

 

 

Regards,

 

Etienne

[Ian Routley]

DX10 has always had issues with z-testing, and particularly overlapping transparency.

This was particularly evident with FSX own or custom fx files. (Try looking at some light fx through a glass window, for example)

The example you have posted appears to show 1-bit transparency, and since I assume you are using Arno Gerretsen's ModelConverterX to convert sketchup files into FSX models this will use a mid range (approx 128) Z-test value.

I cannot see any 'semitransparent' areas in your picture, albeit I am looking at it on an iphone.

I would absolutely hope DX10 could render that properly or 50% of scenery objects would be ruined!

I have not tried Steve Parson's latest round of tweaks to see whether DX10 now works properly with Z-test and framebuffer values other than the very 'vanilla' ones described.

The recipe for realistic semi-transparent grass is applied using FSX-SP2 tools. All textures are dds DXT1 or DXT5 compiled using FSX own imagetool.

It is touchy to get right under DX9, frankly, so if the rules are set differently under DX10 it makes it less likely that you can make both happy.

So, my point to you is this:

There is no DX10 compliant set of steps or tools. Everything is FSX SP2 compliant and made natively with those tools.

There is in-fact no such thing as DX10 compliant scenery. It is simply a term invented by DX10 users frustrated with things not working when using DX10 preview.

To explain this last point, before Steve fixed the current shopping-list of problems that he has addressed, DX10 devotees were decrying incompetent scenery developers for the things that didn't work. That seems ludicrous now, or perhaps only 95% ludicrous.

Some ORBX features (eg Objectflow) are specially coded, and it is quite an ask to recode these to a changing DX10 landscape if that is necessary. Hopefully it isn't.

Is DX10 better than it was? The consensus there is yes. Is DX10 now 100% FSX SP2 compliant, and 'fixed'. I doubt it.

A small correction to your initial post:

FS9 is COMPLETELY different to DirectX9

I do hope you are not confusing the two:

The only elements made using FS9 tools are some freewareAI models, and objects that cannot be made any other way (eg windsocks for static scenery placement)

Orbx FTXAu is not made using any FS9 tools or processes. All FSX SP2, and one of the first sceneries to specify SP2 compliance.

[John Venema]

To address the specific issue of Bill's grasses used at EGFF, they have indeed been produced totally in compliance with the SP2 SDK and the correct implementation of alpha channels. The issue is mainly that the DX10 code seems to not handle large amounts of alpha channel processing on the Z plane. It also is odd that there seems to be zero issues when the objects are controlled by third party apps like Instant Scenery 2 or Orbx's ObjectFlow. Indeed, whilst IS2 is running in the sim and you're placing that grass there are no issues. But reloading a flight with IS2 unloaded causes issues across large fields of the grass.

 

Bill and I liaised for some time on the issue and he found a partial solution. Here's a quote from Bill via email to me:

 

"Hi John,

 

I've been doing some experimenting, and the results are confusing, at best. The problem, at least on my rig with DX10 enabled, is not with a particular grass model. Instead, it seems to be the amount of grass being displayed that affects the transparency. I tried turning down the grass filler to level 1, and on reloading, about half the large patches showed up normally, with the others not having alpha transparency. Mind you, all the models were the same GUID, but only some displayed incorrectly. 

 

I did notice, however, that when editing the placement in Instant Scenery 2, the transparency problem went away entirely. This led me to wonder if using ObjectFlow for the grass models would fix the issue. I knocked together a template and converted my BGLs to OF XML files, and that seemed to fix everything. The good news is that S45 is now fully DX10 compliant. The bad news is that it's not a global fix for all instances of those large filler grass models. 

 

My only advice to other team members is to use OF for all grass, whether seasonal or not. Perhaps we can find a better solution, but that's all I've got the moment."

 

So Bill solved the issue of DX10 compatibility by using ObjectFlow to control grasses at S45, which is fine because he's not using a lot of his grass there. But at EGFF to control the grass via OF would incur perhaps a 25-40% performance hit because of the large amount of grass models used, which I'm not willing to impose on customers as a solution. Instead a possible solution is to use a completely different grass model and less of it, something I feel reluctant to do because Bill's grass is best suited for EGFF. There may be a third option to add a "DX10 grass option" in the control panel which only places the grass sparingly and controlled by OF.

 

The OP's statement "Please insure that futur release are DX10 compliant as your customers are heading that way." is making the assumption that Orbx developers are not adept at producing alpha channeled textures with the SP2 SDK but that is simply not true.

 

I would also put it to you that the vast majority of FSX users are using and staying with DX9 with no intention to use DX10 purely because of the badly implemented DX10 code that was bundled with the sim. We respect and commend Steve's efforts to work around the issues and if his toolset gains critical mass then market forces will bring this to the fore. In the meantime we do provide control panels to allow any alpha issues to be disabled.

 

We will continue to try new tech for things like grasses, which you'll see in Russ White's Damyns Hall airfield for the UK, where the grass has been algorithmically generated with 3DS and scattered randomly and then built as a single model. This offers a huge field of grass with superb performance and no alpha issues in DX10. Russ may then retrospectively apply this tech to Elstree and Stapleford when OF does affect FPS a bit.

[Lucevan]

I know nothing about z channels etc, but...

 

As far as I'm aware (as a DX10 user) the grass at Cardiff is about the only thing that has in this problem in the Orbx world, which is no big deal.

 

Vlad Maly fixed the grass on CEJ4 when he updated it recently so that it is now DX10 compatible.

 

It can be done, and it is appreciated.

 

Thanks

 

Peter

[Argharg]

Thanks for all those precisions, keep on the good work, looking forward scotland. Etienne