ZenHAX

Free Game Research Forum | Official QuickBMS support | twitter @zenhax | SSL HTTPS://zenhax.com
It is currently Tue Oct 20, 2020 5:26 am

All times are UTC




Post new topic  Reply to topic  [ 8 posts ] 
Author Message
PostPosted: Sat Aug 22, 2020 10:10 pm 

Joined: Thu Sep 13, 2018 6:38 pm
Posts: 95
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.


Top
   
PostPosted: Sun Aug 23, 2020 4:26 pm 

Joined: Thu Sep 13, 2018 6:38 pm
Posts: 95
Okay turns out Noesis can open the GLTF's but they are pretty broken...
Image


Top
   
PostPosted: Tue Sep 01, 2020 9:43 pm 

Joined: Tue May 30, 2017 1:10 am
Posts: 38
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?


Top
   
PostPosted: Wed Sep 02, 2020 7:22 pm 

Joined: Thu Sep 13, 2018 6:38 pm
Posts: 95
coredevel wrote:
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


Top
   
PostPosted: Wed Sep 02, 2020 8:07 pm 

Joined: Tue May 30, 2017 1:10 am
Posts: 38
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.


Top
   
PostPosted: Wed Sep 02, 2020 11:14 pm 

Joined: Thu Sep 13, 2018 6:38 pm
Posts: 95
coredevel wrote:
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...


Top
   
PostPosted: Thu Sep 03, 2020 1:19 am 

Joined: Tue May 30, 2017 1:10 am
Posts: 38
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.


Attachments:
Cessna172SP_LOD00_output.txt [265.44 KiB]
Downloaded 18 times
Top
   
PostPosted: Sat Sep 05, 2020 2:40 am 

Joined: Tue May 30, 2017 1:10 am
Posts: 38
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.


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 8 posts ] 

All times are UTC


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Powered by phpBB® Forum Software © phpBB Limited