MSFS20 Modifying 3D Virtual Cockpits in MSFS

[arwasairl]

Hey ya'll,

So I'd like to add some objects for some of the default MSFS aircraft as well as 3rd party aircraft virtual cockpits, but it's proven to be a bit of a pain. For reference, for FSX/ESP, VC models can easily be added new features by creating your model feature in Max, exporting it as an MDL, merging the new feature with the original VC, then re-exporting the merged .MDL and it would perform exactly as advertised.

I've tried the same principal in MSFS, instead of MDL using gLTF, however, the new model is completely ignored by MSFS and acts as if the VC is just the external model being used now. I've used standard Flight Simulator materials as well as .DDS textures to fit with the standard as most as I possibly can, but the new VC model is completely ignored. When replacing it with the original, it performs as normal. I know that things like the modeldef is no longer compiled into the .MDL, but that extra .XML file should be taking care of that by itself. The GUIDs of both models also keep changing after every import (not something I expected), so I'm not entirely sure what the actual issue is.

 

[=rk=]

I've done a great deal of hacking and parts swapping between default Asobo components and new models, I have an addon at flightsim.to that has three AI airplanes that use animated landing gear from default models. I've commented extensively on the subject and you're welcome to explore my history or addons. Here is my "flying desktop," I made it for a model of the Waverider scramjet, on the principle that one could only pilot such a vehicle remotely.

It is all "cranked out" like that because the model had reached the edge of simulated space and is trying to reproduce cataclysmicly unstable gyrations. The gauges come from the default Daher 960 and if I am not mistaken, they had been slightly tweaked to display a performance envelope suitable to a hypersonic scramjet. I suspended development after an update forced the exterior model to be visible while in the cockpit, essentially making the desk straddle the missile, which I found to be intolerable. The moral being that this outcome is expectable using this approach to customizing Asobo's flight sim, creating addon Packages is the highly preferred method.

I can't really suggest where you've gone wrong, because I can't discern much of a procedure. I can say that materials probably aren't the problem, MSFS is pretty flexible about materials, just so long as any associated textures are exactly power of four and .png format that has been converted to .dds format leaving .png as part of the suffix, as if that sort of thing even makes sense. You could just stick to polygon color until you have a working model.

Overall, MSFS is not that extremely different from FSX. One of the biggest distinctions, which you've alluded to is the allmighty XML. No seriously, church of XML kind of thing, get some sort of talisman. I can recommend that you run through the Simple Gauge aircraft SDK sample, study it, tweak it, whatever, but at least build it. Also, are you resetting the Layout.json before testing each change? Because if the contents of the Package do not match the list in the Layout.json, the sim rejects the Package and instead loads the version stored in the buffer.

 

[arwasairl]

Overall, MSFS is not that extremely different from FSX. One of the biggest distinctions, which you've alluded to is the allmighty XML. No seriously, church of XML kind of thing, get some sort of talisman. I can recommend that you run through the Simple Gauge aircraft SDK sample, study it, tweak it, whatever, but at least build it. Also, are you resetting the Layout.json before testing each change? Because if the contents of the Package do not match the list in the Layout.json, the sim rejects the Package and instead loads the version stored in the buffer.

I've noticed that even attaching an untextured cube with a white material inside the cockpit also causes the sim to reject the model, as well as deleting any component (important or not) causes the sim to also reject the entire model. However, if I open the model in MCX and then re-export without making any changes, the sim does NOT reject the model. This only really happens if I'm trying to edit aircraft model packages that are already compiled, like any Asobo or 3rd party aircraft. If I of course had the source 3DSMax project file, this entire procedure would not be as convoluted.

I've searched up a tutorial on adding objects to VCs, but it's outdated by 2 years and (judging by the comments) it no longer works. The procedure also seems mind-bogglingly confusing with all these extra packaging stuff. As far as the layout.json is
concerned, I'm not entirely sure how to reset an packaged addon's layout.json. I'm assuming I'd need to compile it again through DevMode to get a new one, but since it is packaged already, it's the reason why I haven't done that route because in my mind, I'd be recompiling a project that's already been compiled by the original developer. Have I mentioned how confusing this is to me yet? Lol.

EDIT: I've also looked at how others in the community have done it, and it does appear that any modifications made to say, the PMDG 737's cockpit model is done as a completely separate add-on package rather than editing the original model. Pretty different from how I'm used to doing it, but I'll drag my feet over to the package manager even though I really hate it, lol.

 

[arno]

Hi,

If you export a glTF file with MCX it first needs to be run through the MSFS packager tool, did you do that as well? Directly exporting into a model that has been packaged already will not work indeed.

And be aware that MSFS can not export everything to glTF at the moment, you will loose things like skin and bone animations, mouse rectangles, etc.

 

[arwasairl]

Hi,

If you export a glTF file with MCX it first needs to be run through the MSFS packager tool, did you do that as well? Directly exporting into a model that has been packaged already will not work indeed.

And be aware that MSFS can not export everything to glTF at the moment, you will loose things like skin and bone animations, mouse rectangles, etc.

Thanks Arno, I wasn't really sure/aware of how important the packaging system is in MSFS; I'm too used to the drag 'n drop philosophy.

However, do I open the already packaged addon as a package in DevMode or do I have to create a new separate package for the modifications I've done only?

 

[arno]

I don't think you can open an already packaged addon package in the package tool, you would need to have the original source files for that. So without these sources I think making a modification will be quite some work, as you would have to recreate many of the input data (e.g. for animations).

 

[=rk=]

Most edits can be accomplished in the same manner a repaint is distributed. The MSFS repaint is a standalone Package, that essentially edits the default, or addon aircraft that is already present. So you'd structure your gauge, autopilot, EFB, whatever, as an addon itself, only including the folders and files that are added or superseded from the original aircraft.

 

[arwasairl]

Thanks Rich and Arno. I'd assume that since I was modifying an already packaged aircraft, it would make more sense just to overwrite the model with my edited model, but it does appear that this packaging system is required to make such changes.

 

[Lagaffe]

Hi,

When you want to modify an existing model by merging another file as you could do under FSX and MCX, you can use under MSFS another method and especially another tool than MCX.

The last SDK have been improved on this point and it is possible in the two XML files that describe the actions of the 3D models to add additional tags to add a second gltf file to the one you want to modify.

This can be do with a Model Attachement tag which is described in the SDK.
Example from the SDK:

<?xml version="1.0" encoding="utf-8"?>
<ModelInfo guid="{daba6ada-f090-4a4c-b0f0-f91f30932b4b}" version="1.1">
<LODS>
<LOD ModelFile="parent_LOD0.gltf" minSize="30">
<AttachModel id="child_model"/>
</LOD>
<LOD ModelFile="parent_LOD1.gltf" minSize="10">
<AttachModel id="child_model"/>
</LOD>
<LOD ModelFile="parent_LOD2.gltf" minSize="5">
<AttachModel id="child_model"/>
</LOD>
<LOD ModelFile="parent_LOD3.gltf" minSize="3"/>
</LODS>
<ModelAttachments>
<ModelAttachment id="child_model">
<AttachToNode>attachment_point</AttachToNode>
<Model>..\model.child\model.xml</Model>
</ModelAttachment>
</ModelAttachments>
</ModelInfo>

Informations and tags to add are in bold and italic.
In this example, you add a child_model.glTF to parent_LOD0.glTF (and to others LOD) via a "attachment point" node.
This technique has already been used effectively by some publishers.

 

[=rk=]

Thank you, Didier.

I just noticed you typed "parent_LOD0.glTF." I am creating my first "Project" aircraft, all the rest had been made by mashing default Asobo stuff with my own. Anyway, it took me the entire weekend to get the package to build, because my model was named "SimpleAircraft.glTF" I did not need additional LOD's because I was only testing, but it took me all the extra time of trial and error to discover the one difference, is that he default sample is actually named SimpleAircraft_LOD00.glTF, along with the other LOD versions and FSPackagetool will not build unless this naming convention is adhered to. It does not matter that there are no other LOD models and the suffix "_LOD0.glTF" may also work, but this is not something I've not found documented so I thought this account of my experience might prove useful.

 

[GaryGB]

A MSFS glTF 3D model added via AttachPoint to a MSFS glTF 3D model with LODs, a added 3D model need not contain LODs matching a 'Parent'.

"The benefit of this system is that the attached model is not merged into the aircraft itself, and so has its own set of LODs and animations that can be set differently to those of the aircraft itself, which can greatly improve performance. Using the aircraft passenger example again: your attached passengers may not be close to the camera and so it can be on LOD2, while the aircraft itself is on LOD0, meaning that fewer polygons are being rendered."

https://docs.flightsimulator.com/html/Content_Configuration/Models/Model_Examples.htm#h



AFAIK, the MSFS SDK minSize parameter value may control run time LOD loading / display sequence ...instead of the LOD 'name' itself.


IIUC, in MSFS' SDK, adding a Child 3D model to a Parent is a "Model Attachment":

https://docs.flightsimulator.com/html/Asset_Creation/3D_Models/Model_Attachments.htm


"Note that this is not the same as the Submodel Merging feature, since the glTF files used for attached models can have a distinct hierarchy and will have the LOD limits applied to them independently, while sub-models need to maintain the hierarchy and LOD levels of the original "main" model."


PS: This is to be distinguished from 'Merging SubModels':

https://docs.flightsimulator.com/html/Asset_Creation/3D_Models/Submodel_Merging.htm

"Note that this is not the same as the Model Attachments feature, since the glTF files used for sub-model merging should maintain the hierarchy and LOD levels of the original "main" model, while attached models can have a distinct hierarchy and will have the LOD limits applied to them independently"

GaryGB

 

[Lagaffe]

Rick,
In my experience, for my first plane (HN-433), I followed this principle to the letter (HN433_Intern_LOD00.gltf & HN433_Extern_LOD00.gltf) but I found that it didn't matter : for the second plane (Canso PBY-5A), I changed my naming (PBY_Intern.gltf & PBY_Extern.gltf) and that worked too.
It doesn't seem to depend on the version of the SDK because very recently I compiled again using the second method and it worked fine.

Gary,
I found this feature two days ago so I shared it but haven't tried it yet.
As for merging, indeed it's another technique that someone (Stephan aka "Lord Frites") on the internet tried to write documentation about. You can find his work here: https://flightsim.to/file/36150/gltf-compiler-doc-example. I haven't experimented yet because I'm in the process of finalizing an ongoing project.

 

[=rk=]

Rick,
In my experience, for my first plane (HN-433), I followed this principle to the letter (HN433_Intern_LOD00.gltf & HN433_Extern_LOD00.gltf) but I found that it didn't matter : for the second plane (Canso PBY-5A), I changed my naming (PBY_Intern.gltf & PBY_Extern.gltf) and that worked too.
It doesn't seem to depend on the version of the SDK because very recently I compiled again using the second method and it worked fine.

Very odd, I am absolutely sure the build completed because of the name switch. I am guessing the Canso has LOD models, yes? Even so, it would be odd that FSPackagetool requires LOD models, but would satisfy that requirement upon discovering any single "xxx_LODXX" model, odder still if Canso had no extra LOD's and my build cleared for reasons unrelated to the name change.

 

[Lagaffe]

Sorry but all the aircraft I have compiled so far for FS2020 have only one LOD.

 

[=rk=]

No need to apologize on behalf of Asobo nomenclature oddities, thank you.