ADE Ground Polys and DirectX 10

[DanM]

I've been following the ground poly testing, and although I haven't tried creating any ground polys, myself, I'm wondering if anyone has experienced any issues when running the ground polys under DirectX 10? I use the shaders fixes that were developed by Steve Parsons. In particular, I'm wondering whether the ground poly autogen suppression could produce flickering? I haven't heard any mention of DX10 in the ground poly discussions. Have Steve's fixes made it a non-issue?

 

[gadgets]

Dan, the best way to answer your question is to create some ground polys in the configuration about which you are concerned and test.

But, that may not even be necessary. fsDeveloper has numerous posts on the topic of ground poly flickering and autogen suppression - related to FS8 MakeMdl, of course. ADE_GP produces identical executable code to what would have been generated by FS8 MakeMdl - tweaked. So, if ground polys have not previously been a problem (lots of airports include them - including all of mine), then those generated by ADE_GP are unlikely to be. (If you've been following this forum, then you know that my CYYJ includes nearly 1000 ground polys and no one has reported any flickering.)

ADE_GP simply avoids the "hassle" in creating ground polys.

Perhaps someone else would care to comment on the custom shaders you are using.

Don

 

[DanM]

Thanks, Don. I'll accept your answer that testing "may not even be necessary."

I was reluctant to do any testing, myself, since with my having no experience using ADE_GP, I was afraid that I would unknowingly introduce what appeared to be problems only to find out, later, from you that the problems were of my own making. I just didn't want to waste your time.

 

[gadgets]

Dan, I didn't mean to discourage testing; in fact, quite the opposite.

I was simply pointing out that ADE_GP doesn't introduce anything new "into the equation".

If you have concerns about the custom shaders, my CYYJ (http://stuff4fs.com, don't worry about the patches) with its nearly 1000 GP objects is probably as good a test case as you are likely to find.

Don

 

[DanM]

Don,

Below are screenshots showing some of the custom ground polys at your version of CYYJ. FSX is running with DirectX 10 enabled and with the most recent FSX DirectX 10 shaders fixes installed. Not surprisingly, the screenshots show that proper rendering of custom ground polys under DirectX 10 remains one of the few problems for which no fix has been found.

The problem is similar to the blank textures that are seen when running FS9-compiled aircraft in FSX with DirectX 10 enabled. The only way to see the textures on such aircraft is to run FSX in "FS9 mode" (with DirectX 10 disabled). However, there is one difference, and to me, the difference is important. Whereas FS9-compiled aircraft show blank textures at all times of the day and night, custom ground polys render correctly under DirectX 10 until dusk. Only at dawn, dusk, and night, do the custom ground polys exhibit blank textures. I'm willing to put up with that so that I can enjoy the custom ground polys during daylight hours. What I'm unwilling to do, is to run FSX with DirectX 10 disabled, since I highly value the performance enhancement provided by DirectX 10. Perhaps interestingly, it's my emphasis on appearance over performance that produces my need for the level of performance provided by DirectX 10. Fortunately, non-daylight rendering of custom ground polys is one of the few remaining cases where the use of DirectX 10 adversely affects appearance.

From what you've already stated along with what I've seen at CYYJ, custom ground polys created using ADE_GP should have no problem rendering correctly under DirectX 10 during daylight hours.

Dan

 

[gadgets]

Well, now we know!

As I noted yesterday, ADE_GP generates FS-8 style ground polys - without the user having to learn Gmax.

Neither FSX nor even FS9 have any native support for ground polys. While FS9 renders FS8-style ground polys correctly (save for flickering of shadows and suppression of autogen, both of which we seem to have under control), its development tools do not support their creation. Hence, before ADE_GP, airport developers who wanted ground polys had to maintain a copy of the otherwise obsolete FS8 MakeMdl and "tweak" the .asm file prior to compiling.

I understand FSX was to include native ground poly support, but that feature never "made the cut". We are fortunate then FSX supports tweaked FS8-style ground polys to a similar extent to FS9.

I don't use DX-10 and am (was) unfamiliar with its problems with FS9 aircraft and FS8 ground polys. I suspect nothing can be done about it - since DX-10 wasn't even a dream 15 years ago when FS8 was being developed. However, if you have any suggestions that can be implemented given the development constraints, I'd be happy to try them. (Was the FS9 aircraft problem solved? If so, how? Perhaps the same approach can be used with ground polys.)

Don

 

[tgibson]

Hi Don,

AFAIK the FS9 aircraft texture problem has never been solved. FSX in DX10 only supports FSX style texturing materials on aircraft, not older ones. I don't know about scenery, though.

 

[gadgets]

I have explored the issue with Arno. The underlying problem is that DX-10 relies on FSX materials.

There is no .asm to .bgl compiler for FSX. .asm files must be compiled with bglc_9. But, bglc_9 will only accept FS9 material format.

The other alternative would be to create a FSX .mdl file instead of an .asm file. But, FSX has no native support for ground polys.

So, it looks like ground polys and DX-10 will forever remain incompatible.

Fortunately, as you have shown, the polys display correctly during daytime. I guess you'll just have to use your imagination at night.

Don

 

[arno]

Hi Don,

Just an idea, but does it matter if you define a night texture in the asm file or not? I haven't tested it yet myself, but that might be a good thing to try.

 

[DanM]

Just an idea, but does it matter if you define a night texture in the asm file or not? I haven't tested it yet myself, but that might be a good thing to try.

I think it makes good sense to take a look at night texturing. Perhaps inherent differences between FS9 and FSX materials can't be overcome, but it may not be necessary to do so. After all, it's already been observed that .asm files for custom ground polys compiled with bglc_9 using FS9 materials display properly during daytime hours in FSX under DirectX 10. So DX10 doesn't seem to rely always on FSX materials. Something is enabling those FS9 materials to render correctly during the daytime in FSX under DX10.

 

[gadgets]

does it matter if you define a night texture in the asm file or not

Well, I can confirm that having a night texture defined isn't the solution, because that's the situation in the lines shown in Dan's screenshots.

But, you may have "put your finger" on a solution anyway. In the lower screenshots, the area around the tower (the light brown building in the upper left corner) is a ground poly for which there is no _LM file -and it appears to be shown as expected both day and night.

Another possible factor is that .asm files generated by FS8 makeMdl "tag" all textures as "TEXTURE_AIRCRAFT". For consistency, I do the same in ADE_GP. I wonder if tagging them as "TEXTURE_BUILDING" would make a difference.

(A few minutes later)

I've never used DX-10 Preview mode before. So I just turned it on.

First of all, some ground polys do display properly - those placed directly on the ground. It's the ones placed on top of those that are not displayed. But, this may be a layering issue. I noticed that some of the lines I placed only a day or so on my upcoming CYYJ update display just fine. The only difference I can think of at the moment between those and the ones that aren't displaying is a wider gap in layer number between the bottom layer and that of the upper ground poly.

Looks like I've got some experimentation to do!

Don

 

[gadgets]

UPDATE: It appears that the specification of a _LM texture in the .asm file is causing the display difficulty with DX-10. Once I eliminated that, all the errant polys using that texture appeared as expected at night. Same applies to dawn and dusk.

Simply eliminating the _LM texture itself makes no difference. The file must be recompiled.

Dan, if you'd like to run some further texts, I'd be happy to recompile some of the CYYJ ground poly files and send them to you.

Don

 

[DanM]

Wow, Don, you've made some impressive progress!

Yes, if you would send some recompiled CYYJ ground polys to me to test, that would be great.

Does eliminating the specifying of a _LM texture in the .asm file make the ground polys fail to render properly when not running under DirectX 10? If so, it would seem that compiles with and without the _LM texture being specified need to be available so that proper rendering occurs in FSX whether DX10 is enabled or not. Following logically from that, am I correct in assuming that the end-user would have to install one or the other version of the completed ground polys depending upon whether DirectX 10 was being used or not?

Am I correct that what appears to you to be a layering problem still exists under DirectX 10?

Dan

 

[gadgets]

Am I correct that what appears to you to be a layering problem still exists under DirectX 10?

No. There is no layering problem. That was a "red herring" which pointed me towards the real problem, i.e., specification of a _LM texture in the .asm file.

Am I correct that what appears to you to be a layering problem still exists under DirectX 10?

I have just finished adding a DX-10 checkbox to the ADE_GP compiler dialog. When checked, the _LM specifications are eliminated from the .asm file. If not checked, they are included. The status of that checkbox is saved from one session to the next, so you only have to set it once. Default is unchecked. The checkbox is only enabled when it would have an effect - e.g., if there are no _LM textures, the checkbox is disabled irrespective of its checked status (unless, of course, we find some other correctable deficiency related to DX-10.)

Yes, if you would send some recompiled CYYJ ground polys to me to test, that would be great.

Please send me your e-mail address (don at stuff4fs dot com) and I'll e-mail them to you. As you can see, there are a lot of "gp" files. I'll only be sending you a couple.

Don

 

[DanM]

Don,

In your email to me, you mentioned missing night lighting. If you were talking about apron lighting, then I can tell you that I am not experiencing the problem (see first screenshot below). It's possible that Steve Parsons' shaders fixes (which I use) are making a difference between my system and yours with regard to visibility of lighting under DirectX 10.

The second screenshot shows CYYJ before your gp recompile. As shown earlier, these polys were not textured at night.

The third screenshot shows the recompiled polys. Although they are visible both day and night, the screenshot reveals there is an obvious problem.

Dan

 

[gadgets]

Thanks for the report, Dan.

After sending you the recompiled files, I downloaded Steve's modified shaders and, magically, my ramp lighting re-appeared. Presumably, this was due to the "missing night texture issue" which the new shaders resolve.

Re the third screenshot, I currently have my development version for CYYJ in a state of disarray. Obviously, the recompiled files I sent your are using the wrong or a modified texture. This exercise was solely to allow you to confirm that ground polys created from .asm files without an _LM texture entry are visible at all times and, you seem to have confirmed this.

Depending on how the schedule looks for release of the CYYJ upgrade, I may prepare a patch for the current version of CYYJ. If I do, I will, of course, ensure the correct textures are used.

Thanks for bringing this issue to my attention.

Don

 

[DanM]

Thanks for giving ADE_GP the ability to create custom ground polys that render correctly in DirectX 10 at any hour!

 

[arno]

Hi Don,

Good catch for the night textures, I guess I should update my ground polygon wizard too.

Just thinking loud again, if the night texture is removed from the asm file, you get the same texture as during the day. So if you want special night effects on the ground texture a different approach is needed. Maybe we can try to switch the textures just like we switch the seasons in asm code. I'll have a look at that.

 

[gadgets]

Thanks, Arno. As I sort of explained earlier, my use of night textures in those instances was to brighten the gp lines that took on a washed-out appearance at night under my apron lighting.

Losing that is a small sacrifice under the circumstances. But, if one were to include some form of lighting in a ground poly, the absence certainly would be more noticeable.

The difficulty I see in using a time-based approach to texture selection is the abrupt change that would occur at day-> dusk, etc. Hopefully, you'll find a way to minimize that. Please keep me posted.

Don

 

[gadgets]

The third screenshot shows the recompiled polys. Although they are visible both day and night, the screenshot reveals there is an obvious problem.

Dan, I just realized what is the problem. In a "production environment", you can't simply remove items from the texture list in the .asm file.

Each DRAW_TRI section in the file starts with a MATERIAL statement that includes a texture index number. For test purposes, I didn't re-export the file from Gmax - which would have updated those texture index references. I simply removed the _LM entries from the texture list - thus changing the index of each of the following textures in the list. While this did prove what was the problem with GPs under DX-10, it resulted in the wrong texture being applied.

Anyone who wishes to apply a similar solution to their GPs must remove the _LM textures in Gmax and re-export the files or use some tool to update the texture indices referenced in the DRAW_TRI sections.

Since I've got six airports to update, I'll probably create a small utility to do it for me at the .asm level, since removing the texture in Gmax means I'd have to maintain two versions of the Gmax file. If I do create such a utility, I'll be happy to make it available to others.

Don