A .MDL exporter

[Verdite]

Quickly tried your cpgen, i tried dropping an existing som mdl onto it and nothing happened. I basically dropped one existing som mdl file onto the cpgen and the cmd box came up and closed without any error report etc.

[Holy_Diver]

^There should then be a .cp file in the same folder as the file that was dropped.

[Verdite]

Got both of your programmes to work (it must have been my drivers on my old machine.)
Found the cp file for the som mdl. (How do you edit anims btw?)
Made my model to test, though in the preview screen the mdl was flipped strangely. I tried to give the mdl a cp of its own but i couldnt... I tried placing the mdl file on the cp gen and i didnt get a cp file. So instead i simply copied and renamed an existing cp to match the mdl file name. (Without the cp som crashed often. Duh  )

I got the model in game but because it was flipped only its feet were showing (i dropped it from a height to see what would happen - nasty i know!)

Anyway i jumped off the map to see what was going on, and the model was there.

Ill flip the model 180 next to see what happens.

[Verdite]

Flipped the model and only the top of the model was visible, and stuck in the floor again.

Btw... The dwarf.x file, could you get it to work? I dl'ed the dwarf and the textures. Something i noticed is that the textures are jpg and 512x512... I didnt know som could output textures that were jpg and higher than 256.

Regardless i couldnt get the dwarf to work. I just got this error...


: Load C:\tools\dwarf.x
: Found a matching importer for this file format
: Import root directory is 'C:\tools\'
: Entering post processing pipeline
: JoinVerticesProcess finished | Verts in: 5688 out: 1519 | ~73.3%
: Leaving post processing pipeline

[Verdite]

Got it to work. When the model was flipped i moved it to the other side of the horizontal grid in metaseq.

The model wasnt animated though, it seemed to move like it was pushed. It also wouldnt attack eventhough i set the data to attack in the parameter editor.

[Holy_Diver]

: Load C:\tools\dwarf.x
: Found a matching importer for this file format
: Import root directory is 'C:\tools\'
: Entering post processing pipeline
: JoinVerticesProcess finished | Verts in: 5688 out: 1519 | ~73.3%
: Leaving post processing pipeline

That's normal output. There's no error unless the output says there was an error.

If the textures are larger than 256 they are downsampled so to fit into 256x256.

In order for the animations to work... A) they must actually be present when you open the model in the viewer tool (meaning they were successfully imported) ... B) they must not require "soft" animation (not yet supported) ie. each moving part must be a solid "mesh" -- eg. think Tin Man, not Scarecrow ... C) They must be named to match the traditional Som animation IDs, or must at least correspond to the .prf file. I explained how to do that probably near the top of this thread.

Don't give up and you'll figure it out. I can't tell if your model there is one piece or not. If it is you won't be able to animate it as such just yet. I do plan on very much supporting "soft" animation asap. Once you're as good with the tools as you are Meta' and x2mdo etc, you could really help others by writing a guide "for dummies" (no offense) ... I've wasted enough time trying to write such guides in the past I know that I'm no good for it.

PS: I can't help with attacking. The .mdl and .cp file only deal with animating the model and the control points. I suggest choosing an asset (which came with Som) that is close to what you want to do, and just use its .prf file while changing the .mdl/.cp file. Your control points will need to be of the same type/quantity, and it will be limited to whatever the asset you chose can do, but you're free to model it however you want and move the control points about as you please. If you want more than that Todd might be able to help in the .prf dept. It's something I haven't looked at so far.

If you think you've done all that you can and fulfilled all these requirements, and things still don't work, send me a copy of your files and I will see where things are not working / if x2mdl needs some work. Afaik x2mdl/cpgen works with all of the "Tin Man" .mdl files that come with Som to produce functionally identical files.

[Holy_Diver]

I'm not sure btw why your mdl file is not standing flush with the floor. I believe for Tin Man mdl files the ones that come with Som all use (0,0,0) for the root control point. So make sure (0,0,0) is floor level and between your models feet. The "Scarecrow" models use a cyan control point for their root. You may be able to include a cyan control point in a Tin Man mdl file to use a root other than (0,0,0) ... I don't know if there is an advantage to that or not.

Otherwise you'll need to figure out what direction is up etc for the file format you're using. It may not be consistent... x2mdl is dependent upon the Assimp importers. I'm assuming the importers won't recenter your model, though I suppose it's possible. If that's so you can try either inserting a cyan control point. If that doesn't work I'll add something to x2mdl to detect a cyan control point / reorient stuff around it (I think I'm just trying to cover all my bases here ... it's not likely to be a problem)

PS: Cyan is (0,255,255) ... fully saturated green and blue. Read about control point colour coding somewhere near the top of this thread (I'm thinking) ... btw we'll probably need to try some stuff out for control points colouring. Presently x2mdl only recognizes per vertex colour in order to distinguish the colour of cps. In other words using a red material/texture isn't good enough. I don't know if Meta' supports per vertex colour or not. I could add support for material properties, but not textures. Still per vertex is best. Let me know. Any vertex that is not pure white colour wise is considered to make up a control point.