Sword of Moonlight > Help

x2mdl/x2mm3d download (2021)

<< < (2/5) > >>

Holey Moley:
Important bug fix

(http://www.swordofmoonlight.net/holy/x2mdl.zip)

Details: I've fixed an x2mm3d conversion bug for sparse keyframes (i.e. the animation freezes for at least one frame.) I'm glad I found this sooner than later.

Holey Moley:
Two Fixes

(http://www.swordofmoonlight.net/holy/x2mdl.zip)

I've added a note to the first post (OP) but I will try to explain more here now (read the note first.)

Yesterday I spotted a problem with large deltas in the 60 fps upscale extension to SOM's player. This kicks in because it's hard to say if large delta's should be averaged or if they are "teleporting" to a new position. It turned out I'd inadvertently put the teleport on the wrong frame (of the two) and somehow that made a difference visually, noticeable as a glitch frame the an arm animation. (Honestly I find it odd that it could matter. I feel like there must be something more to this.)

But that just drew my attention to the fact that rotation deltas probably shouldn't be treated like this because Euler angles (which SOM uses) might not be shortest path. Actually I expected to have that problem in the beginning but mercifully it hasn't popped up so far.

So I made a change to stop doing that for rotation (which I may have to reverse course on if it causes problems) and this broke my "wind cutter" SFX model's spinning animation. Incidentally I realized not only is "wind cutter" hard to choose capitalization or hyphenation for it's also awfully close to the saying "cutting wind" in English. It's actually my favorite "magic" in King's Field but the logistics around its name gives me such a headache I think I'm going to have to change it or work around it.

So I looked at the data. For one the numbers were sometimes large enough to exceed the "teleportation" limit, and that didn't seem right. But also the rotation on the X and Z axis was oscillating around positive and negative 180 degrees, which wasn't good either. The oscillations are invisible since they're identical.

For some reason my original model itself was incorrect. I don't know how that could've happened. I think I made the animation myself from scratch but maybe not. After I remade it the deltas were under the arbitrary limit I'd set, but not by a lot. The animation spins 35 degrees in 1/30th of a second. That seems really fast, but I guess not as much as you think. But I wanted to remove that limit like I say, or try to.

So I looked at those oscillations and added some code to detect them. I don't know if the other axes can do this or if it's a "gimbal lock" (singularity) thing. Not having a concrete example I just stuck with this case. (I could flip the SFX on its side and see what happens.)

But too there was something wrong with the MDL file when converted to an MM3D file. It turned out there was a problem with removing the bind frame from it because its first frame was a blank, so there was no data for it. Instead the bind frame time needed to be shifted to make it the first frame. This isn't a problem for making MDL files but it is for converting them. I might have missed this for a less regular model than this rotating SFX. I hope I didn't for the ARM.MDL file. I should probably double check it. (I've made a note to do this and look at the XZ axes... although I'm worried if the latter is an issue it will make it dicey to mess with more than one axis.)

EDITED: I should add that upscaling animations to 60 fps is a temporary solution until I can get around to sampling the animations between frames. That wouldn't be too hard to do right now because the animation code has been rewritten/replaced more recently.

UPDATE: I warned there might be a problem I missed because the last frame wasn't in the animation when converting the MDL into MM3D. I think that's correct (I can never remember how these things work) since the last frame has 0 duration, which SOM can't represent, and where it would begin the animation loops. The thing is the Assimp viewer I used to preview the data I think always loops, so it looked like the loop was complete at the end of its time slider... which is how the source MM3D file is setup as well. (Funnily it seems like King's Field II's animation format defines the final frame and omits the first frame... which then must duplicate the final frame. Or maybe it has a special "flag" to instruct this behavior.)

Holey Moley:
Critical Fix / mdl2x.exe added to ZIP

(http://www.swordofmoonlight.net/holy/x2mdl.zip)

I've patched x2mdl.exe to fix a problem I created by not testing code that I added to add a dummy part to merge control-points into their parent when there isn't a mesh in the part... This is likely to happen for a base CP except historically hard body animations omit this CP (implicitly defining it as 0,0,0) and a soft body animation historically only has one part, so it will necessarily have a mesh unless it's something like KF2's Fire Elemental that uses an SFX instead.

The bug happens because the part array is reallocated and that caused it to automatically deallocate any memory attached to it (I'd forgotten it used C++ destructors.)

Edited: I'm sure I meant to add the reason for this merge code was the arm.mdl model needs every part to map to a specific part of the arm, so the CP has to be merged into the hand or it will think the CP is the hand. Note that there is a fake CP in the arm.mdl file, but it's not a real CP, so it's not technically required.

Also I worked all day on this and merging parts for soft-body animations. Although I know that there is a way to have multi-part soft-body animations (and each part can be driven separately) no models have ever used that facility and I haven't explored it enough to unravel its inner workings.

I'd been trying to make KF2's skeletons walk. Their animation is pretty dopey as walking animations go, I think it's definitely something that should be improved on. But I was just trying to add a base CP so they can actually move off their spawn point. I'm not very good at this kind of animation (no real experience) and thought it might be easier to coordinate to move the CP independently of the body, so I added a new "joint", raised off the ground, and this showed that the hybrid system I'd setup didn't work correctly for joints that aren't bound to 0,0,0.

I plan to rebuild the skeleton animations as hard (aka skeletal) animations, and then improve their walk cycle under better conditions. I think probably KF2's walking patterns are just straight lines, however I've tried to modulate them to be less robotic for my project. I'm not sure why, at low/chaotic framerates KF2 gets away with a lot I think that just doesn't read at a smooth 60 fps.

EDITED: While I was uploading the source code I was reminded recently I modified mdl2x (not x2mdl) to write out material names in the X file (which it should've always done) and so I felt like may as well add that program to the pot since the source code is saved alongside it I think. Note, mdl2x writes Microsoft's X files in the "format" SOM's tools understand. (X is a virtually dead format which suffered I think because of its attachment to Microsoft and because no one used Microsoft's library to read/write them so there are so many different "dialects" of it and most programs have their own "dialect" of it instead of being written against the file format itself, e.g. its specification.)

EDITED: If you set D3DXF_FILEFORMAT=1 as a command-line "environment variable" mdl2x will write text files.

Holey Moley:
Important fixes and working mdl2x :doh:

I've reuploaded, with a few important fixes to x2mdl that are too technical to explain really, but at least one can output animations incorrectly, that could go unnoticed, although it tends to be pretty obvious when it messes up.

Also the x2mdl I added last time turned out to be a dud. The reason it was on my mind is a I modified it to output (preserve) material names, but I hadn't thought about the fact that the rest of the file uses those same names to refer to the materials (as opposed to using their number) so it produced bad files that x2mdo, etc. won't even accept.

I haven't worked with mdl2x as much as x2mdl, but I've been using it for a while now without issue, so it's probably good enough more or less. I have a feeling if you tried to convert every one of SOM's models to X files with it there would be issues in many, but I haven't used it that way very much.

Holey Moley:
Slight fix for working backward and "Original_MDL_viewer.exe"

Verdite (Moratheia) contacted me today with a problem that (inadvertently) made me to notice a change I made a while back appeared to require a touch up. This fix only applies to running MDL files back through x2mdl, or possibly through mdl2x, which may not even do animation.

You might hold off on this though because Verdite has a problem with blue CPs that should be red that I haven't figured out yet, and am waiting for a reply with an input model.

P.S. I've also gone and packed in a new EXE called "Original_MDL_viewer.exe" that's just an up-to-date version of what was called "Somimp_view" in the past. It's just a modified version of "assimpview" that you can use for a limited preview of the input model or to view original (old) models before converting them into "modern" MDL files.

Navigation

[0] Message Index

[#] Next page

[*] Previous page