2010-08-30, 09:30 PM
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.
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.