Topic: x2mdl/x2mm3d download (2021) (Read 23699 times)

Holey Moley · « **on:** December 25, 2020, 06:08:58 PM »

It's Christmas 2020, today I'm just making a link for a post where I will publish a new version of x2mdl I've been working on all year long. I would do it now, except I'm about to publish a new version of MM3D that drastically changes the way animations are stored in the mm3d files, so I need a few days to update x2mdl to be compatible. I think everyone can wait a little longer so to not have a too bumpy debut. It will probably be up before 2021, but the subject line for this topic/thread says 2021, so please check back a few days from now.

2022: http://csv.swordofmoonlight.net/x2mdl.dll/

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

http://www.swordofmoonlight.net/holy/KF2-DATA-BACKUP.zip

https://github.com/mick-p1982/mm3d/releases

Reply#3 has some instructions.

Updates

*3/28/2021: Fix for inputting MDL files that have no deltas on the first frame of the first animation (now inherits data from the bind frame that's not outputted) and a fix that normalizes rotations around the Y axis so they can be upscaled to 60 frames per second in the player (notes in Reply #6.)

*4/14/2021: Critical memory corruption bug fix. Edited: Also added mdl2x program. This program is less tested, more experimental. It converts files to Microsoft's X format compatible with SOM's conversion tools. This may be the first time it's been published (notes in Reply #7.)

*5/9/2021: More fixes, incl. I bungled mdl2x last time because I added material names to improve it but didn't think to fix the corresponding parts of the file that reference the materials by their names. That's the kind of thing I do all the time (notes in Reply #8.)

*5/22/2021: Slight fix for first frame when inputting MDL files (more for diagnostic use) and adding "Original_MDL_viewer.exe" tool (notes in Reply #9.)

*7/15/2021: I've attached some source code to this post for safe keeping. You don't need to download it. It's not stored in the official repository with the x2mdl source code because it's code added to Assimp, that's used to read files.

12/17/2021: That code (strike-out) is now available with the rest of it (http://svn.swordofmoonlight.net/Sword-of-Moonlight/code/x2mdl/) (x2mdl is now built into SOM and extremely vetted.) The ZIP file is updated with new x2mdl.exe and Original_MDL_viewer.exe and a new viewer called Modern_MDL_viewer.exe that does the same modifications as x2mdl.exe. You probably want to use the latter if you make use these programs. The former (original) is for looking at old MDL files without any changes to their skeletal animation hierarchy and key frame data. Otherwise they're both just quick viewers for MDL and MDO and MSM model files. Also note, there's now a few command-line options for x2mdl.

4/9/2022: KF2-DATA-BACKUP.zip is art from my KF2 project for anyone who's asked for KF2 models in the past. Unfortunately the textures are quite dim. This is how they are on the game disc. You'll just have to increase lighting in your software or process them with image editing software one by one to your need.

Holey Moley · « **Reply #1 on:** December 28, 2020, 01:19:01 AM »

I've published the MM3D update here (~~https://github.com/mick-p1982/mm3d/releases/tag/win32-demo2c~~) so now I can turn to x2mdl/x2mm3d. Since Christmas day I've had domestic interruptions in my regular schedule, but I've managed to squeeze in a half workday each of the past 3 days. Strike-out: https://github.com/mick-p1982/mm3d/releases/tag/win32-dec-2021 is a new release preparing switching SOM over to use this MM3D format in a couple days.

Off-topic: I also wrote up my GameFAQs end of the year report today: https://gamefaqs.gamespot.com/boards/958393-sword-of-moonlight-kings-field-making-tool/79202963

Update 8/6/2021: I've attached some MM3D files from my KF2 demo I made by "drag-dropping" the MDL files onto the renamed x2mm3d.exe file in the top post of this topic/thread. These can be opened with the program in the win32-demo2c link above and posed/saved as OBJ files. I've done this because a good Patreon supporter/donor kept asking for these files, but I thought I'd given instructions on how to do this (not here) already, but since they asked again today I've done this process myself to show just how easy it is to do.

Update 12/8/2021: I've published a new release specifically for working with SOM's legacy models that are stored on this site, which will soon be distributed as MM3D files only compatible with this software. This makes them more manageable. Even though there's some room for more advanced features this should make it easy to fix all of the (many) blemishes and is a start.

Holey Moley · « **Reply #2 on:** December 31, 2020, 06:02:25 AM »

Sorry, I've misbehaved, I'm running late on this goal. I did upload a pretty big patch to the MM3D demo from the previous Reply/post today. I swear I'm on x2mdl first thing tomorrow.

Truth is I got lost in a programmer's rabbit hole for two days. It's a hard phenomenon to describe, but it happens from time to time. You really get invested in something and it can kind of takeover your world until you realize how neglectful you've been in being so single-minded. Sometimes it can seem like your goal is just beyond your grasp, and next thing you know, it's just beyond your grasp, and next thing you know (next,next,next) it's two days later and you realize this has to end, but you keep going still, but eventually you do get that train to come to a halt. Luckily this time I got some good work in there, but I should've cut myself off sooner and did what I said I would do.

Well, right now it's midnight so I'm going to watch some videos online while it doesn't count against my data plan. Otherwise I might get started now.

Holey Moley · « **Reply #3 on:** January 02, 2021, 06:35:15 AM »

This (http://www.swordofmoonlight.net/holy/x2mdl.zip) is kind of a rush, but I went ahead and uploaded it because I shared a bad/broken one the other day (different topic/thread.) I wanted to put out a working replacement.

I'm going to put this in the TOOL folder I guess, shortly, I want to give it more thought and add some command-line options and probably I need to finish the mixed animation feature I'm working on right now before putting in the versioned file tree.

The mm3d facility is only compatible with the newest patch uploaded to https://github.com/mick-p1982/mm3d/releases/tag/win32-demo2c just earlier today. To make MM3D files (instead of making MDL files) the way is to rename it to x2mm3d. It can only output MDL or MM3D. It can take many inputs but I only recommend MM3D or maybe X but it might be acceptable with others. (Edited: Of course it supports SOM formats.)

There are very many ways to make control points now, but I haven't tested them all. MM3D files should use real points instead of triangles and name them to (C0) or (R0) to (R31) and yes, you must include parentheses. It also detects vertex colors or color only materials or any mesh or node with those names and maybe even other points, but they need color if not named.

I may update this link. I'm not using an attachment since I don't like reattaching because it breaks the links.

EDITED: To be clear, this initial version only understands SOM's two types of animations and so can't mix them or make weighted animations. This is the first version than can do soft animations. Shortly there should be a simple system that can convert an unweighted, mixed animation into a soft animation. Then I will see if it's feasible to convert weighted to soft.

Holey Moley · « **Reply #4 on:** January 03, 2021, 07:50:14 PM »

Important bug fix

I've reuploaded with a bug fix that affected MM3D->MM3D "conversions" but might well effect others, and I think I've done all I intended for outputting unweighted mixed animations.

I'm going to take a break before adding more options and making space for it in the TOOL folder and adding the Assimp code to the SDK folder.

This will let me (finally) get back to working on KF2's monsters.

Holey Moley · « **Reply #5 on:** January 04, 2021, 07:56:03 PM »

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 · « **Reply #6 on:** March 28, 2021, 11:00:33 PM »

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 · « **Reply #7 on:** April 15, 2021, 04:27:09 AM »

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 · « **Reply #8 on:** May 09, 2021, 05:11:19 AM »

Important fixes and working mdl2x

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 · « **Reply #9 on:** May 22, 2021, 05:34:48 PM »

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.

Holey Moley · « **Reply #10 on:** December 08, 2021, 07:04:24 AM »

new MM3D release

~~https://github.com/mick-p1982/mm3d/releases/tag/win32-dec-2021~~ is a new version of the makeshift 3D modeling software I've developed which is meant to work with the new SOM model files I'm going to be publishing any day now. I've added notes above.

Strike-out: Please use this link https://github.com/mick-p1982/mm3d/releases for newer versions.

I had a really bad evening with it because for some its app always starts slow (something about wxWidgets) but now I got it to start fast but it would show a busy cursor (IDC_APPSTARTING) for like 5 seconds at the start. It was really dumb because the app worked fine. I spent hours trying to make it go away through programming fixes until it went away for mysterious reasons, at the very end... that I don't want to speculate on further. I just want to relate a frustrating evening sitting in the cold. It doesn't help I'm missing a cat lately.

There will be new and improved versions of the other tools/apps here in the coming days. They need to go up after the new release does. There's now (shortly) a version of x2mdl built-into SOM (technically a new DLL file) so using x2mdl/cpgen should be a thing of the past, but the renaming trick for x2mm3d.exe is still pretty useful to convert Assimp's formats to this MM3D format. The new system isn't technically limited to MM3D but I haven't worked with other formats, most don't have everything SOM needs. There will probably be issues with control-points that would need to be ironed out in order to use different formats. CPs are the most annoying part honestly.

There are some new convenient command-line switches for x2mdl but I haven't yet staked out ones for changing the output mode and the output location.

Holey Moley · « **Reply #11 on:** December 12, 2021, 11:07:35 AM »

final update

As of tonight I'm finally at the end of this project... luckily though at the very end I noticed a problem with an animation not matching its original, so I just have to work that out and probably endeavor to recheck/reconvert every single thing one last time. Unless this stumps me tomorrow I should be able to publish it by tomorrow.

BTW, RE my last post (#10) in here I've definitely, since, fixed/improved a number of things with that MM3D release, which was more just about ripping out ANGLE so I could compile it again and some usual troubles with wxWidgets/Windows. But I'm going to hold off before patching until sometime after the new release. It definitely has a problem with its lighting setup I want to tackle. I noticed yesterday the original author of the old Misfit Model 3D code probably did a very weird thing by flipping the relationships of lights and materials to set up its fixed lighting behavior. It defaults to 20% ambient and 80% diffuse, which would be normal for lights, but this is the materials, and the lights can't be changed (yet) so standard 100% 100% materials are completely flooded with light that isn't useful. And its selection highlight is a red light, which becomes invisible except on the gray solid mode material. It should probable be an emissive contribution instead of a light, but even then it's troublesome to use a single color since a red object will be invisible to red highlights. This is a constant problem with modeling software. It's a problem for the do_red extension to. I wonder if that's why I think in KF3 when you hit the monsters they also turn a little be see-through. And maybe a little bit white/pink too.

EDITED: This round of work has pushed me further than ever before to the brink of exhaustion. I've been working on it day-in-day-out double-time for weeks, as long as I can remember. It doesn't bode very well for anyone who ever wanted to make their own game system that it seems to be a near impossible task except for a very unconventional lifestyle to be able to do it, and even still just making a decent workflow change like this one takes such a large amount of work, when you could look at it as only a small part of the bigger picture in the grand scheme. I'm definitely psychically at my breaking point, and I know I have to a break of some kind after it's done. For the record, there's nothing especially technically difficult in the new code. It's more like a huge mountain of paperwork that seems to never end. There's also something very mentally exhausting about working with 3D model data transformation code for days on end. It's hard to describe it. It can be one of the most complicated/sprawling data structures that exists, and going from one form to another is not always straightforward... it's tempting to make it more straightforward by writing naive code with more moving parts. There's a tradeoff between intelligibility and performance. There's always a bit of finicky math in there too. Transforming between different coordinate systems and mathematical models can be a lot more complicated than you might think.

Holey Moley · « **Reply #12 on:** December 17, 2021, 03:37:08 PM »

These files are updated once again with notes in the top post (12/17/2021) after a very drawn out SomEx release focused on building x2mdl into SOM and thorough testing it.

Also the MM3D model editor is updated here (https://github.com/mick-p1982/mm3d/releases) to cover the alternative MDO blending mode and work better in a few new ways.

Holey Moley · « **Reply #13 on:** December 18, 2021, 10:25:44 AM »

Important MM3D fix

EDITED: Yesterday I uploaded an EXE file to https://github.com/mick-p1982/mm3d/releases instead of the full ZIP file with some extra documentation. I've also fixed a problem with materials not having their alpha blending mode initialized that didn't show up in debug builds (this even applies to opening files so it's kind of a big deal.) (There were two places where the value was initialized--a big part of my working on this MM3D project has been refactoring it's really chaotic and duplicitous code.)

Holey Moley · « **Reply #14 on:** March 04, 2022, 10:42:41 PM »

Note, the official release location for x2mdl is now found at http://csv.swordofmoonlight.net/x2mdl.dll/ (find the newest ZIP file and unzip.) I've added this to the large font download ~~link~~links. I'll still update the other from time to time, but for downloading x2mdl.exe the official is best. Plus x2mdl.exe is now updated in the TOOL folder when updating x2mdl.dll. If you're looking to do custom model work I recommend downloading both (at least for the notes) and ask for help.

Edited: While I'm here... yesterday I found a mistake I made with scaling animations. They need to be remade, unless perhaps if a model only has one animation in it (which all of SOM's scaling animations do.) I've also been making lots of improvements to it lately since I've been doing modeling work on my KF2 project. (I've also been working a lot on MM3D. It's even come to dominate my work lately.)

simple machines forum

News:

Sword of Moonlight|

Help|

x2mdl/x2mm3d download (2021)

Author Topic: x2mdl/x2mm3d download (2021) (Read 23699 times)

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

Holey Moley

Holey Moley says,

simple machines forum

News:

Sword of Moonlight| Help| x2mdl/x2mm3d download (2021)

Author Topic: x2mdl/x2mm3d download (2021) (Read 23699 times)

Sword of Moonlight|

Help|

x2mdl/x2mm3d download (2021)