Jump to content
Hash, Inc. Forums
nemyax

MDL format details needed for exporter development

Recommended Posts

I'm considering doing a .mdl exporter for Wings. It might be based on Howard Trickey's old plugin, or it might be done from scratch.

I've recompiled Howard's plug against the latest Wings, but it crashes during export. And even if I manage to update it enough for it to work, the latest .mdl version it supports is 9.5.

I'd like some information about the current version of the format. Clearly, there's no official specification, but maybe there have been efforts to reverse engineer the format by people who have followed A:M's evolution.

Share this post


Link to post
Share on other sites

In v13 there was a switch to an XML-based fileformat... I am not sure what it was before, so it will very likely be not the same algorithm like the one needed for 9.5.

What maybe of great use for your explorations could be TROJER and the developement of it. Malo and his friend reverse engineered the fileformat for his OBJ-converter-program there.

(he is even using Wings3d for his examples)

 

More informations can be found here:

http://www.hash.com/forums/index.php?showtopic=40419

 

You can contact Malo here:

http://www.hash.com/forums/index.php?showuser=537

Share this post


Link to post
Share on other sites

Hello,

Sorry if my English is not always understandable, I'm not English speaker.

Here are some pictures with information on the format of AM: Feel free to ask questions on points that are not clear.

01-AM.jpg

02-AM.jpg

03-AM.jpg

 

 

05-AM.jpg

06-AM.jpg

 

07-AM.jpg

08-AM.jpg

09-AM.jpg

10-AM.jpg

Share this post


Link to post
Share on other sites

Thanks a lot!

Do you know the meaning of the bits in the spline element's bit field (the first integer: 262145 etc.)?

Share this post


Link to post
Share on other sites

And even if I manage to update it enough for it to work, the latest .mdl version it supports is 9.5.

I'll note that current versions of A:M are supposed to be able to correctly load MDL files from anything back to version 5.

 

If the old MDL plugin for Wings could be made to create a v9.5 MDL without crashing, that ought to be good enough to get a model into A:M.

Share this post


Link to post
Share on other sites

No unfortunately I did not understand this numbers. :(

 

So in Troer I only used 262145 and 262149.

Prior to version 17, AM corrected its figures when the model converted was imported in a window's model. Now it's no longer the case.

 

 

Share this post


Link to post
Share on other sites
If the old MDL plugin for Wings could be made to create a v9.5 MDL without crashing, that ought to be good enough to get a model into A:M.

If anything, that would be a start. I'll see what I can do.

Share this post


Link to post
Share on other sites

I just did a quick test and I notice that If I peak a CP its number changes from 262145 to 262144.

 

If I unpeak it the number changes back to 262145

Share this post


Link to post
Share on other sites

I also notice that "locked" CPs get the number 262657

Share this post


Link to post
Share on other sites

A CP that I switched to "Perpendicular Normals" gets a single digit 1 instead of the 6-digit number.

 

If I set it back to "biased Normals" it reverts to 262145

Share this post


Link to post
Share on other sites

The comments in Howard's code state the meaning of three bytes:

 


-define(CP_SMOOTH, 1).
-define(CP_CLOSED, 4).
-define(CP_HOOK, 16).

 

There's also this:

 


% let A:M compute regular patches

 

By regular I presume he means quads and tris, as opposed to fivers. If the plugin offloads patch building to A:M, does that mean there cannot possibly be any UV data? If so, the exporter is near worthless, because half the reason you'd want a direct Wings–A:M link is the UV layout.

Share this post


Link to post
Share on other sites

UV data... that is all beyond me but some comparative analysis of simple cases get you what you need to add to his previous work.

Share this post


Link to post
Share on other sites

Gradually the format going to give his secrets :)

 

Just out of curiosity, what are the functions you want to import that does not exist in the import Obj AM? Because to my knowledge, What Howard Trickey's old plugin does, AM's obj import plugin does it today.

Share this post


Link to post
Share on other sites

In Troer I could import the Uvs patches 5 sides.

They do not seem to me that the Uv are linked to this numbers before the splines.

But if the patches are bad writing, they can lose their Uvs.

Share this post


Link to post
Share on other sites

what are the functions you want to import that does not exist in the import Obj AM?

I want an exporter that preserves three things:

  • Edge/spline flow (none of this )( where this X is supposed to be)
  • Five-pointers
  • UV layout

I've tried A:M's OBJ import, and it doesn't cut it. Looks like the exporter needs to be done from scratch.

Share this post


Link to post
Share on other sites

Here is a PHP script that converts a UV .obj in UV * mdl

If this can help you

treser.net/AnimationMaster/UV/PHP UV.zip

Share this post


Link to post
Share on other sites

Ok, for me the big problem you will found is the spline flow.

With Troer, I decided to accept only some cases of figures.

 

But with hooks, it will be possible to import more case of figures.

A another way is to modify the model as this topic : http://www.hash.com/forums/index.php?showtopic=45564

But the map must be cut and redraw. (it is possible but I don't know how hard it is to programm this).

Share this post


Link to post
Share on other sites

Those are bit fields:

262145 = 0000 0000 0000 0100 0000 0000 0000 0001

262144 = 0000 0000 0000 0100 0000 0000 0000 0000

262657 = 0000 0000 0000 0100 0000 0010 0000 0001

Share this post


Link to post
Share on other sites

Can we presume that many of those bits are currently unused placeholders?

Share this post


Link to post
Share on other sites

for me the big problem you will found is the spline flow

Judging by your diagrams, it doesn't look insurmountable. Surely it creates some interesting problems such as keeping track of which vertices are fused rather than single CPs or deciding what goes which way at a non-cross-shaped intersection, but that's all doable.

Share this post


Link to post
Share on other sites

I found an another pdf for exlain how UV calcul is made in Troer :
http://treser.net/AMStudio/doo/uv/uv.pdf

I don't know what is the first number of the patches.
But If it help you, in Troer i use only 21 or 41(for Five-pointers)


24 2 6 4 2 2 6 4 2 0

24 10 22 21 9 10 22 21 9 0

41 3 14 13 9 8 3 14 13 9 8

I think, if you know what is this number, you found a way to draw correctly the patches in AM.

Share this post


Link to post
Share on other sites

I've changed my mind about the Wings plug. Instead, I've started on a .mdl export addon for Blender. I believe it will complement the middleman addon nicely.

Share this post


Link to post
Share on other sites

Good idea!... Have you an idea of the way you will do it? Export an high subdivision or a low subdivision, with textures, bones...?

 

I have try some bridges from AM to Blender, but helas, I have not your talent for programming, but perhaps It can help you :

https://www.hash.com/forums/index.php?showtopic=46571&hl=

A little htlm5 program (make with construct2) to correct lowObj Obj exported from AM, before imported it in Blender(without use Wings3D) : http://treser.net/AMStudio/AMStudio2014/Obj2Obj.zip

 

(Sorry for my english)

Share this post


Link to post
Share on other sites

Have you an idea of the way you will do it?

 

Yes, it's quite straightforward. CPs are represented well enough by polygon edges. And everything references everything else in Blender's bmesh. Add a layer of directional information, and you're laughing.

 

 

 

Export an high subdivision or a low subdivision, with textures, bones...?

 

At this time, I'm only targeting spline cages, patches and UVs. The mesh can be as dense as you want to make it in Blender.

 

Thanks for the links!

Share this post


Link to post
Share on other sites

Malo

Did you figure out what to put in the section? The normals listed there don't seem to be referenced from anywhere in the file.

Share this post


Link to post
Share on other sites

The normals in a mdl format.

is writing in the patches as this :


808 16 19 18 16 X X X X 0

 

the last numbers ( where i write "X" for the example) are the number of the lines of the

a number for each CPs of the patches

 

For example if the patches is writing as this :

 

X X X X X 2 4 1 3 X

The normal for the first CP is the second line of the section

The normal for the second CP is the fourth line of the section

The normal for the third CP is the first line of the section

The normal for the fourth CP is the third line of the section

Share this post


Link to post
Share on other sites

Great, thanks.

Got the spline export partially working: not all CPs are fused properly. Patches and UVs are still broken, and I had to remove the related parts from the .mdl to prevent A:M from leaking memory.

400_8acf3781d4f1b22642421e170b4adb04.png

Share this post


Link to post
Share on other sites
X X X X X 2 4 1 3 X

The normal for the first CP is the second line of the section

The normal for the second CP is the fourth line of the section

The normal for the third CP is the first line of the section

The normal for the fourth CP is the third line of the section

 

Did you mean "X X X X X 1 3 0 2 X"? Because I'm seeing 0-based arrays in my .mdls.

Share this post


Link to post
Share on other sites

I'm finally getting the correct topology. Still no patches or UVs though. One down, two to go.

 

400_cd50266d83d1c02cbe1c5fecae6e7485.png

Share this post


Link to post
Share on other sites

Malo

Is there a special rule for specifying patch CV and texture coordinate indexes? I'm simply listing four associated CV indexes for each patch, but A:M ignores that. The stamp comes out empty, and the five-pointers aren't filled in.

Share this post


Link to post
Share on other sites

I have to go to work... I will take a see In the format again this night.

But have you try to open your mdl model with an older AM (before V17.... ) Because before V17, AM corrected the bad patches.

Have you try to open your model via "import" in a window's model to see if you have the same result?

Share this post


Link to post
Share on other sites

If you want, you could send me a simple MDL model converted with your converter, I will study what is wrong in the UV and patches.

Share this post


Link to post
Share on other sites

I'm still in the dark about the correct ordering of CPs in patches and in UV data. When I get it right for a special case, it turns out broken for other cases.

The SDK documentation has a link (ftp://ftp.hash.com/pub/Sdk/AMSDKDoc/spline.pdf) to a document that supposedly describes Hash patches in detail, but that link is dead. Does anyone have this document? I believe it would be a great help.

Share this post


Link to post
Share on other sites

Thanks, Fuchur, but unfortunately, the PDF wasn't much use.

I think the bitfield at the start of each patch entry is the main clue, but I can't work out the meanings of the bits. Could someone experienced with the SDK share what they know or think? It doesn't look like the bitfield follows the order of the patch flags defined in HPatch.h, but it obviously has to do with these flags.

If anyone is interested, I've uploaded a stripped-down version of the exporter without the patch-related experimentation. Get it here: https://drive.google.com/file/d/0B___ge5IO2JdcG9DSEQtLU1LU2c/view?usp=sharing

Share this post


Link to post
Share on other sites

Nice work nemyax! :)

Good idea to continue splines, where the links problems is.

The calculation is fast it's really good!

Thank for your work!

I would like to help you to found the bitfield, but I stopped there my understanding of the format. :(

Share this post


Link to post
Share on other sites

Thanks, Malo.

 

I stopped there my understanding of the format.

But you do create valid UV-mapped patches!

Share this post


Link to post
Share on other sites

Hi nemyax,

 

I think I understand some of the bitfield .
this explanation of the bitfield is for patches with 4 sides (or 3 sides, because in reality it is a 4-sided patches )
To understand this, we must know that there is a direction for each splines.
spline.png
Imagine that the patch consists of 4 splines that rotate counterclockwise around point ABCD .
orientation.png
Imagine that the black arrow rotates in the counterclockwise direction, and green clockwise on this picture.
Imagine that AB BC CD DA have as bitfield 8, 16, 32, 64 :
ar4.png


Imagine that you can combine them.:
24.png

All the combination between 0 and 120 :
hollad.png

For 5 patches it is the bitfield + 1, but I have to go deeper.

Share this post


Link to post
Share on other sites

Thanks a million, Malo!

This observation makes a lot of sense, and it gives some meaning to the SDK's HPatch::IsFlip1()HPatch::IsFlip4() flags. Luckily, the script handles "directed" edges anyway, so this should be cheap to fix, at least for 3- and 4-pointers.

Share this post


Link to post
Share on other sites

Happy that help you.

Note that this only works if you follow the orientation and that we take the CP of the new spline at each crossing.

niverennadur.png

If you write : X 1 2 5 7, the bitfield will be different.

 

Here are some of the code for the patches to 5 sides (same note for the patches with 4 sides, follow the orientation and take the CP of the new spline at each crossing ):

Pemp.png

Hooks is different... but I have not find yet the explication.

Share this post


Link to post
Share on other sites

I have not study the UV yet... but no, it is not the same Cps. I will see that and give the solution.

Share this post


Link to post
Share on other sites

It seem to be that : when the coordinates of Cps are written in the splines, there are two kind of CPs: those that are tied and those that wear the coordinates. For Uvs, you must only use the CPs that wear the coordinates.

Share this post


Link to post
Share on other sites

for writing patches :

If you follow the orientation and take the CP of the new spline at each crossing the bitfield is = the bitfield

if you use any CPs of each spline... the bitfield is = ( bitfield+ 5)

Share this post


Link to post
Share on other sites

Malo

Your advice has been indispensable. Now the only thing left to fix is the UVs on five-pointers.

 

300_afa7c2c530d20c27b57e181b9a35bc74.png

Share this post


Link to post
Share on other sites

Waow... nice result, nemyax.

Could you send me a simple example converted with your converter, I will try to see what is the problem with the UVs on five-pointers.

Share this post


Link to post
Share on other sites

Thank for the models.

 

I'm not 100% sure of the solution, but it seems it is necessary to indicate the opening of the patches.
The patches with 5 pointers are written with 5 CPS (but indicates with four segments in the bitfield)
For UVs, there is 4 CPs, but you have to indicate which are in the segment that are not indicated in the bitfield.
here EA

uv5.png

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


×
×
  • Create New...