Microsoft Flight Simulator[2020] GLTF/BIN

[CosmicDreams]

https://cdn.discordapp.com/attachments/419711036837330956/746842975711133787/FS-GLTF.zip

MFS2020 seems to be using just GLTF for it's aircraft models(perhaps even for other things just other stuff is packed in BGL archives)

Existing tools don't seem to work however, so they might have tinkered with it a bit

i ACCIDENTALLY PUT THIS IN GAME ARCHIVE BEFORE. IF MODS SEE THIS, PLEASE REMOVE THAT ONE.

[CosmicDreams]

Okay turns out Noesis can open the GLTF's but they are pretty broken...

[coredevel]

Can you upload a smaller model that has the same problem? This airplane has over a million vertices, so it's kind of overwhelming when you want to print out debug information.

The filename says LOD00. LOD 0 is the highest poly LOD. Does the same airplane have other LODs, and do they show up correctly?

[CosmicDreams]

Can you upload a smaller model that has the same problem? This airplane has over a million vertices, so it's kind of overwhelming when you want to print out debug information.

The filename says LOD00. LOD 0 is the highest poly LOD. Does the same airplane have other LODs, and do they show up correctly?

There are other lods yes. I think all of them are broken.
Here: https://cdn.discordapp.com/attachments/419711036837330956/750797648683860030/cessna.zip

[coredevel]

Thanks. From what I can tell, MSFS 2020 GLTFs use a nonstandard vertex format. It's interleaved, which is ok, but the components are stored in an nonstandard format.

position = VEC3 floats (ok)
tangents = VEC4 bytes (nonstandard)
normals = VEC4 bytes (nonstandard)
tex_0 = VEC2 shorts (nonstandard)
tex_1 = VEC2 shorts (nonstandard)
color_0 = VEC4 ushorts (ok)
indices = ushorts (ok)

These nonstandard components should be stored as floats, because if they're stored as shorts or bytes, then GLTF doesn't tell us how to decompress them back into floats.

MSFS 2020 also uses .DDS textures, which is nonstandard. To support .DDS, Microsoft added its own extension, so any GLTF reader must be able to understand these vendor-specific extensions to process it.

And in the your screenshot, the landing gear is floating. This may be due to the fact these parts are either invisible or animated, so we don't see they're true location when loaded out of the game.

[CosmicDreams]

Thanks. From what I can tell, MSFS 2020 GLTFs use a nonstandard vertex format. It's interleaved, which is ok, but the components are stored in an nonstandard format.

position = VEC3 floats (ok)
tangents = VEC4 bytes (nonstandard)
normals = VEC4 bytes (nonstandard)
tex_0 = VEC2 shorts (nonstandard)
tex_1 = VEC2 shorts (nonstandard)
color_0 = VEC4 ushorts (ok)
indices = ushorts (ok)

These nonstandard components should be stored as floats, because if they're stored as shorts or bytes, then GLTF doesn't tell us how to decompress them back into floats.

MSFS 2020 also uses .DDS textures, which is nonstandard. To support .DDS, Microsoft added its own extension, so any GLTF reader must be able to understand these vendor-specific extensions to process it.

And in the your screenshot, the landing gear is floating. This may be due to the fact these parts are either invisible or animated, so we don't see they're true location when loaded out of the game.

The small rod next to the wheel is the pole that mounts the wheel casing to the fuselage. I believe the bones are in the incorrect positions...

[coredevel]

These 4 parts (small rods) are floating:
LANDING_CENTER_PIVOTL
LANDING_CENTER_PIVOTR

LANDING_LEFT_LEG
LANDING_RIGHT_LEG

In the scene hierarchy, they have no parent, so they are transformed at root. Unlike the rest of the plane, they are bound to skins, so there's some extra transformation going on there. It seems to me, the parts that have problems, are always skinned. Parts that are not skinned look ok, I would guess it's skinning issue, either with the importer or exporter.

BTW, this model was exported from 3dsmax 2019 using the babylon.js glTF exporter:

"asset" : {
"generator" : "babylon.js glTF exporter for 3dsmax 2019 v1.5.0",
},

Plugins and source code found here:
https://github.com/BabylonJS/Exporters/releases/

But, what I really like to find is a GLTF importer for 3dsmax, so I could test it somewhere else.

I attached a human readable GLTF file with line breaks.

[coredevel]

I noticed something else.

Usually, this is how vertices are transformed:
1. A MeshInstance without a skin (rigid) will be transformed by the node that contains it.
2. A MeshInstance with a skin (skinned) will be transformed by the nodes pointed by the skin.

There is a problem here with #2 for this model. These 4 troublesome parts have a transform in their mesh nodes. When a mesh is skinned, #2 says this transform is ignored, so there shouldn't be a transform here. In other words, these nodes shouldn't have any rotation/scale/translation fields.

{
"mesh" : 42,
"name" : "LANDING_CENTER_PIVOTL",
"rotation" : [ 0.1281711, -0.00414568931, 0.0320621133, 0.991225 ],
"scale" : [ 0.99999994, 0.99999994, 0.99999994 ],
"skin" : 1,
"translation" : [ 0.0720584244, -0.7337615, 1.1861788 ]
},
{
"mesh" : 43,
"name" : "LANDING_CENTER_PIVOTR",
"rotation" : [ 0.129827321, 0.004687555, -0.0367405638, 0.9908446 ],
"scale" : [ 1.00000012, 0.99999994, 0.9999999000000001 ],
"skin" : 2,
"translation" : [ -0.07194746000000001, -0.733509839, 1.18668592 ]
},
{
"mesh" : 44,
"name" : "LANDING_LEFT_LEG",
"rotation" : [ 0, 0, 0, 1 ],
"scale" : [ 1, 1, 1 ],
"skin" : 3,
"translation" : [ 0.7221286, -0.7317269, -0.5423519610000001 ]
},
{
"mesh" : 45,
"name" : "LANDING_RIGHT_LEG",
"rotation" : [ 0, 0, 0, 1 ],
"scale" : [ 1, 1, 1 ],
"skin" : 4,
"translation" : [ -0.7221286, -0.7317269, -0.5423519610000001 ]
},

I believe this is bad data, bad exporter. Skinned meshes shouldn't have a node transform. I don't know how Microsoft load these meshes without error, but whatever they do, it's probably nonstandard.