FsX MDL format description

[arno]

I have put a page (http://www.fsdeveloper.com/wiki/index.php?title=FsX_MDL_format) on the Wiki that describes the FsX MDL format. It is certainly not complete yet, but it contains the parts that I understand now and which allow me to read simple scenery objects.

Hopefully it is also useful to others and if you know things not yet on the page, please feel free to update it.

[scruffyduck]

Thanks Arno :)

[theisomizer]

Hey Arno,

I just updated the wiki page with a bit of my knowledge. Don't expect much :D , but it beats nothing at all. I have been hacking the MDL format since FS2002 so I will try to add as much info as possible as I slowly learn the internals of the FSX format.

Cheers,
Sean

[Manuel Ambulo]

I have put a page on the Wiki that describes the FsX MDL format. It is certainly not complete yet, but it contains the parts that I understand now and which allow me to read simple scenery objects.

THANKS ARNO!!!, it is absolutly very GOOD NEWS!, had been searching for the new FSX MDL format, because some of my programs reads the old FS9 MDLs to get information for charts,...but now that FSX came out i cannt get this information....now im seeing some LIGHT AT THE END OF THE DARK TUNNEL lol :D....step by step ...:)


Hopefully it is also useful to others and if you know things not yet on the page, please feel free to update it.

ABSOLUTLY, usefull....hehe :D...AND THANKS AGAIN, Arno


Best Regards,

Manuel Ambulo

[arno]

I just updated the wiki page with a bit of my knowledge. Don't expect much :D , but it beats nothing at all. I have been hacking the MDL format since FS2002 so I will try to add as much info as possible as I slowly learn the internals of the FSX format.

Thanks Sean. Hopefully I can do some more tests with animated objects soon, so that I can update the relevant sections as I learn more.

[lc0277]

Thanks for the documentation Arno !

Concerning the differences between aircraft and scenery MDL, are we really ready to swap from one type to another ?
In aircraft.cfg files we can use the visual_model_guid command to use a library object instead of the providen mdl. I tried some objects from the default library ...

My first try was a total fsx crash. I think that it was because the object i used (arianne_bourget) was geo-locked.
The second try was successful (a F-22 raptor from the library). Of course it was not really flyable, and has incorrect contact points, no moving parts etc. But nothing that cannot be solved easily.

Another test with PPL_RussianVillain (735a6aeb-368a-4ae5-a4bc-bcb4f5b88626). No crash, but rendering is incorrect :
http://lc0277.nerim.net/screens/ppl.jpg
Doesn't really looks like a russian :rolleyes:

[arno]

It looks interesting indeed. I expect there are some sections of the MDL format that are only used by aircraft and not by scenery, but the fact that they seem interchangable is great news.

Also, I think the Russian villain I found a while back looks better (see screenshot) :D. I can't remember the GUID, but it was in the PPL section.

[lc0277]

The problem may be elsewhere. If I copy the MDL extracted from its library BGL to the aircraft directory, then it shows correctly. visual_model_guid does not seems to work for all models.

BTW some MDL files exists in both "aircraft" and "scenery" versions. For instance ANI_GiraffeWalk_Mature can be found in SimObjects/Animals and in scenery/global/animals.bgl. The files look barely identical, but there is a slight size difference.

[theisomizer]

Thanks Sean. Hopefully I can do some more tests with animated objects soon, so that I can update the relevant sections as I learn more.

Sweet. I'll be doing some tests with aircraft animations this weekend. Keep you posted.

Cheers,
Sean

[Manuel Ambulo]

Hi,

I have a little question of how to draw the 3D model, ehh...for example: if i want to draw a PART, in the wiki page says it has these parameters:

int (?)
int (?)
int material_index
int scene_ref (?)
int vertex_offset
int vertex_count
int index_offset
int index_count
int mouse_rectangle_ref (?)

Then, i get the index_offet and divide by 3 (index_offset / 3) then that gives me (the result) the index number of the triangle that i must get from the INDE section? (im correct? or i misunderstood it?..hehe). And also the index_count is the number of triangles needed to draw that part of the 3D model?...do i need to divide the index_count by 3 too? (i dont think so...but if im wrong then correct me)...

And another question, then the vertex_offet and vertex_count, how they are related or what role they play in the part's drawing?...(just asking if someone knows...if not...no problem..hehe)

i would appreciate if someone could tell me if im wrong or in the good way..hehehe...thanks again...

Best Regards,

Manuel Ambulo

NOTE: Sorry by my "rookie" questions...

[arno]

Hi Manual,

Yes, that is sort of how it works.

The index_offset will tell you where to start in the index list. If you count each triangle as three indices you have to divide the number by three to get the triangle count. If you just count each index as an integer, you can just use the value given.

The index count also has to be divided by three if you are counting the triangles. But if you are just counting the integers you can use the value given.

In the index list you will find the vertex numbers used by each triangle. This is were the vertex_offset comes in, as the vertex count usually starts at zero for each part. So to get the correct vertex you need to add the vertex_offset to the vertex number from the index list. Once you know the vertices it is rather easy to draw the triangle of course.

I don't know were the vertex_count is used. I guess you might need to know this when you want to extract the vertices from the list, but I did not use it in my code to render a MDL object.

I hope this makes it a bit clearer :).

[Manuel Ambulo]

Hi Manual,

Yes, that is sort of how it works.

The index_offset will tell you where to start in the index list. If you count each triangle as three indices you have to divide the number by three to get the triangle count. If you just count each index as an integer, you can just use the value given.

The index count also has to be divided by three if you are counting the triangles. But if you are just counting the integers you can use the value given.

In the index list you will find the vertex numbers used by each triangle. This is were the vertex_offset comes in, as the vertex count usually starts at zero for each part. So to get the correct vertex you need to add the vertex_offset to the vertex number from the index list. Once you know the vertices it is rather easy to draw the triangle of course.

I don't know were the vertex_count is used. I guess you might need to know this when you want to extract the vertices from the list, but I did not use it in my code to render a MDL object.

I hope this makes it a bit clearer .

THANKS...MANY THANKS...arno, yes, now i see more clearly how it works...i need to do some tests to see how i can draw the model, but i still have a little question, the TRAN section which contains the matrices, are they found in scenery 3D models MDLs files?, i mean, i know that back to the old format the matrices used to be declared just before the commands used for draw a specified part of an object, i dont know if here it applies the same thing, i mean if it is needed some transformation before drawing a part (of a SCENERY 3D model), or it is something that only appears in aircraft's MDL :confused: .....and i want to know if in the TRAN section there are multiple 4x4 matrices or there is only one 4x4 matrix?....sorry by my english...i hope you got what i meant, ...i mean...if the TRAN section can be also found in 3D scenery MDLs, or if it is only reserved for aircrafts MDLs?? :confused: ...

Best Regards,

Manuel Ambulo

[arno]

Hi Manual,

The simple scenery objects I looked at until now only have one transformation matrix in the TRAN section. So they are to be found in scenery objects as well. When using animations and probably also attachpoints I expect more transformation matrices to show up, but I have not yet studied those in detail.

[osman]

Hi,
I just looked to some mdl files which I extracted from land vehicles library, I will add one to this post. It has the usual sequence of sections. Within the MDLD section you find a LODT section at offset 0x23aa2, which in turn has 4 LODE sections with several PART sections ending at offset 0x23d6e. But the MDLD section does not end at that point, instead there is a SHAM section following covering the rest of the file. In that SHAM section there are again MATE, INDE , VERB etc sections ending again with LODT. Has anyone an idea what that could be ?? The name could suggest that it has something to do with drawing the shadow.

[arno]

Hi Winfried,

That sounds like a vary logical explaination. In the Fs2004 format non-default shadow models are stored in a similar way. I'll try to explore the MDL file you attached a bit more.

[theisomizer]

Ok folks,

As some of you might of guessed by now I'm a bit of a hacker... ok more than a bit (I almost became a CEH until I decided to go into the aviation industry).:D

So last night I was digging through another MDL file when I bulb lit up in my head and I thought 'Hey, why not look through xtomdl.exe instead?' So I ran through it and made some startling discoveries. The first of which I'll share with you now:

Attached is a list of ALL of the possible RIFF tags that can be found in a MDL file. Yes, all, No more, no less. Most of these will be unfamiliar to you so I'll try to get a description of each up on the wiki in the next few days.

Legal note - This type of hacking is NOT illegal, or at least in the United States anyways. Reverse engineering code for the sole purpose of program interoperability is legal. And that is exactly what I did.

Ok. please enjoy and feel free to edit/redistribute/add to it/feed it to your dog!

Sean

[arno]

Thanks, that is a nice starting point. There are quite a few new ones in that list indeed. Now we only have to find out what their relation is (as which one is nested in the other one) and what they actually do :).

[Stranger]

Hi guys,

I've updated some parts of FSX MDL Wiki document. The text file attached contains descriptions of most MDL signatures posted by theisomizer.

Actually I'm able to draw most of default objects although there still is a problem with static matrices in animated models. When applied, most (but not all) animated parts are positioned correctly except that they are alligned to different axis - 90 degress to non-animated as seen on attached images. Probably resolving of animation structure will bring more light on.

I see that the last post in this thread is more than a year old. Is there any progress? Is anybody still interested?

[=Hollywood=]

you guys just gave me an idea, thatwould likely make the guys at ACES laugh...

how hard would it be to turn an animated animal or human into a 'pilotable' mdl, and create an online session sometime ala people walking through the scenery lol...

[Marginal]

I'm able to draw most of default objects although there still is a problem with static matrices in animated models. When applied, most (but not all) animated parts are positioned correctly except that they are alligned to different axis - 90 degress to non-animated as seen on attached images. Probably resolving of animation structure will bring more light on.The SCEN structure describes a hierarchy of matrices that need to be multiplied together to form the final matrix for the part. The top matrix in the hierarchy is often a matrix that converts between left and right handed co-ordinate systems. It sounds like you're just applying a single matrix, instead of following the hierarchy, and so you're missing out on that top matrix.

Each SCEN entry consists of 4 16bit words:
(child, peer, offset of matrix in AMAP section, unknown - bone index?)
where child and peer point to other entries within the SCEN section. Sorry I haven't documented this on the wiki - I'm waiting to see how animations fit into this. But see the file FSXImport.py from here (http://www.fsdeveloper.com/forum/showthread.php?t=8298) for example code.

[Stranger]

Thanks for the answer!

Can we go through short example of actual data?


? Static
matrix
index
AMAP 0: 1 0
AMAP 1: 1 1
AMAP 2: 2 2
AMAP 3: 2 3
AMAP 4: 2 4
AMAP 5: 2 5
AMAP 6: 2 6


Child Peer AMAP
offset
SCEN 0: 1 -1 0 0
SCEN 1: 2 11 8 0
SCEN 2: -1 3 16 0
SCEN 3: -1 4 24 0
SCEN 4: -1 5 32 0
SCEN 5: 6 7 40 0
SCEN 6: -1 -1 48 0


Can you please explain the relationship of few entries?

AMAP offset is clear: AMAP_index = AMAP_offset / 8.

Does the first value of AMAP entry represents matrix index as well? Is it the coordinate system conversion you talked above?

What is the meaning of "child"? "Has child" or "is child of"?

What is a meaning of "peer"?

Hope I'm not overflowing you with questions.

Thank you

[Marginal]

AMAP offset is clear: AMAP_index = AMAP_offset / 8.Right.

Does the first value of AMAP entry represents matrix index as well?I don't know what the first entry in the AMAP table represents. The second entry is an index into the TRAN table of matrices.

What is the meaning of "child"?"has child"

What is a meaning of "peer"?"next sibling"


So, to take your example, looking at a part marked as using SCEN entry #1:
- SCEN[1].AMAP_offset = 8, so AMAP index = 8/8 = 1
- AMAP[1].static_index = 1, so use the matrix TRAN[1].
But SCEN[0].child=1, so SCEN entry #1 is a child of SCEN entry #0:
- SCEN[0].AMAP_offset = 0, so AMAP index = 0/8 = 0
- AMAP[0].static_index = 0, so multiply the existing matrix (TRAN[1]) by TRAN[0] to give the final matrix for this part.

Another example, this time looking at a part marked as using SCEN entry #3:
- SCEN[3].AMAP_offset = 24, so AMAP index = 24/8 = 3
- AMAP[3].static_index = 3, so use the matrix TRAN[3].
But SCEN[2].peer = 3, so SCEN entry #3 is a peer/sibling of SCEN entry #2. SCEN[1].child=2, so both SCEN entry #2 and its peer/sibling SCEN entry #3 are children of SCEN entry #1 (as also are SCEN entries #4 and #5):
- So, using the info from the previous example, the final matrix for this part is TRAN[3] * TRAN[1] * TRAN[0]

As you can see, the child and peer/sibling pointers are difficult to work with. In my code after reading in the SCEN table I compute a parent pointer for each entry. This makes it easier to work up through the hierarchy.

Hope I'm not overflowing you with questions.Not at all. The more people looking at this the more likely we are to work it out.

Disclaimer - this is all (informed) guesswork, and may be incorrect.

[Stranger]

Thank you for clarification!

I'll try to implement it in my code.

[Stranger]

That's it! All parts are in place. Thank you very much!

Now I've discovered that model is flipped right to left.
I also understand that to move control surfaces to neutral position the animation part have to be resolved. Am I right?

[Marginal]

Now I've discovered that model is flipped right to left.You may be using a different co-ordinate system - see "Co-ordinate Systems" in the "Modeling File Formats" section of the SDK.

I also understand that to move control surfaces to neutral position the animation part have to be resolved.I don't know, but I assume so.

[Stranger]

Well, here is the progress so far:

Right to left mirroring problem is solved by means of additional scale matrix applied to mesh:

-1 0 0 0
0 1 0 0
0 0 1 0
0 0 0 1

The animation format is fully decoded and looks much more familiar now. Haven't tried to apply any animation yet as I still have to dig the "Quaternion" interpolation subject, but the relationship between animations, streams, keyframes and particular parts is clear enough.