Talk:X2mdl/a guide by Wolf

needed changes and thoughts

Here is a growing list of changes just to keep things factual.

• Can't do stuff, needs to be rephrased as "cannot YET do" or there needs to be a third section (if there are indeed things x2mdl is not meant to do) ie. handling all types of animations is technically possible via the MDL format, though some cases might require a loss in terms of fidelity.
• The thing about not using more than one bmp is not accurate. You can have at least four 256x256 TIM images in a MDL file. x2mdl has always been able to do more than one. Possibly many more than four for smaller images, depending on how accurately the format replicates the PSOne frame buffer or whatever it's called(I don't recall running any tests)
• Technically we don't know if the animation ids are just conventions or what. All we can say for sure is these are the ids Som files traditionally use. The ultimate call in terms of what does what might be made by the PRF files. I've been told before by others they think this is probably the case. Don't know anything about PRFs yet myself.
• Please phrase stuff in terms of what we know. Wiki's are not places for speculation. Ie. what 4 and 5 does for traps. We don't know unless you tried. Generally though for each class of assets, the ids are totally different. Ie. NPCs and enemies don't necessarily share IDs even though many IDs server the same function. And like I said, it may be entirely a PRF thing. Also there may be stuff implemented that we don't even know about / just never happened to be used by the stuff on the disc. Experimentation is called for.

• I've not really read thru the "The Process:" section. But it needs to be framed in terms of a "tried and true" example of what you can do, rather than a one size fits all guide.

• Truth is we're going to have to give some thought in terms of how to organize this wiki. It's totally different functionality wise from any wiki I've ever seen/worked with.

In general for example I think Tinman animation would be a good BAD place for the animation ID info and an explanation of what exactly it is. X2mdl would be a good page for what x2mdl's function is and its history. I'm seriously considering using / pages for this wiki. I think at the least I want to mirror the VCS at som.net, so like Pool/look/new/rm_som_000.mdo could be used by an artist to make a page about an asset they've created whenever they feel like it. My gut tells me X2mdl / examples might be a good page for examples. Then it could get turned into a directory if it got too big.

If pages are categorized and linked via "See also" sections, they're pretty easy to find.

Anyway, good job. This page reminds me the headlines need to stand out more... and I'm really not pleased with the paragraph/line spacing.--Holy Diver 01:13, 9 March 2011 (CST)

Nvm on animation IDs. Those are shared by Tinman and Scarecrow. Organizing stuff is going to be tough I'm afraid. Probably MDL (file format) would be the place to look normally. I think maybe the page I'm working on there should be somewhere else. But usually it's best to keep info together unless it gets too long or confusing section layout wise.--Holy Diver 01:47, 9 March 2011 (CST)

list of stuff wrong with x2mdl

@Wolf, I know you've requested a number of changes be made to x2mdl. I was hoping you could just prepare a list either here, or in the page. Just to be sure I don't miss anything next release. I will probably release some stuff after I'm able to relax the Tinman requirements via an Assimp post process that will strip out bogus skin/bone weight data. I expect to start work on that before the end of next week. And expect to finish it before moving onto anything else. So that would be a good time to work in any reasonable corrections.--Holy Diver 03:40, 9 March 2011 (CST)

Here's what I can think of, most beneficial listed first:

*the conversion process seems to have several irregularities. I don't know if the input file, assimp, or x2mdl is the culprit, but the first key-frame in an animation is being set as a 'default pose' which only shows up in the Parameter Editor's preview window. In that 'default pose' x2mdl moves all the objects in the model to a 'stand at center' position which makes the model look messed up. Also, x2mdl keeps the 'default pose' upright, but flips the actual animation on its side. Therefore, if you place an MDL upright in the map editor, it will be flipped sideways in game. Makes it almost impossible to line things up properly.

*Increase compatibility with standard model formats ie Relax the Tinman requirements

*Fix the broken drag-and-drop support.

*Automatically add '01' or '00'(for non-animated) to $00.

* Add support for clipping one long animation into multiple sets, and/or joining multiple sets into one multi-set model.

*Fix the Enemy animation set #s (in Somimp):

• 6 = Currently "Evading" - should be "Defending"
• 7 = Currently "Unassigned" - should be "Evading" aka "Avoiding"
• 13 = Currently "Attack D"- should be "Unassigned"
• 14 = Currently "Attack E"- should be "Unassigned"
• 15 = Currently "Attack F" - should be "Attack D" aka "1st Indirect attack"
• 16 = Currently "Defending" - should be "Attack E" aka "2nd Indirect attack"
• 17 = Currently "Unassigned" - should be "Attack F" aka "3rd Indirect attack"
• 20 = Currently "Hitting" - should be "Getting hit"

the recipe seems prohibitively work intensive

Surely there's a better way o_O --Holy Diver 05:43, 9 March 2011 (CST)