P3D v4 gp poly problem

[jyarddog]

I did one gp in one area. worked great. Did another one with a different texture ( installed correctly in ADE gp texture editor. texture is difined), but it does not show in game unless I go top down and zoom out a ways. Bob

 

[tgibson]

Try the second radio button in the GP compile dialog box, instead of the top one

 

[ahuimanu]

I think I am having the same issue and I didn't get a nibble on my posting about it. If we are on F3Dv5, we are severely restricted on what radio buttons we can use - most are disabled. I would have to use the airport reference point altitude, but ADE_GP seems to want the "local elevation" option only. I can't even see mine, but I think the OP and I are experiencing the same thing and it is related to altitude. If I create a scenery object library and place one of those objects (which is from a MDL file), then I can see it just fine. However, everything I can read here and in the ADE_GP manual gives me the impression that the options we are given for P3Dv5 take the approach of compiling our GPs as models and then placing them into the GP BGL. I have an airport background, which should be serving as a flatten and ADE is even creating an airport elevation adjustment stub file and placing that within the P3Dv5 installation's scenery files. However, I just can't see the GP at all whereas many, including jyarddog, report that if they use the top-down view and slew up, they can see it.

In all cases, this feels like an elevation problem and I find that almost ALL P3Dv5 airports, when they are flattened, are on plateaus even with a default install. Since the documentation says "will create at local elevation," I unfortunately don't think this is a reference to the ARP, which I wish would be used, but the actual local terrain elevation. I am doing all of this with a stock install (no scenery addons except for the one I am testing). If more of the options in the ADE_GP compile dialog were available to us, it would help. Even if I do an FS8 style GP, I can't see it. My next step would be to try to create a poly in blender, with a simple square with a color on it, and compile it directly to see if this improves.

Sorry if this seems like a post hi-jack, but I believe I am talking about the same thing that jyarddog is with the exception that I can't make it work great anywhere.

 

[jyarddog]

You mean local el full vis? That is the second one. I did that already. ......................... This sentence is hours later. I removed the photoreal in my scenery..... no change. Just trying to eliminate possibilities.

 

[ahuimanu]

I am referring to this dialog (from the manual). "Local elevation, Full visibility" is the only option available. Selecting "Generate FS8-Style GPs" seems to have no effect. The explanation from the manual for the "Local elevation" option is this:

"compiles all ground poly objects using the elevation of the ground for reference. This is the default for P3Dv3 and for FSX when materials have been used. For other situations, if the ground poly objects are at other than ARP elevation, use this option."

I am finding that, in nearly all cases, the ground elevation is not the same as the ARP in P3D where a fresh/no-addon installation has airports on plateaus due to flattening.

The next part of the ADE_GP manual that is useful is this part:

"for P3Dv3+ and FSX using materials – a model (.mdl) file is created for each GP object which is saved to a subfolder named ADE_GP in your ADE folder and a .xml file to position each of the models is saved to a file named ADE_GP.xml in your ADE folder prior to being submitted to the compiler in the SDK. The resulting compiled .bgl files named as the source .ad4 file suffixed with “_GP” and associated textures are saved as noted above."

With the latest SDK, there is something about this process that is probably causing these GPs to "stick" to the earth below the airport. I think the GPs are there, but are buried; your observations about having to slew high above to see your GPs gives some support to this hunch. Other threads here give me the impression that the GUIDs for some terrain features have changed in the latest SDK (Prepar3D v5 SDK 5.3.17.28160) and I am not certain that ADE is incorporating these changes. ADE for anything FSX/P3D related seems frozen in time since Summer of 2020, which is about when the world shifted attention to MSFS. Whereas the GP features have been updated several times, ADE has not. I am afraid what we may be experiencing is the slow decay when tools are kept in synch with each other. For instance, Arno's tools seem to be maintained, whereas the ADE tools are less so. Of course, these are all freeware gifts, so I am making observations and not complaints. The only option I had available to me to support ADE was to have purchased the ProKey, which I did. It seems that once the ProKey was discontinued, my suspicion told me that supporting the tooling for FSX/P3D was likely being deprioritized. Such is the way of things.

For these reasons, I am starting to pay closer attention to the SDK tooling and I am realizing that I might find better long-term sustainability for P3D if I just shift to a GIS-oriented solution as I am convinced that this is how the base scenery is made (hence tools like Shp2Vec). I am starting to think that a tool like qgis, particularly because it is very easy to extend with Python, might be a good solution. I can't easily replicate the features of ADE_GP as it does seem to build MDLs around flat surfaces, but I can create most of the inputs to the scenery tools with something like qgis.

With that said, I am happy to try out any combination of steps that might lead to a solution. I am literally on a default install with no scenery other than the one I am testing. Jyarddog, I have another post where I included my test scenery, and maybe you could post your .ad4 file here? If somebody can make your example (or my own, work), then we might have an opportunity to trouble-shoot.

 

[jyarddog]

wilco. file attached.

 

[jyarddog]

Just now I went to ADE and opened the ade-gp folder. There I found mdl's with long numbers as their names. I opened one of those in MCX then exproted as an mdl - I put that in my mdl folder, opened ADE, went to lists, models, and added this mdl with its long number/name. and placed it. I did have to raise the elevation from 0 to 6' (my airport el) and it worked. It stays, does not go away. Ergo- I had to turn this gp ploy into an mdl. What a pain but at least a work-around for now.

 

[ahuimanu]

what is interesting is that that is, more or less, the same error I am seeing everywhere I test (6 feet). The manual process is what the tool should be doing, but something about its feed-forward process to ADE has causing issues. Thanks for your update, I'm going to try it on my end too.

 

[ahuimanu]

Just tried an earlier scenery of mine, last compiled in Nov 2021, and the GPs work there. I think it is something about this newer SDK.

 

[ahuimanu]

I wonder if ADE_GP is not doing something right then?

 

[Tim Collins]

There are problems with the P3Dv5.3 SDK. If you can, replace it with the SDK for P3Dv5.2.

 

[ahuimanu]

Thanks Tim, would that be the whole run of the 5.3 SDK or the most recent?

 

[Tim Collins]

As far as I can tell, it’s all of the 5.3 versions. LM are aware of the issues, but haven’t yet dealt with it - probably because the pro scenery people have found workarounds. Certainly the 5.2 SDK gives better results for most situations, but doesn’t allow sloped aprons which I believe was the main intended upgrade for 5.3.

 

[ahuimanu]

Ah, okay and thank you. I do have a 5.2 SDK and I'll install that as well.