• Which the release of FS2020 we see an explosition of activity on the forun and of course we are very happy to see this. But having all questions about FS2020 in one forum becomes a bit messy. So therefore we would like to ask you all to use the following guidelines when posting your questions:

    • Tag FS2020 specific questions with the MSFS2020 tag.
    • Questions about making 3D assets can be posted in the 3D asset design forum. Either post them in the subforum of the modelling tool you use or in the general forum if they are general.
    • Questions about aircraft design can be posted in the Aircraft design forum
    • Questions about airport design can be posted in the FS2020 airport design forum. Once airport development tools have been updated for FS2020 you can post tool speciifc questions in the subforums of those tools as well of course.
    • Questions about terrain design can be posted in the FS2020 terrain design forum.
    • Questions about SimConnect can be posted in the SimConnect forum.

    Any other question that is not specific to an aspect of development or tool can be posted in the General chat forum.

    By following these guidelines we make sure that the forums remain easy to read for everybody and also that the right people can find your post to answer it.

MSFS20 Draw Order of GPs

Messages
1,201
Country
us-texas
Hi,

I am using MCX to convert ground polys generated using ADE. The workflow works quite well, however as the models tend to get larger....FS seems to ignore Z bias.

Here is how it looks in MCX (correctly!):
mcx.png


Notice hold short above taxi lines.

On the sim, it has random behavior:
sim.png


There is a work around, which is to model each layer separately, and then use the SDK proj mesh layer adjustment for each object.....but is a lot of work.

Is there something I'm missing so this works directly off of MCX?

Thanks!
 
did a little bit more try outs, it does seem like using projected mesh ignores the draw orders and just splashes everything together. Have to split the layers or just place as a planar object (non-proj mesh)
 
I never tried to make ground polygons for MSFS myself, so I think other developers will have to help you on this one. But if there are tips to improve the MCX output I'll follow this thread.
 
[EDITED]

MSFS 2020 displays FSX XtoMDL-compiled BGL file format G-Polys made via MCX' G-Poly Wizard if one has a proper Manifest.json and Layout.json in the root of the add-on folder chain under the top folder alongside the \Scenery, \Texture and \ContentInfo sub-folders.

I followed Dick's workflow described here to configure my FSX scenery for MSFS display:

https://www.fsdeveloper.com/forum/threads/using-fsx-object-libraries-in-msfs.455643/


There is major flickering of those G-Polys if I set:

MSFS { Esc Key } Menu > Options > General Options > Graphics > Anti-Aliasing to [ TSAA ] mode


To eliminate flickering of those G-Polys I can, on my AMD RX 5700 XT 8 GB VRAM Video Card:

Disable [ TSAA ]

...and set instead:

MSFS { Esc Key } Menu > Options > General Options > Graphics > Anti-Aliasing to:

[ AMD FSR2 ] > QUALITY Mode > AMD FIDELITYFX SHARPENING [ 200 ] slider position


As MSFS Menu GUI explains, Nvidia GPUs utilize comparable- but differently named- settings for the above. :pushpin:


https://www.google.com/search?q=MSF...7CLCBwkwLjE3LjIxLjTIB54B&sclient=gws-wiz-serp


I have not yet tested a MSFS format, non-projected mesh glTF G-Poly, but I expect it will work.

Just as MCX' existing G-Poly Wizard uses SCASM / ASM for legacy "FS8"-type, and XtoMDL for FS2Kx"-type G-Polys, I would also welcome seeing generic Khronos 2.0-type and MSFS_XML_Extension-type glTF options in an updated MCX' G-Poly Wizard. ;)

As I increase my use of 3D G-Poly TIN surfaces that may not be compatible with the 'current' MCX G-Poly Wizard "flat" output format, I would be interested in seeing an updated MCX-GPW feature set to allow Layer Number selection for "flat" MSFS glTF G-Polys, and perhaps 3D TIN surfaces.


IIRC, a potential limitation of features IIUC, compared to an Apron Polygon is inability to display transient environmental effects during / after rain.

But I may be mistaken based on lack of testing; it might be that true MSFS glTF G-Polys created as SimObjects may be able to display transient rain effects ...and a number of other complex effects that Aprons and Projected mesh can not.


These MSFS threads discuss "Draw Order" and G-Polys, Z-Bias, Z-Sort, Alpha, projected mesh, layered Polygons / Aprons: :teacher:

https://www.fsdeveloper.com/forum/threads/projected-mesh-not-using-pbr-material.448818/

https://www.fsdeveloper.com/forum/threads/z-bias-and-draw-order.449535/

https://www.fsdeveloper.com/forum/threads/alpha-material-problems-with-z-sorting.457338/


...and also this linked Google search:

https://www.google.com/search?q=site:+www.fsdeveloper.com+MSFS+Z-Bias+draw+order&sca_esv=77667d73f37b3433&ei=Ztb0aJP6B56e0PEP6JqFoAE&ved=0ahUKEwiTxd_jnrCQAxUeDzQIHWhNARQQ4dUDCBE&uact=5&oq=site:+www.fsdeveloper.com+MSFS+Z-Bias+draw+order&gs_lp=Egxnd3Mtd2l6LXNlcnAiMHNpdGU6IHd3dy5mc2RldmVsb3Blci5jb20gTVNGUyBaLUJpYXMgZHJhdyBvcmRlcjIFECEYoAEyBRAhGKABMgUQIRigAUj5-gFQ0iZY2-8BcAF4AZABAJgB4QGgAcEZqgEHMTIuMTcuMbgBA8gBAPgBAfgBApgCH6ACliDCAgoQABiwAxjWBBhHwgILEAAYgAQYkQIYigXCAgoQABiABBhDGIoFwgIOEAAYgAQYsQMYgwEYigXCAhEQLhiABBixAxjRAxiDARjHAcICDhAuGIAEGLEDGIMBGIoFwgIREC4YgAQYsQMYgwEY1AIYigXCAg4QLhiABBixAxjRAxjHAcICDhAuGIAEGMcBGI4FGK8BwgILEAAYgAQYsQMYgwHCAggQABiABBixA8ICCBAuGIAEGLEDwgIFEAAYgATCAgsQLhiABBjRAxjHAcICBBAAGAPCAgsQLhiABBjHARivAcICBRAhGKsCmAMAiAYBkAYIkgcGMS4yOC4yoAeprgGyBwYwLjI4LjK4B_cfwgcKMi0zLjE4LjkuMcgHjAQ&sclient=gws-wiz-serp

[END_EDIT]

On a practical basis though, finding true zoom level-21 aerial imagery that exceeds the merged Projected Mesh resolution at that same zoom level-21 is not easy; most is 'synthetic' up-sampled imagery that is actually 3 or 4 zoom levels lower in its original true resolution.

Quite a bit to be tested when the cold weather arrives by years end. :idea:

GaryGB
 
Last edited:
MSFS 2020 displays FSX file format G-Polys made via MCX' G-Poly Wizard if one has a proper Manifest.json and Layout.json in the root of the add-on folder chain under the top folder alongside the \Scenery and \Texture sub-folders.

I followed Dick's workflow described here to configure my FSX scenery for MSFS display:

https://www.fsdeveloper.com/forum/threads/using-fsx-object-libraries-in-msfs.455643/

There may be flickering of those G-Polys if one does not set MSFS > Options > Settings > Graphics to disable (forgot the term ?) < ...to be edited when I return to my FS computers >.

I have not yet tested a MSFS format, non-projected mesh glTF G-Poly, but I expect it will work, preferably using MCX' G-Poly Wizard. ;-)

The potential limitation of features IIUC, compared to an Apron Polygon is the inability to display transient environmental effects during / after rain.

But I may be mistaken based on lack of testing; it might be that true MSFS glTF G-Polys created as SimObjects may be able to display transient rain effects ...and a number of other complex effects that Aprons and Projected mesh can not.

On a practical basis though, finding true zoom level-21aerial imagery that exceeds the merged Projected Mesh resolution at that same zoom level-21 is not easy; most ends up being up-sampled imagery that is actually 3 or 4 zoom levels lower in true resolution.

Quite a bit to be tested when the cold weather arrives by years end. ;-)

GaryGB
Gary cant use PolyWizard as it only exports in BGL format, but you can export as a GLTF directly, sanz the issue above. I use Combine Scene feature,.

"has a proper Manifest.json and Layout.json in the root of the add-on folder chain under the top folder alongside the \Scenery and \Texture sub-folders." <- how are those generated? or are those generic files?
 
When I open the gltf, it shows MCX is doing what its supposed to.....the Z Bias properly show as Material draw order. The limitation is on FS side and the use of projected mesh. If the GP object is placed as a normal object using SDK, draw order is respected (but object bleeds with terrain).
 
In what order does MSFS process the ZBias property? Between the FSX ground polygons and P3D v2 ground polygons there is also a difference in this and I have to invert the ZBias value between them to make it work. Could it be something similar here?
 
Gary:

Can't use Poly Wizard as it (currently) only exports in BGL format, but you can export as a GLTF directly, sans the issue above.

I use Combine Scene feature.

"has a proper Manifest.json and Layout.json in the root of the add-on folder chain under the top folder alongside the \Scenery and \Texture sub-folders." <- how are those generated? or are those generic files?

I edited my post above, in-context, to explain my proposed MCX 'MSFS-mode' G-Poly Wizard feature update, and Dick's FSX display workflow:

https://www.fsdeveloper.com/forum/threads/draw-order-of-gps.460365/post-936475


Here is an example of how good a "legacy" FSX scenery can look in MSFS 2020: Bill Womack's 2B2 - Plum Island FSX scenery


1760855092679.png



NOTE: All I had to do was add a few exclusions to eliminate overlapping "place-holder" MSFS default objects to reveal Bill's classic 3D models. :wizard:


BTW: I can display the "Fence", "X", and "Hazards" on the 'East' end of RWY-10 (or is that the 'East' approach to RWY-28 ?) :p

Bill's FSX file format 'flying bird flock' near the 2B2 Nissen / Quonset hangar are also fully animated and cast shadows in MSFS. :scratchch


FYI: Also featured is the fabulous Grumman J2F-4 Duck by Paul Domingue c/o 'flyndive' for MSFS 2020 / 2024:

https://flightsim.to/file/82655/grumman-j2f-duck


Upon request, I can post more detailed info on the minimal work-flow (copy a few files, and put the scenery path in a batch file to be run).

The batch file runs MSFSLayoutGenerator.exe to update the blank Manifest.json and Layout.json in the root of the add-on folder chain; AFAIK, the batch file can be further modified to rename the \ContentInfo folder's nested sub-folder (containing a generic Thumbnail.jpg) to match the add-on's top folder name.

https://github.com/HughesMDflyer4/MSFSLayoutGenerator


PS: FSX' add-on scenery access can be via 0-byte Symbolic Link 'Clones' from FSX' add-on's root install folder to a MSFS 2020 \Community add-on package sub-folder. 🤓

https://github.com/pacman2108/Link-Shell-Extension

...or see the original (highly technical) author website:

https://schinagl.priv.at/nt/hardlinkshellext/linkshellextension.html


Alternatively, one may use directly- or via a batch file-:

Mark Russinovich's SysInternals Junction - Junction Point 'symbolic link' utility:

https://learn.microsoft.com/en-us/sysinternals/downloads/junction


GaryGB
 
Last edited:
In what order does MSFS process the ZBias property? Between the FSX ground polygons and P3D v2 ground polygons there is also a difference in this and I have to invert the ZBias value between them to make it work. Could it be something similar here?
Arno it uses the (+) value shown on the Material Editor of MCX.

If Z Bias is 20, Draw Order is 20 on the resulting GLTF.
 
Gary I think I know why the flickering occurs. The FSX generated ground polys would accommodate the "world roundness" or flat element of the FSX scenery. If you superimpose that on MSFS, you would run into the same issues of the old flat "Sketchup" to FSX conversion of 15 years ago....until MCX came up with the GP Wizard tool. When I try this on my medium size airport.....the taxi lines pretty much disappear (event though my airport is flat).
 
Did you try to convert FS2004 output to glTF then? That does not have the earth curve included.

As for the zbias, I meant did you try negative values for layering? In P3D we also have to do that.
 
Did you try to convert FS2004 output to glTF then? That does not have the earth curve included.

As for the zbias, I meant did you try negative values for layering? In P3D we also have to do that.
I did not try negative Z bias, but the layering order comes out great just as long as it is not a projected mesh.

I dont have FS2004 installed, wouldnt you need the bglcomp from FS2004 to be able to generate FS2004 output?
 
No, the FS2004 ground polygons are compiled with the scasm tool that comes with MCX.
 
Hi again:

AFAIK, based on Don's last posted ADE_GP PDF Manual on his website, all G-Poly output from that utility was SCASM / ASM "FS-8" format.

http://web.archive.org/web/20180404053633/http://stuff4fs.com/Applications/ADE_GP/ADE-GP - User Manual.pdf

[EDITED]

However, a forum thread post here at FSDEV contradicts that assumption based on what I saw in the stuff4fs PDF Manual for ADE_GP.

It seems Don was able to restore the option he tested for use of non-SCASM / ASM / "FS-8" G-Polys (aka "GPs" in ADE parlance).

https://www.fsdeveloper.com/forum/threads/ade-gp-and-p3d-v4.441947/post-790146


IIUC, ADE_GP integrated into ADE was essentially the same as on stuff4fs, and did not have MakeMDL / XtoMDL BGL G-Poly output.

IIRC, SCASM / ASM "FS-8" format used a Z-BIAS that was 'positive' in FS-8, FS-9, FSX, and earlier P3D versions.


I do not recall when L-M implemented the 'negative' Z-BIAS "Material Functionality" required for native G-Polys in (newer ?) P3D versions.

https://www.prepar3d.com/SDKv4/sdk/modeling/3ds_max/modeling/modeling_materials.html#ZBiasLevel


Google AI states it was implemented in P3Dv4+:

https://www.google.com/search?q=Prepar3D+Z-BIAS+"Material+Functionality"&sca_esv=289e7c278657c79e&source=hp&ei=R8L7aOe-Dvuj0PEP6frNQQ&iflsig=AOw8s4IAAAAAaPvQV3Utrbv29m6USKTxhcNGpV2Q3VRC&ved=0ahUKEwin_s3JuL2QAxX7ETQIHWl9MwgQ4dUDCCI&uact=5&oq=Prepar3D+Z-BIAS+"Material+Functionality"&gs_lp=Egdnd3Mtd2l6IihQcmVwYXIzRCBaLUJJQVMgIk1hdGVyaWFsIEZ1bmN0aW9uYWxpdHkiMgUQABjvBTIFEAAY7wUyCBAAGIAEGKIEMgUQABjvBUj1RFAAWOIzcAB4AJABAJgBwgGgAbULqgEEMC4xMbgBA8gBAPgBAvgBAZgCCqAC_gvCAgUQIRirAsICCBAAGKIEGIkFmAMAkgcFMC45LjGgB-sfsgcFMC45LjG4B_4LwgcFMi0yLjjIB3k&sclient=gws-wiz


Pertinent search results:

https://www.google.com/search?q=site:+www.fsdeveloper.com+gadgets+ADE+GP-Editor&sca_esv=289e7c278657c79e&ei=kL37aMuXMbXIwN4Pls_e4AY&ved=0ahUKEwjLn6uKtL2QAxU1JNAFHZanF2wQ4dUDCBM&uact=5&oq=site:+www.fsdeveloper.com+gadgets+ADE+GP-Editor&gs_lp=Egxnd3Mtd2l6LXNlcnAiL3NpdGU6IHd3dy5mc2RldmVsb3Blci5jb20gZ2FkZ2V0cyBBREUgR1AtRWRpdG9yMgUQABjvBTIFEAAY7wUyBRAAGO8FMggQABiABBiiBDIFEAAY7wVIyhRQxwpY1A9wAXgAkAEAmAGmAaABnQOqAQMwLjO4AQPIAQD4AQGYAgSgAvIDwgIIEAAYsAMY7wXCAgsQABiwAxiiBBiJBcICCBAhGKABGMMEmAMAiAYBkAYFkgcDMS4zoAenB7IHAzAuM7gH3gPCBwUyLTEuM8gHLQ&sclient=gws-wiz-serp

PS: Personally, I never used ADE-GP, as I prefer the features in Arnos' MCX G-Poly Wizard (aka "GPW").

Perhaps there may be a 2-way import / export between ADE-GP and MCX GPW, as I have decompiled ADE_GP BGLs and imported into GPW.

IIRC, I had to use Winfried Orthmann's BGLAnalyze 3.1 first, then import the *.SCA into MCX.


BTW: The same workflow was required for MCX' processing / import of SBuilder's SCASM G-Polys.


I have not tried importing MCX' GPW output G-Polys into ADE_GP, but this thread discussed that:

https://www.fsdeveloper.com/forum/threads/import-gp.456338/

[END_EDIT]

GaryGB
 
Last edited:
Since P3D v2 we can use the zbias in mdl files and from that version the zbias value has to be negative as well. In the PBR materials of P3D (so from v4.4) they have to be positive again.
 
So much for Google AI's accuracy ...compared to Arno's memory. :wizard:

GaryGB
It was not my memory, it was my external memory (I looked in the MCX source code how I export it for the different soms).
 
It must be good to understand what you see when you "look under the hood" ...in source code. :)

GaryGB
 
Back
Top