A .MDL exporter

[Holy_Diver]

Here (attached) is a new tool for working with .MDL files. It's called x2mdl basically in the spirit of the x2mdo tool that From' released. X2mdo converts .x files to .mdo files from what I understand, and that's what x2mdl does. However you can also try other types of files in place of .x. If that format includes all the features a MDL file requires and is supported by the Assimp library it will also work. If it doesn't include all of the features it will still probably net you a static graphic but might not be useful for animation etc.

As is I think you could get started making new doors and treasure chests etc, and even NPCs and monsters. However Som has two different kinds of animations, and only one kind is supported right now. With the supported kind you can make wooden puppets basically, like most of Som's NPCs but not make one piece rag doll puppets, slugs etc. The animation method you choose must also reflect that or the Assimp library will interpret the animations as the wrong kind and they won't be exportable (yet)

In this release textures will be converted to 16bit and be down sampled to 256x256 if necessary. Afaik as far as we know this is as good as any existing .MDL files, but it may be the format can do better. Just need to setup some experiments.

X2mdl only facilitates .mdl files... you will have to figure out the .prf files and others for yourselves. In some cases you can just overwrite the string of characters in the .prf file that stores the name of the mdo/mdl file. Edited: also I still have to develop another app for generating .cp files (more about that later...)

When you name your animations there are 3 ways x2mdl will recognize them. If the last letter is a closing parenthesis, x2mdl will look backwards for the first opening parenthesis, and if that is followed by the # character, the next characters must be the number, eg. Walking (#1) ...otherwise, the first character must be a number, eg. 1 ...otherwise the actual order of the animations will be used, so first animation is 0, the next is 1, and the next is 2, and so on. If your file format of choice does not let you name animations in any way, you will have to somehow make dummy animations to fill in the animation IDs you don't want/need.

Below is a list of animation IDs used by Som:

if(id<2)
{
switch(id)
{
case 0: set = "Idle (default)"; break;
case 1: set = "Walking (#1)"; break;
}
}
else if(anims<5) //! guessing object
{
switch(id)
{
case 4: set = "Opening (#4)"; break;
case 5: set = "Closing (#5)"; break;
}
}
else if(anims<12) //! guessing enemy
{
switch(id)
{
case 4: ‎ set = "Dying (#4)"; ‎  ‎  ‎ break;
case 6: ‎ set = "Evading (#6)"; ‎  ‎ break;
case 9: ‎ set = "Trigger (#9)"; ‎  ‎ break;
case 10: set = "Attack A (#10)"; ‎ break;
case 11: set = "Attack B (#11)"; ‎ break;
case 12: set = "Attack C (#12)"; ‎ break;
case 13: set = "Attack D (#13)"; ‎ break;
case 14: set = "Attack E (#14)"; ‎ break;
case 15: set = "Attack F (#15)"; ‎ break;
case 16: set = "Defending (#16)"; break;
case 20: set = "Hitting (#20)"; ‎  break;
}
}
else switch(id) //! guessing npc
{
case 2: ‎ set = "Hitting (#2)"; ‎  ‎  ‎  ‎  ‎ break;
case 3: ‎ set = "Dying (#3)"; ‎  ‎  ‎  ‎  ‎  ‎ break;
case 4: ‎ set = "To Left (#4)"; ‎  ‎  ‎  ‎  ‎ break;
case 5: ‎ set = "To Right (#5)"; ‎  ‎  ‎  ‎  break;
case 6: ‎ set = "To Face (#6)"; ‎  ‎  ‎  ‎  ‎ break;
case 16: set = "Seated (#16)"; ‎  ‎  ‎  ‎  ‎ break;
case 17: set = "Standing (#17)"; ‎  ‎  ‎  ‎ break;
case 18: set = "Hitting Seated (#18)"; ‎ break;
case 19: set = "Dying Seated (#19)"; ‎  ‎ break;
case 20: set = "To Left Seated (#20)"; ‎ break;
case 21: set = "To Right Seated (#21)"; break;
case 22: set = "To Face Seated (#22)"; ‎ break;
}

If you want to replace the arm, animation IDs 0, 1, and 2 are used for each swing animation, not sure which is which.

Control points are supported by x2mdl, but x2mdl won't generate the .cp file. In order to create a control point your format needs to support per vertex or per triangle colours. Setting the material won't do. Any triangle that is the same colour on all vertices and that colour is not pure white will be treated as a control point. I'm assuming pure white means the equivalent of no coloration... if that is not so for your format I will add an option to specify what is the neutral colour.

If your model has no control points, and you're impatient, then you can probably get it in game by using the wooden treasure chest's .cp file.

Beyond the scope of the .mdl file I don't really understand control points myself at this point. I'm assuming they are referenced by number in the .prf file. For example a control point at the tip of a sword damages the player when it touches the player during an attack and might be the point where a magic spell originates for example.

The way the program works is very simple at this point. And there are few frills in the case that something goes wrong. Just drop a file on top of it, and if it works it will make a file of the same name with .mdl appended to the end. Alternatively you can evoke the program via a command prompt and pass along the name of the input file as the only argument.

It's a standalone application, but requires Direct3D 9 and the D3DX9 libraries to be installed on the system. The kinds of external images supported are currently limited to the ones supported by the D3DX9 interfaces (.bmp, .dds, .dib, .hdr, .jpg, .pfm, .png, .ppm, and .tga)

[Holy_Diver]

Bad News:

The maximum MDL texture size appears to be 256x256. There's still a possibility a 512x512 mode may be discovered, but this seems pretty conclusive. Kind of expected / easy to work around.

Worse News:

Som does not appear to support the 24bit TIM mode. Therefore all MDL files are limited to 16bit color... or technically 15bit. I understand the TXR files may be 24bit. But I gotta advise not using all 24bits if you want your art to be consistent, because afaik MDL files are necessary because MDO don't seem to ever be used where animation is involved.

On the upside:

If you need better than 15bits it shouldn't be too much trouble for Ex to replace Som's textures on the fly with whatever you have.

EDITED: Assuming 24bit is even possible with TXR files. You might consider doing items and details in 24bit. Because items appear in closeup in the menu and might not hurt to make them stand out. And details like a painting and other curios for example might benefit from the extra depth without appearing out of place.

[Verdite]

Fantastic news. I am really pleased to read about this... Ill test it when i can. Really, thank you. ‎ 

[Holy_Diver]

Without a proper .cp file you should be able to craft doors and treasure chests for yourself (as in with the tools at hand) ... that might be a good way to familiarize yourself with how things work. I think doors somehow use control points to push players/monsters out of the way of the opening/closing door but you can still get an idea of how things work. And once the cps are supported you'll still be left on your own (for now) to figure out how the .prf files interact with them (eg. in the case of the door cps)

I think if a file does not have control points Som assumes at least one at (0,0,0) which defines the resting position of the object. So it should be possible to make non-walking NPCs also if you want to try your hand at character animations. I hope to have th cp program (cpgen.exe) ready within maybe a week or two (conservative estimates)

There is a lot to take into consideration. For starters with a chest/door you will want the 4 and 5 animations setup. You may try leaving out the closing animation to see what happens if you don't want it to ever close (it may just play the open animation again though the next time it's examined)

You might also try monkeying with the arm animations. It might very well be possible to add new arm animations and set some field in the weapon .prf file to that number to get a new kind of weapon swing.

The first frame of the animation is not used by Som. It's really just the starting pose / initial state, which usually includes a lot more info than the proceeding frames. I'm not positive about timing, but working with the skeleton mdl file the framerate appears to be 15 frames per second. I'm pretty sure the games run at around 30fps but I'm not positive. I don't think (but I'm just guessing really) that the in game time in in sync with the fps. Furthermore Todd informed me yesterday that you can speedup and slow down the animations arbitrarily with the .prf files, which is pretty interesting in itself, but also means that the framerate of the files is either not necessarily fixed in time or between files...

All that said the x2mdl exporter and the Assimp importer are synced at 15fps for the time being. Which brings me to the important point. If you have a 2 second animation thats 30 frames plus the 1 start frame. If you can start the first frame at a negative time I recommend that if it works out, otherwise your animation will need to be one frame longer. It's possible the importer might discard a negative time keyframe so be wary of that also. Either way x2mdl will subtract one frame from the top of the animation and use it as the setup frame. I'm assuming your modeling suites work in terms of frames because talking about seconds gets into "real" numbers which are technically impossible to specify exactly.

The frames are not interpolated by Som. Which can be a little choppy but also gives you a lot of freedom... like the skeleton's death animation with interpolation would not look right at all. This complicates some things however when preparing your files. Like a simple chest opening can be done with one or two key frames with interpolation between, and it's safe to do it that way, but in the end the animation will be discretized and if your animation is interpolated how it gets sampled may not be as you intended. Ideally if you can somehow prepare a keyframe for every frame of animation on the top of the frame that will get you best results. Ideally at 15fps (+1) ... if you want more frames I recommend doubling the duration of the animation and using 30fps then throttling it in the prf file to get what you want. If you want less than a second interval try to cut it off at a division of 15.

Edited: your animations will probably look smoother at 30fps because that better matches the game fps. So you'll get one frame per game frame. Which is pretty harmless for this kind of animation. For the other animation type each frame potentially changes every vertex in the model, so real-time frame rates might be more difficult to achieve within the amount of space alloted to animation data.

I'm going to try to update my checkout of the Assimp codebase sometime today and prepare an uptodate as possible build of the Assimpview tool with some tweaks for Som files like the one I posted in the other thread.

The main reason the other kind of animation is slower coming is not because I don't understand it, but because when I started Assimp did not support that kind of animation. Support is slowly developing but I will probably have to take time out myself to complete the task on behalf of the Assimp library. In theory I could add support for most everything without the support of Assimp, but in reality I want to confirm my implementation of the MDL format is correct, and the most straight forward way to do that is to amend Assimp first.

[Holy_Diver]

Here is a (new) modified version of Assimp_view.exe. I will try to upload this somewhere eventually.

I will shortly replace the x2mdl.exe attachment in the first post with a version built from a current snapshot of Assimp. I think the next release will also look for the the Assimp32.dll on your computer and use that instead if found (maybe only if the version is newer -- headers permitting) so you can just download that occasionally from the Assimp website to stay current.

EDITED: Try to avoid clicking the checkboxes in the bottom area of the viewer if you can. There seems to be a nasty bug that will more or less permanently screw up the settings. It's kind of out of my hands. If it's fixed I will upload a new build.

UPDATE: I'm told this bug is now fixed. Will post something when I can get a new attachment up.

UPDATE: Somimp_view.exe download moved to top post.

[Holy_Diver]

Just one more subroutine to implement before the .cp tool should be ready to see some action. All and all this stuff has been really a lot of work, and it's only about 50% there without both animation types (and could probably use about another 50% in the optimization dept)

[Holy_Diver]

After a marathon (Velvet Underground fueled) all night debugging session cpgen.exe is here as promised (released to no fanfare as usual)

PS: If you want to replicate a MDL file so it matches up with it's prf file cpgen has a log feature but you'll probably only see it if you run it from the command prompt. It will tell you what controlpoints are in the file, their colour, and where they are at in the model coordinates. All you really gotta do is match up the colour/number and I think cpgen is programmed correctly to manage the rest. The coordinates are so you can visually match up the control points. The only way to see the control points is with the Assimp viewer app. They are generally but not always invisible in the Som tools.

I regret Assimp does not have a single exporter to its name (yet) but you should (at long last) have all you need now to make original animated assets (in plain English)

UPDATE: The latest cpgen build is now and for ever attached to the top post.

[Verdite]

Ill try to test all this tonight... Just one thing id like to ask. Does the editor come with script editing for animations? Or do you have to edit it externally.

[Verdite]

x2mdl crashes each time i drop a file on it or use the cmd line.

i'm dropping an x file of 500+kb onto it and it crashes. cpgen also crashes when i drop an x file onto it.

[Holy_Diver]

Cpgen should not have any external dependencies so its unlikely its crashing. Are you dropping a .mdl file on it? If you don't give it a valid .mdl file as input it will not do anything.

Can you describe "crash"? Because it's normal for a command line app to just popup and disappear in the blink of an eye (especially if not on the command line) ...Unless you here are beep and see a dialog box it probably did not do anything unexpected. There isn't any error reporting to speak of yet, so if it runs in to trouble you probably won't hear about it.

If cpgen works there will be a .cp file created in the directory of the file you drop on it (with the same name) ...so don't drop a .mdl file from your data/game folders on it or the original .cp file will get overwritten.

If you use the .mdl files spit out by x2mdl exclusively it just tacks on .mdl to the file name so you shouldn't confuse it with original files.

As for x2mdl, it may crash in an unfriendly way if you don't have the right Direct3D 9 and D3DX9 libraries on your computer.

X2mdl is the same deal. Drop a .x file or other kinds of graphics files onto it and it should produce a .mdl file.


These are very straight forward non-graphical tools. I don't intend for them to be the last word on the subject, but they will have to do the job for the time being. If you're using them correctly I just can't imagine them not working. But please please help me debug them for you if they're not working on your end.