Are There Any Other GP Issues

[gadgets]

To the best of my recollection, I have addressed (but not necessarily solved) in the last day or so all GP-related issues raised in this forum during my six week absence. If I have missed any, please post.

Don

 

[downscc]

I have a recurring problem with ground polys being buried underneath taxiways. I gave up on the problem you looked at for me at KCRP. I am now working on an ADP file for PANC and I am using ADE to create an elevation stub as well as a flatten airport background. The ground polys south of the ARP all work as expected; however, going North of the ARP (about 3000 ft) the ground polys and lines no longer lie on top of the taxi layer (taxi layer drawn first). I have tried changing ground poly layers, many different vertical offsets and changing elevation stubs to no avail. I am stuck, I don't know what to do next other than throw my hands up. Any ideas?

Using P3Dv4.1 with 4.1 SDK and ADE1.75.6372 and GP Editor 2.2.05. I have test splotches of red triangles along the length of runway 15/33, where the ARP is about 1000 ft North of the 33 end of runway. The test splotch appears on top of the taxiway at the high speed turnoff (M) about 1000 ft North of ARP but the all the other further North towards the 15 end are rendered below the taxi layer.

I have applied ground polys and lines throughout the length of the two 7/25 East/West runways without a problem. There is no other elevation correction file for PANC (I turned off the Orbx bgl when I created my own elevation stub with ADE).

I'm fishing for ideas, many thanks in advance:

 

[gadgets]

Dan, GPs displaying below taxiways in Pv4 are typically the result of the terrain not being flattened. (Elevation stubs do not flatten terrain; they control ARP elevation. Taxiways don't flatten terrain either; only runways and aprons flatten terrain.)

In Pv4, GPs are displayed at terrain elevation + the user specified elevation offset. If the terrain has not been flattened and falls below ARP elevation - user elevation offset, GPs will slip below the taxiways.

I note your AD4 file contains a flatten, but depending on which ORBX files you have disables, the Orbx terrain may stiull be having an effect.

An easy way to determine if this is what's happening is to compile the airport with the GP elevation offset set to a large value, e.g., several meters and use top-down view.

Don

 

[downscc]

Don, I have compiled the airport with GP elevation offset of 5000 mm (5 m) and the result in top down view is the same (other than the visible test splotch on Taxi M floating in the air). The remaining test splotches further North are below taxiways. The Orbx file I disabled is \scenery\world\scenery\ADE_FTX_SAK_PANC_elevation_adjustment.BGL. Turning it on has no impact.

The easy way determined what exactly? Still fishing. Thanks again.

 

[gadgets]

When I responded earlier, I had not tested your file. I have now done so and see that some of the lines are missing - even with a large offset.

I will continue to investigate.

Don

 

[downscc]

Many thanks for your time.

 

[gadgets]

I'm stumped! I've tried everything I can think of, including sequentially deleting most airport elements, to no effect. Every GP northwest of the ARP is overlaid by the taxiways and aprons. I increased the GP Layer to the maximum value. No difference. I even deleted all the GPs and reentered the missing hold short at the north end of the airport. The problem persisted. Interestingly, I was unable to display the "enhanced C/L" GP line at the entrance to Rwy 15 - even with apron and taxiway deleted. This suggested maybe it was at fault. But deleting it had no effect.

Then, I recompiled one of my airports. The GPs displayed properly!

That the portions of the lines and polys not lying under a taxiway or apron at PANC display properly confirms it's not an elevation issue. The ADE-GP compiler doesn't "care" where a GP is located. It handles them all identically.

That leave display priority. I examined the _GP.bgl file. All z-bias values are identical.

So, I'm left with the conclusion that it's something else in the .ad4 file that's responsible. (It's a very large, complex airport.) But, I can't even hazard a guess what it might be. If I think of anything, I'll let you know. Fortunately, you can use "standard" hold-shorts to replace most of the missing items.

Don

 

[downscc]

Granted, PANC is a very large and complex airport. However, I never solved the problem with disappearing GP lines at the much simpler KCRP and we tried the same steps there to no avail. In both cases I can use default surface markings to get the the end product. True. But I've only tried ground polys in two cases and both failed.

The engineer in me keeps thinking about the fact that I can go East or West from ARP any reasonable distance, but only 3000 feet North. I find that very interesting.

 

[gadgets]

The engineer in me asks the same question. I love to be able to answer it. I don't seem to have this limit on my own airports - which make me wonder what it is about yours that inflicts it.

How about sending me the .ad4 file for KCRP. Maybe that will help.

Don

 

[downscc]

Things are messy right now, a Windows update has me troubleshooting. Not even Firefox works. Thank goodness I still have a Win7 machine with all my office stuff on it.

I moved the PANC ARP to the Northern extent of the airport at N61 12.053 W150 00.843 and viola the Northern most test splotch at 15 end of 15/33 was working. This is when I discovered my Windows was trashed because i had no keyboard or mouse control, and i couldn't even bring up Process Explorer.
My KCRP has been modified removing the gp elements that didn't work.

Okay Firefox is back trying P3D now......, nope. P3D does not like the Windows update. With P3D in window mode, if I mouse click on Start button it behaves as if i held down the 'V' key for a minute. Back to troubleshooting.

 

[gadgets]

On a whim, I checked to see where the QMID10 area covering PANC was located. It appears the intersection of four areas is smack-dab in the center of PANC. I wonder if that has anything to do with the problem.

(Jon, this discovery was made with an alpha version of my Terrain Sculptor Pro. Consequently, there's some doubt, but from a quick calculation it appears to be correct. As well, the .bgl seems to contain an extra node, exactly at the intersection, which is not reflected in the .ad4 file. I'll do some more work tomorrow to confirm the real situation. But, if true, ADE's processing of terrain containing QMID10 boundaries might need some tweaking.

Don

 

[scruffyduck]

Thanks Don

 

[Rosario Manzo]

Hello
I don't know if it has been highlighted already. In the previous ADE-GP versions I used to have a warning when some vertices were superimposed. Now I do not have this warning anymore but I discovered myself some GPs with superimposed vertices.

 

[pinkjr]

Don, I use ADE V1.71. When I compile my file with GPs under P3D (v3.3), my GPs bleed badly. If I chose to compile under FSX...problem goes away.
Do I need to update, is there a later ADE version?

Also, when I apply P3D Material Settings, it's like Z bias levels are not respected upon compilation. GPs do generate, but they also bleed with photoreal.

I don't see others attempting to use P3D material settings with ADE, so I may be one of the few out there. In any case, using ADEx under FSX mode still works fine, even on P3D v4.

Thanks,
David

PS I don't use ORBX of any kind!

 

[gadgets]

I don't know if it has been highlighted already. In the previous ADE-GP versions I used to have a warning when some vertices were superimposed. Now I do not have this warning anymore but I discovered myself some GPs with superimposed vertices.

Rosario, "superimposed" to ADE_GP means two or more vertices in the same element at the exact (to 10 decimal places) same position. Visibly superimposed doesn't necessarily count. And, if I recall correctly, they must be sequential. Bottom line, if ADE-GP is not complaining and your GPs are drawn correctly, it's OK.

When I compile my file with GPs under P3D (v3.3), my GPs bleed badly. If I chose to compile under FSX...problem goes away

David, The "bleeding" must be an internal PV3 issue - assuming you have specified the material parameters correctly. ADE-GP simply tells P3D what parameters you have specified; it has no control over how P3D displays the material. Compilation for FSX (now) ignores material. (If you have successfully used materials with FSX using ADE-GP 2.2.06, please send me an example; the major activity last week was to ensure materials were ignores when compiling for FSX since materials were "freezing" FSX at startup.)

Also, when I apply P3D Material Settings, it's like Z bias levels are not respected upon compilation

That was my observation as well. I got lots of flickering. That's why I introduced an elevation offset - which sees to work quite nicely.

Everyone who compiles GPs for Pv3 or Pv4 uses materials - though most , I expect, use the default material. However, there are several threads in this forum on the use of custom material which appear to have terminated successfully. That being said, it's possible that you are attempting to use an unusual parameter and ADE-GP is not handling it correctly. Perhaps you could cite a specific problem with screenshots

Don

 

[gadgets]

You can relax, Jon. The extra node in the TS Pro display is a result of my (now proven faulty) algorithm for recombining adjacent terrain polys which are the result of QMID clipping. (PANC lies in four QMID10 areas, hence it's airport poly is an aggregate of 4 polys in the CVX file). The node is not in the data itself.

Sorry for the false alarm (but now there will be one less bug in TS Pro at introduction.)

Don

 

[Rosario Manzo]

Rosario, "superimposed" to ADE_GP means two or more vertices in the same element at the exact (to 10 decimal places) same position. Visibly superimposed doesn't necessarily count. And, if I recall correctly, they must be sequential. Bottom line, if ADE-GP is not complaining and your GPs are drawn correctly, it's OK.

Roger, thank you.

 

[Andrew]

From before, I had compiled all my airports with the ADE Release candidate for P3Dv4.0. Yesterday, with ADE 1.75.6421, I recompiled ENCN, and lost all my taxi centerlines, which use the yellow20F texture. All the textures I need for my GP's, are in my prefferd .dds format in ADE\Texture, and correctly transferred to my Airports of Norway\Texture folder.

The only remedy till now I have found, is to use the encn_GP.bgl from my previous compilation with the ADE release candidate. Then all lines are back.

 

[gadgets]

with ADE 1.75.6421, I recompiled ENCN, and lost all my taxi centerlines,

Andrew, I'll need your .ad4 file to investigate.

Folks, regarding original problem, i.e., the GPs in the NW quadrant of PANC being displayed beneath the aprons and taxiways, I fear we may have run into an internal PV4 issue. As of last night, I had determined that the intersection of four QMID10 areas lay very near the ARP of PANC. All the GPs in the NE/SE and SW areas are displayed properly. Using the rubber band, I moved most of the components of PANC away from that intersection and magically, all the GPs - includiong those in the NW quadrant - were displayed properly.

Dan, it will be interesting to know whether or not a similar problem lies at the root of your problem at KCRP. I suspect that is the case, since the intersection of 4 such areas lies VERY close to that airport. You can confirm this for yourself, or send me the .ad4 file.

I can find nothing in the SDK, nor is Jon aware of any such limitation or workaround for the issue. Doesn't mean it can't be fixed, but it will require some experimentation.

Don

 

[gadgets]

GOOD NEWS! As I mulled over the problem, it occurred to me I HAD seen it before. The solution at that time, and I have confirmed also for the current situation, is to ensure your ARP is northwest of any QMID10 intersection lying within the airport boundaries. In the case of PANC, I moved the ARP to N61.183, W150.010. All GPs appeared.

I'll write a sticky with this reminder.

Don