-
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 Error loading modeldef.xml
- Thread starter Nordscape
- Start date
Hi Vetle:
I have never personally had that error in my own work with Sketchup static scenery 3D model exports (aka 3D models that are non-Animated, and not SimObjects, thus having no requested conditional visibility coding).
I would 'speculate' that this is an unimportant status message due to certain (other) MCX Options settings still pointing at FSX as the preferred version of FS for output.
It is possible that by default an empty Animation is inserted into the 3D model, and MCX cannot find the info for implementing that into the glTF which it is being asked to output when you tell MCX to submit the MSFS glTF to MSFS compiler (...just a guess).
One may also wonder if a MCX Option setting still makes MCX believe it should insert 1 or more "Empty LODs" into the 3D model ?
I may be mistaken, as I know Arno has been very meticulous with MCX coding over the years, but I wonder when we see these types of error scenarios, if a mis-match of MCX Options settings not yet understood by newcomers, could be triggering these output / compiler problems ?
I am thinking there may need to be an internal check for congruency in all (not just 'some') MCX settings when one begins toggling between the default install of MCX targeting FSX, and instead targeting MSFS, with to determine processing for both import and export.
IIRC, Arno has already implemented a number of "mode" toggles in some MCX Options settings that changes import processes.
I greatly appreciate having the 'Option' to manually over-ride and configure certain settings in MCX, but in this case I am starting to wonder if newcomers to MCX, (and/or those who do not aspire to "FS Uber-Geek-ness") need a bigger "safety net" while they are still learning how to use MCX, and want to be able to generate some FS content while in the long beginners phase MCX' complexity imposes.
But I am compelled to ask if, as newcomers to the vast intricacies of MCX, we might be further protected from our own lack of meticulous "geek-ness" when we 'dare' to alter the default install of MCX from FSX to the dreaded 'Grendel' of MSFS, by having the ability to create MCX system-wide toggles of settings for MSFS that disables all conflicting settings left over from the default FSX 'mode' present upon installation.
I am thinking of a menu of configuration 'profiles' for MCX itself, that toggle all Options settings between various FS versions.
PS: I also wonder if:
* since MCX (and Blender also ?) allow us to implement our own PBR texture attributes on what originally was a 'generic' texture
* or if we use an incorrectly configured PBR texture from a 3rd party source (ex: a 'free texture' website)
...could we possibly still not yet get full compliance with 'quirks' of MSFS' compiler, and end up with "Pink Checkerboards" ?
I appreciate Arno's efforts to enable many tasks via MCX; but I wonder if MCX still allows 'MSFS incompatible' Options settings if, as beginners, we naively set a mix of Options settings in a way that conflicts with an overall 'profile' that targets a specific FS output version ?
https://devsupport.flightsimulator.com/t/1-18-13-0-pink-textures/3288/28
FlyingRaccoon said:
"The game engine gltf parser now expects paths to be normalized.
As you’re using a standard PBR (3DSMAX) material and not an FSMaterial, the
exporter is not normalizing the paths (which used to be ok). We will fix the
way (standard) (3DSMAX) pbr materials are handled in the exporter BUT , this
gives me the opportunity to remind people that even if the exporter is
tolerant, we strongly advise you to use FSMaterials. This is the type of
materials we use internally, the type we test on a regular (basis), and in the
end, the material with the least chance of regressions. The same applies for
GLTF vs MDL, ArtProj vs ModelLib, etc… Replacing your materials with
FSMaterials (will) solve your issue."
https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/mitigation-path-normalization
BTW: The MSFS SDK properly refers to these options as "FLIGHTSIM MATERIALS"; ...appallingly little is to be found on Google.
https://docs.flightsimulator.com/html/Asset_Creation/3DS_Max_Plugin/Materials.htm?rhhlterm=flightsim materials material&rhsearch=FLIGHTSIM MATERIALS
[RANT_MODE_ON]
Hmmm... that reeks of 'URI-ne' due to a "ScriptKiddie" 'piddling around' and not going the full distance with MSFS SDK coding when creating the 3DSMAX and/or Blender exporter.
What about projects that are not routed through a 3DSMAX and/or Blender exporter, and are submitted instead directly to MSFS compiler ?
OK, again an Asobo admonishment for using PBR texture sets that are not "standard 3DSMAX PBR materials" or "FSMaterials".
This begs the question: how do we create or convert custom PBR texture sets to "standard 3DSMAX PBR materials" or "FSMaterials" ?
Are we not able to utilize "standard 3DSMAX PBR materials" and "FSMaterials" in applications other than 3DSMAX and Blender ?
[RANT_MODE_OFF]
Perhaps Arno as author of MCX, and others knowledgeable on these MSFS workflows could please help us out with this one ?
Many thanks in advance for any assistance Arno may be able to provide in this regard.
GaryGB
I have never personally had that error in my own work with Sketchup static scenery 3D model exports (aka 3D models that are non-Animated, and not SimObjects, thus having no requested conditional visibility coding).
I would 'speculate' that this is an unimportant status message due to certain (other) MCX Options settings still pointing at FSX as the preferred version of FS for output.
It is possible that by default an empty Animation is inserted into the 3D model, and MCX cannot find the info for implementing that into the glTF which it is being asked to output when you tell MCX to submit the MSFS glTF to MSFS compiler (...just a guess).
One may also wonder if a MCX Option setting still makes MCX believe it should insert 1 or more "Empty LODs" into the 3D model ?
I may be mistaken, as I know Arno has been very meticulous with MCX coding over the years, but I wonder when we see these types of error scenarios, if a mis-match of MCX Options settings not yet understood by newcomers, could be triggering these output / compiler problems ?
I am thinking there may need to be an internal check for congruency in all (not just 'some') MCX settings when one begins toggling between the default install of MCX targeting FSX, and instead targeting MSFS, with to determine processing for both import and export.
IIRC, Arno has already implemented a number of "mode" toggles in some MCX Options settings that changes import processes.
I greatly appreciate having the 'Option' to manually over-ride and configure certain settings in MCX, but in this case I am starting to wonder if newcomers to MCX, (and/or those who do not aspire to "FS Uber-Geek-ness") need a bigger "safety net" while they are still learning how to use MCX, and want to be able to generate some FS content while in the long beginners phase MCX' complexity imposes.
But I am compelled to ask if, as newcomers to the vast intricacies of MCX, we might be further protected from our own lack of meticulous "geek-ness" when we 'dare' to alter the default install of MCX from FSX to the dreaded 'Grendel' of MSFS, by having the ability to create MCX system-wide toggles of settings for MSFS that disables all conflicting settings left over from the default FSX 'mode' present upon installation.
I am thinking of a menu of configuration 'profiles' for MCX itself, that toggle all Options settings between various FS versions.
PS: I also wonder if:
* since MCX (and Blender also ?) allow us to implement our own PBR texture attributes on what originally was a 'generic' texture
* or if we use an incorrectly configured PBR texture from a 3rd party source (ex: a 'free texture' website)
...could we possibly still not yet get full compliance with 'quirks' of MSFS' compiler, and end up with "Pink Checkerboards" ?
I appreciate Arno's efforts to enable many tasks via MCX; but I wonder if MCX still allows 'MSFS incompatible' Options settings if, as beginners, we naively set a mix of Options settings in a way that conflicts with an overall 'profile' that targets a specific FS output version ?
https://devsupport.flightsimulator.com/t/1-18-13-0-pink-textures/3288/28
FlyingRaccoon said:
"The game engine gltf parser now expects paths to be normalized.
As you’re using a standard PBR (3DSMAX) material and not an FSMaterial, the
exporter is not normalizing the paths (which used to be ok). We will fix the
way (standard) (3DSMAX) pbr materials are handled in the exporter BUT , this
gives me the opportunity to remind people that even if the exporter is
tolerant, we strongly advise you to use FSMaterials. This is the type of
materials we use internally, the type we test on a regular (basis), and in the
end, the material with the least chance of regressions. The same applies for
GLTF vs MDL, ArtProj vs ModelLib, etc… Replacing your materials with
FSMaterials (will) solve your issue."
https://learn.microsoft.com/en-us/dotnet/framework/migration-guide/mitigation-path-normalization
BTW: The MSFS SDK properly refers to these options as "FLIGHTSIM MATERIALS"; ...appallingly little is to be found on Google.
https://docs.flightsimulator.com/html/Asset_Creation/3DS_Max_Plugin/Materials.htm?rhhlterm=flightsim materials material&rhsearch=FLIGHTSIM MATERIALS
[RANT_MODE_ON]
Hmmm... that reeks of 'URI-ne' due to a "ScriptKiddie" 'piddling around' and not going the full distance with MSFS SDK coding when creating the 3DSMAX and/or Blender exporter.
What about projects that are not routed through a 3DSMAX and/or Blender exporter, and are submitted instead directly to MSFS compiler ?
OK, again an Asobo admonishment for using PBR texture sets that are not "standard 3DSMAX PBR materials" or "FSMaterials".
This begs the question: how do we create or convert custom PBR texture sets to "standard 3DSMAX PBR materials" or "FSMaterials" ?
Are we not able to utilize "standard 3DSMAX PBR materials" and "FSMaterials" in applications other than 3DSMAX and Blender ?
[RANT_MODE_OFF]
Perhaps Arno as author of MCX, and others knowledgeable on these MSFS workflows could please help us out with this one ?
Many thanks in advance for any assistance Arno may be able to provide in this regard.
GaryGB
Last edited:
- Messages
- 34,312
- Country
Did you edit your modeldef.xml file? It might be the xml syntax is not valid and that it therefore can't be read.
Without the modeldef.xml file you will not be able to export animations, etc. So depending on what model you work with you can ignore it or not.
Without the modeldef.xml file you will not be able to export animations, etc. So depending on what model you work with you can ignore it or not.
Hi Arno:
The OP did above not link to his (2) preceding threads with details on the fact that this is a simple static 3D model of a building:
https://www.fsdeveloper.com/forum/threads/ensx-stavanger-ems-helicopter.459356/
https://www.fsdeveloper.com/forum/t...tures-for-further-process.459389/#post-929290
GaryGB
The OP did above not link to his (2) preceding threads with details on the fact that this is a simple static 3D model of a building:
https://www.fsdeveloper.com/forum/threads/ensx-stavanger-ems-helicopter.459356/
https://www.fsdeveloper.com/forum/t...tures-for-further-process.459389/#post-929290
GaryGB
- Messages
- 410
- Country
Correct as Gary mentioned, it's only a static model. Then I understand that it's not necessary for me to investigate this further. Thanks for all the input!
- Messages
- 410
- Country
Hmm. weird. The SDK has been installed through the simulator developer mode? But yeah, only statics
- Messages
- 410
- Country
Ah, I see. Well, as long as it doesn't matter with static models I guess I'm fine with having it like that. Thanks for the input though!