MSFS20 MCX "Same Key" Error Exporting glTF

[GaryGB]

Hi Arno:

I apparently did not have the latest update to MSFS default package files cited in my recent thread here:

https://www.fsdeveloper.com/forum/threads/mcx-gdi-error-converting-dds-to-png.453581/


After a MSFS Content Manager World Update: USA-II, was updated / installed, the above cited KFHR package contains new files.



In MCX September 14, 2021 - Build, I imported:

[MSFS-2020_Packages_Install_Path]\Official\OneStore\microsoft-airport-kfhr-friday-harbor\scenery\Microsoft\Friday-Harbor\modelLib.BGL


In MCX > Material Editor > {Textures} tab, all selected mapped textures were able to be converted from DDS to PNG with NO GDI+ error


But, when I attempt to export from MCX: Object 27/30 (KFHR-05) a glTF 3D model, MCX stops the export, then throws this error:

"Error: An item with the same key has already been added."



PS: The final MCX Event Log entry before the KFHR-05 glTF export object process 'stopped' ...is:

12:23 AM glTFWriter Information Object contains multiple LODs, these will be exported as separate objects.


I am intrigued as to this reference to there being "multiple LODs", since IIUC, these would have to all be compiled into the modelLib.BGL.


BTW: The modelLib.BGL was imported initially by MCX BGLXReader:

12:23 AM BGLXReader Information Read 30 object models, 0 object placements, 0 effect placements
12:23 AM AllObjectReader Information Cleaning object: KFHR-05
12:23 AM AllObjectReader Information Removed 2 triangles with small area
12:23 AM AllObjectReader Information Cleaning object: KFHR-27
12:23 AM AllObjectReader Information Removed 5 triangles with small area
12:23 AM AllObjectReader Information Cleaning object: KFHR-30
12:23 AM AllObjectReader Information Removed 4 triangles with small area
12:23 AM AllObjectReader Information Cleaning object: KFHR-29
12:23 AM AllObjectReader Information Removed 8 triangles with small area


MCX Object Information for KFHR-05 shows apparent use of (5) LODs and multiple "Attachpoints" for 'light00 [R255 G255 B255]'

MCX Attached_Object_Editor info for KFHR-05 shows apparent use of multiple "Attachpoints" for 'light00 [R255 G255 B255]'

A search of MSFS SDK online documentation web pages returns no hits for "Attachpoint"

Anthony31 states:

ADDING A VISIBILITY CONDITION:

Now, here is a very important distinction between ModelBehavior code and PartInfo code. With PartInfo you could either use an Attachpoint (no longer supported in MSFS) or add it to an animated. With ModelBehavior the visibility condition is completely separate to any animation. You can easily make non-animated parts visible or not visible. While the ASOBO_GT_Anim templates refer to the name of the animation in your 3D model visibility refers to the name of your part.

So, does the latter information posted above in this "PS", mean MSFS' KFHR-05 source "Library" modelLib.BGL ...is compiled in MDL format ?

I would greatly appreciate your advice as to how to eliminate this error, so MCX glTF export can complete output of the selected object.

GaryGB

 

[arno]

Hi Gary,

But, when I attempt to export from MCX: Object 27/30 (KFHR-05) a glTF 3D model, MCX stops the export, then throws this error:

"Error: An item with the same key has already been added."

I just tried it here, but I don't get this error. But my model does show less attachpoints for the lights, so I think I don't have the latest update yet.

I think the fact that some attachpoints have the same name and maybe also the same position is part of the error. I will try to get the latest MSFS update here, but that is often a struggle so might take a while.

12:23 AM glTFWriter Information Object contains multiple LODs, these will be exported as separate objects.

I am intrigued as to this reference to there being "multiple LODs", since IIUC, these would have to all be compiled into the modelLib.BGL.

Yes, all LOD are compiled into the BGL file. But when you export to glTF each LOD is its own glTF file. The package tool will combine them all into one BGL. But the message refers to the multiple glTF files that are made.

 

[GaryGB]

BTW: The modelLib.BGL was imported initially by MCX BGLXReader:

12:23 AM BGLXReader Information Read 30 object models, 0 object placements, 0 effect placements
12:23 AM AllObjectReader Information Cleaning object: KFHR-05
12:23 AM AllObjectReader Information Removed 2 triangles with small area
12:23 AM AllObjectReader Information Cleaning object: KFHR-27
12:23 AM AllObjectReader Information Removed 5 triangles with small area
12:23 AM AllObjectReader Information Cleaning object: KFHR-30
12:23 AM AllObjectReader Information Removed 4 triangles with small area
12:23 AM AllObjectReader Information Cleaning object: KFHR-29
12:23 AM AllObjectReader Information Removed 8 triangles with small area


MCX Object Information for KFHR-05 shows apparent use of (5) LODs and multiple "Attachpoints" for 'light00 [R255 G255 B255]'

MCX Attached_Object_Editor info for KFHR-05 shows apparent use of multiple "Attachpoints" for 'light00 [R255 G255 B255]'

A search of MSFS SDK online documentation web pages returns no hits for "Attachpoint"

Anthony31 states:

ADDING A VISIBILITY CONDITION:

Now, here is a very important distinction between ModelBehavior code and PartInfo code. With PartInfo you could either use an Attachpoint (no longer supported in MSFS) or add it to an animated. With ModelBehavior the visibility condition is completely separate to any animation. You can easily make non-animated parts visible or not visible. While the ASOBO_GT_Anim templates refer to the name of the animation in your 3D model visibility refers to the name of your part.

So, does the latter information posted above in this "PS", mean MSFS' KFHR-05 source "Library" modelLib.BGL ...is compiled in MDL format ?

I would greatly appreciate your advice as to how to eliminate this error, so MCX glTF export can complete output of the selected object.

GaryGB

Hi,

For P3D you should see both the inner and outer cone. Or do the two cones have the same value?

When exporting to MSFS there is only one cone after import.

Notice in the MCX Attached Object Editor screenshot above, KFHR-05 in modelLib file imported to MCX has both Inner and Outer Cones.


Thus, I am again compelled to ask:

So, does the latter information posted above in this "PS", mean MSFS' KFHR-05 source "Library" modelLib.BGL ...is compiled in MDL format ?

Thanks again for your reply, and advice as to how to eliminate this error, so MCX glTF export can complete output of the selected object.

GaryGB

 

[arno]

Hi,

The version of the model I have here does show the inner and outer cone with the same value, so in that case only one is rendered in MCX as well. Do they have different values after the latest update, I doubt it since the glTF file only stores one cone angle.

Actually any glTF model is wrapped in a kind of MDL file inside the modellib.bgl file. So in a way the models are still MDL files. But I think when you write they are a MDL file, you mean a legacy MDL file.

At the moment I can't give you advice on how to fix the export error. To fix it I need to be able to reproduce it myself first and for that it seems I need to get the latest MSFS update first. Which is a time consuming and frustrating activity. You could try to rename some attachpoints so that they are uniquely named.

 

[GaryGB]

Many thanks for your reply, and your ongoing efforts with this, Arno.

I was able to update / display KFHR_05 files in MSFS, but I have yet to find where MS wrote USA_II update; maybe I have (2) package folders ?


I'll tinker a bit more to see what I might be able to discern.

UPDATE:

I just did a search for modelLib.BGL with "Everything Search" from VoidTools; there are hundreds of MSFS files with that name.

https://www.voidtools.com/


I did find I still have only (1) 'active' MSFS packages folder chain now, after downloading World Update II: USA and (2) other items via:

MSFS Main Menu GUI > Profile > Content Manager.


To verify where the MSFS "active" packages folder is located:

MSFS Menu GUI > Options > General Options > Developers Menu > Tools > Packages > Re-size dialog via blue 'handle' at bottom Right


PS: Try this location at night; the lights apparently are all working, and this scenery now looks fabulous (...many thanks to MS for this as well).

GaryGB

 

[arno]

Hi Gary,

Just to let you know now that I updated MSFS I can reproduce the error you get. Let me try to fix it.

 

[GaryGB]

Thanks Arno; I had noticed the same thing.

[EDITED]

IIRC, I did not get the error with the 'prior' non-MSFS glTF version of the object export.

[END_EDIT]

GaryGB

 

[GaryGB]

Hi again, Arno:

I found that the MCX error reported above has been reported previously here on a few occasions in the past:

https://www.google.com/search?q=site:www.fsdeveloper.com+Error:+An+item+with+the+same+key+has+already+been+added&client=firefox-b-1-d&ei=2SFKYfrYK9uFtQb31IfwCg&oq=site:www.fsdeveloper.com+Error:+An+item+with+the+same+key+has+already+been+added&gs_lcp=Cgdnd3Mtd2l6EAM6CggAEOoCELQCEEM6EAguEMcBENEDEOoCELQCEEM6CgguEOoCELQCEEM6CAgAEIAEELEDOgQIABBDOgsILhCABBDHARCjAjoRCC4QgAQQsQMQgwEQxwEQowI6BQgAEIAEOg4ILhCABBCxAxDHARCjAjoOCC4QgAQQsQMQxwEQ0QM6DQguEMcBENEDEEMQkwI6CwguEIAEEMcBEK8BOggILhCABBCxAzoECC4QQzoHCAAQsQMQQzoLCAAQgAQQsQMQgwE6CAgAELEDEMkDOgsILhCABBDHARDRAzoRCC4QgAQQsQMQxwEQowIQkwJKBQg4EgExSgQIQRgAUOoaWLiTA2CMsgNoAXAAeACAAYsBiAGCCJIBAzYuNZgBAKABAaABArABCsABAQ&sclient=gws-wiz&ved=0ahUKEwi6qZHY1pDzAhXbQs0KHXfqAa4Q4dUDCA0&uact=5


Is there something that end users of MCX may need to do manually with the example file / object cited above, to work around the error ?

Thanks for your clarification of what our options may be for exporting glTFs from MSFS 3D scenery models inside default "Library" BGLs.

GaryGB

 

[arno]

Hi,

The error you reported has been fixed now, so if you get the latest development release it is solved.

I have seen errors with the same description, but in different parts of the code, in my bugtracker. These are usually related to exporting X files. However I have never been able to reproduce them with the information in the bug report. So most likely in those situations the users made some manual edits to the model before exporting.

 

[GaryGB]

Hi Arno:

Many thanks for fixing this error in MCX; I am now able to successfully export both generic Khronos glTF 2.0 and MSFS-type glTF files.


Additionally I am now able to convert the original MSFS DDS textures to PNG for import and display in Sketchup without this GDI+ error:

https://www.fsdeveloper.com/forum/threads/mcx-gdi-error-converting-dds-to-png.453581/


FYI: a Sketchup free ASSIMP-based Universal Importer plugin by Samuel Tallet is able to retain / display Edges on imported glTF Faces.

SketchUp Plugins | PluginStore | SketchUcation

SketchUp Plugin and Extension Store by SketchUcation provides free downloads of hundreds of SketchUp extensions and plugins

sketchucation.com

The Sketchup PBR Viewport by Samuel Tallet included with his Physically-Based Rendering plugin Ruby script is amazing:

SketchUp Plugins | PluginStore | SketchUcation

SketchUp Plugin and Extension Store by SketchUcation provides free downloads of hundreds of SketchUp extensions and plugins

sketchucation.com

GitHub - SamuelTallet/SketchUp-PBR-Plugin: Open-source Physically-Based Rendering extension for SketchUp 2017 or newer.

Open-source Physically-Based Rendering extension for SketchUp 2017 or newer. - SamuelTallet/SketchUp-PBR-Plugin

github.com

Technology used by the Sketchup PBR Viewport by Samuel Tallet allows quality, real-time rendering which approximates that of MSFS 2020.


One might wonder if the Chrome / ClayGL WebGL graphic library technology used for Sketchup PBR Viewport may also merit use in MCX ?

Home - ClayGL Documentation

docs.claygl.xyz

I anticipate that your updates to MCX may allow further development of a Sketchup-based work-flow for MSFS 3D scenery production.

GaryGB

 

[arno]

Hi Gary,

Not sure what kind of MCX updates you still anticipate for SketchUp. As I read it the pbr addons for SketchUp save as glTF, so MCX should be able to read them. If you encounter bugs there, please report them with a sample in a new thread.

But as I see it a workflow with SketchUp is possible already.