simple machines forum

Sword of Moonlight => Help => Topic started by: Holey Moley on December 25, 2020, 06:08:58 PM

Title: x2mdl/x2mm3d download (2021)
Post by: 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on December 31, 2020, 06:02:25 AM
 :evils: 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.)
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on May 09, 2021, 05:11:19 AM
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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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.)
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley 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 linklinks. 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.)
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on March 18, 2022, 10:33:47 AM
MM3D upgrade

First, off-topic, I've uploaded a minor SomEx.dll patch just now that fixes a problem with scaling animations. I'm not going to announce it as usual.

The past few days I've been working upgrading MM3D's modeling capabilities by addressing several of its tools that original author neglected to add texture map support to. That made these tools pretty much useless since texture mapping is the most difficult thing, and it's not worth ruining your texture map to edit a model.

I've mostly been using it for animation, but lately I've not used Blender since I started the new round of work on my KF2 project. I have been making some edits, but I'd hit enough walls that I decided it was time to roll up my sleeves and do something about this. The demo and source code for this is on Github.com. I really enjoy working on MM3D this way. I've been pleased with my decision to take it under my wing.

Anyway, this is just my activities of late. Hopefully I will be back to working on KF2's NPCs by this time tomorrow.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on April 02, 2022, 12:12:09 AM
MM3D upgrade

I've been working on the UV editor part of the MM3D editor a lot in the past few days... all day yesterday. I've published the work on its Github site. It includes snapping and other new editing commands and buttons. I have to work on a pivot system like Blender's "3D cursor" to make it a little better, but it's pretty competent at this point. I had to add a vertex (UV) snapping system to edit KF2's ghost the other day. Yesterday I worked on snapping to pixels and polish. There's considerable hotkey remapping, so always delete your key binding config file to restore to the latest default.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on April 09, 2022, 07:04:41 AM
Quote
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.



http://www.swordofmoonlight.net/holy/KF2-DATA-BACKUP.zip
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on April 16, 2022, 11:07:34 PM
checking in

In the past 2 or 3 days I've been taking on SOM's UV animation problems. There are 3 problems I hope to tackle. The first is control over sky animations. The second is animating NPCs and monsters. The third is animating MDL files in general, which includes NPCs and monsters, but the real problem is just the inability to mix regular animations with UV animations. A fourth is animating level geometry. Unfortunately that one's going to have to wait. There is a solution for that already, but it's not ideal.

Unfortunately I expect this to be a week long project, if not 2 weeks, since it will also include realizing the animations in the modeling software, in the player, and converting the art data into runtime data. It's not exactly what I expected to be working on right this moment, but it seems to be the right time to do this.

The first problem I faced was how to wedge this into the modeling software UI. UV animation like this is pretty obscure, and the software already has virtually every key on the keyboard mapped to hotkey shortcuts. So it didn't make sense to make a dedicated facility for it, and I didn't want to tack it onto the animation facilities either.

Animating a UV map is already pretty odd since there's not really anything to grab onto. You could cook something up, but it would feel a little pointless and frictionless. I wanted to add a new category for more obscure video game like needs. I.e. stuff 3D modelers don't usually think about, but games need. The more low-fi the game, the more obscure the need. I had to brainstorm what to call it. I started out with something like Effects, but it didn't map nicely to a shortcut. Then I thought maybe Qualities, but I didn't like using Q as a shortcut... that area on the keyboard already has a certain character that didn't quite fit for opening a window up, lest you do so by mistake. Then I hit on Utilities, that was just perfect. That made me excited for the project. The U key was wide open (being quite out of reach) and "utility" exactly captures the meaning I'm going for. I'm surprised I didn't have to resort to a thesaurus. It did take me a few days to come up with that.

It's good for work when everything seems to click into place like destiny. Also there's an existing "Meta Data" system that didn't have a good shortcut assignment. But I changed the wording to User Data (better IMO) and that was perfect as a double (Ctrl+U) for the U key. Especially because this new Utilities layout is identical to the User Data window's, even going so far as to reuse the same code and source file.

The first day of real work was a hurricane of just laying down infrastructure. Because of the extra level of indirection caused by establishing a category (Utilities) there was extra work and abstract things to consider. It's a modular system, ideally it would be nice to integrate plugins into it. It's like meta data, only more than just little textual notes. (Sometimes games can get some mileage from such notes, but SOM doesn't. It can also be nice for adding contact information if you want.)

I think somewhere down the road will be some "utilities" for fine-grain manipulation of lighting "surface normals". That's something you can't always get out of 3D editors which low-poly games can really benefit from. I already have a problem with lighting on KF2's dead soldier (I call him star man) because this software calculates soft normals differently from KF2's. It's more correct, but the slight difference on low-poly models makes the soldier's face look pretty bad in some locations. That could be fixed by having any of a number of facilities, including storing imported normals, alternative ways of calculating them, or full customization... as in directly specifying normals. Anyway, the thinking is if you keep adding obscure possibilities like this in a disorganized way then the software's high traffic interface would be compromised.

How the Utility system differs is it pulls out a side panel that's tailored to the utility type itself. When I was done working yesterday I wasn't too happy with the layout. But I had some ideas this morning and now it's all come out quite nice by the end of the day. Sometimes doing layouts with C++ seems to go slow. Plus I've been improving the UI software itself somewhat today. One day I'd like to apply it to SOM... like for Apple or Linux systems, where Windows won't fly. The right panel is still a little incomplete. It's going to have full key-frames for a texture matrix... but I don't expect I will initially enable all of that for SOM's MDO file format. I'll leave it open for expansion if not. For modeling software it would be too odd to restrict it to SOM's use case.

In the screenshot the Detach button lets the right panel come off in order to be able to work with the main window at the same time. This changes the undo/redo model somewhat since every change then becomes an undo sequence point, and there's no Cancel button. But really there just needs to be a way to get to its panel in the first place. Programming UI stuff for editors takes days too. It looks simple but it may be more complicated than the actual animation logic... especially if it's approached as an art form in its own right.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on June 06, 2022, 09:00:29 PM
MM3D upgrade

More info: https://github.com/mick-p1982/mm3d/issues/1#issuecomment-1147825671

Download: https://github.com/mick-p1982/mm3d/releases/download/win32-dec-2021/mm3d-portable.zip

Edited: A lot of hotkeys are remapped. The Help->About menu now has a "Tip" to clear out the keycfg.ini file, and the hyperlink to its URL should now open it into your text editor that's assigned to the INI extension.

This is a substantial upgrade I've been focusing on pretty much since the new KF2 demo I published on the eve of May 1. I don't like the thought that it took me a month to prepare this, but I don't know what else I've been doing.

This model editor is becoming more mature. I'm happy with how the menus and hotkeys have turned out. The main focus of this update is a graph based animation editor, but it's really pretty basic. Maybe the extras are more impressive, but it was the editor that took up the bulk of my time preparing this. There's just so many little details involved that you wouldn't think of.
Title: Re: x2mdl/x2mm3d download (2021)
Post by: Holey Moley on June 09, 2022, 04:56:34 PM
Fix

http://www.swordofmoonlight.net/holy/x2mdl.zip
http://csv.swordofmoonlight.net/x2mdl.dll/1.0.0.2.zip

I've updated the x2mdl.exe file in these to fix a bug when converting MDL files into MM3D files that outputs 1 pixel textures if the files already exist.

Unrelated, FWIW I've also updated https://github.com/mick-p1982/mm3d/releases to fix glitches in the scroll bar pixels, and a couple other minor bugs. I've also added a mantis-model.zip file in order to supply a test model to play with. It's the same as SOM's DATA/ENEMY/MODEL/E019.MM3D file.