simple machines forum

So this (pictured) is what I've been wasting the past couple days doing. I sometimes doubt the wisdom of my choices of activities. When I got this model into Blender I couldn't figure out what to do next. I don't do a lot of 3D modeling, and it's been years since I modeled something from scratch.

I decided the best way to start would be to make a "skeleton" for Aleph except not in the usual way, since he's seated. I had to make reverse skeleton, and then pull it back into a standing position. The results in the picture are about as far as I could take it. I used my MM3D software to do this, mainly because I've never used Blender to do animation work, and it was very simple... except for the fact that this really put it to the test, and as usual it turned up a lot of bugs that I had to stop and work on fixes for. That's how you improve new software. But that was the bulk of my time working on this.

Now I will probably shoot it back over to Blender and tweak it. One disappointing thing I found out (which should've been obvious) is my plan to be able to edit the 3D model from inside the animation mode turned out to not work when the vertices have more than one attachment to the skeleton. I may yet find a solution to that, but there's no perfect solution to it, and this will make my idea of using the soft-body mode to tweak kinks in the skeletal animation a lot less attractive if I don't find a solution. If it's not practical then what would help is two viewports showing the model in both modes at the same time, but this will probably be a hard thing to set up in UI terms. Anyway, I have to go back to the drawing board there.

As I'm working on this I'm very seriously considering adding this soft skeleton facility to SOM before I'm done with it, because to dismember this model would be a lot of work and might not look right, even though at a minimum the arms probably need to be separated at the shoulder since SOM only shows the arms. Secondly soft body animation doesn't work for the arms. And third the arms are unique in that they're the only model (besides the gold coin and shadows) that never appears in the editing tools. That means I can add the facility without having to overhaul all of the tools to work with it immediately. Generally I'm adverse to doing work I know I'll have to just discard later. In my mind that's wasted time that's easily avoided. For that reason I see this as a real possibility. If I do this a side-effect will also be finally combining MDO and MDL files because there's no other way to do it. So that will be a big milestone. And I see this as an approachable way to break these tasks up into smaller more manageable tasks over time. (Edited: It will also require a new way to attach equipment to the arms... they'll have to be full arm models just like the arms but without animations. I've been wanting to do this because I feel like the current way involves way too many files and too much coordination.)

Note, on Aleph here his coat is probably down too low on him. It's stretched out in a way that's unavoidable. But it's sill neat to see his character model standing up. No doubt many sitting character models will have undergo this process in the future to bring all of this gold into SOM's treasure trove.

Edited: Just a fun fact. That asymmetry below his belt is because there's a strip of polygons that was clearly meant to be a second strap for his sword to hang on. In the final model it was textured over instead, but the polygons weren't removed. In this image it's stretched out like everything else. Maybe I should have pulled it up around his belt instead. FWIW this MM3D software doesn't have great facilities for working with vertex weights. It's something that needs attention.

Here (pictured) are a couple imports from King's Field III. There's a nonzero chance both of these guys will appear in this project. The Exselector may appear in the system menu. It won't be so odd because it will be technically distinct from the game itself, like a modern day game system's menu. I'm trying to adapt Aleph's model into a VR avatar (in game body double) and use him in place of the original arms, because I don't think they will fly. That said I don't intend to include Aleph's coat here. I'm not really sure what to do about clothing. I will probably use this get up until I have an idea for an original outfit, and eventually provide both options if not more. I can't not include the KFIII outfit (it honestly looks like head-to-toe denim) for old-time-sake.

I guess his red and yellow fabric could be a shirt and stalkings. His skin appears olive tone here, but I think it's very light in the game. I know KF2's textures are much darker and lower contrast than they appear in the game. I assume KF3 is identical, although I don't know what is the mechanism. The same goes for these Exselector models. I think the rainbow color would be more washed out and brighter in the game. I've actually added some fake occlusion shading to Aleph to brighten him for his picture. I think it would be really cool if a single model of the Exselector could smoothly morph between all three of its forms. That would be a really cool progress indicator

EDITED: I've attached the 3D model files... Aleph's for this (https://www.reddit.com/r/KingsField/comments/mmnlcd/calling_artistsdesigners_reddit_contest_to_design/) contest to design clothing for Aleph to wear for this King's Field II project.

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.)

Something of note occurred a while ago. Briefly, for a long time now Sword of Moonlight has had a unique anti-aliasing technique for which I’ve continued to develop complementary 3D image-based graphical effects. This line of work has matured and now has reached a conclusion. It started when I had an idea I thought could address its main weakness: that is it takes more than one image frame to create a double exposure image, which means it can’t anti-alias a single image by itself, or put another way: when a picture is moving it can’t do its job.

This is an economical solution because it doesn’t require any resources or time on the computer to compute its results. When a picture is moving it can be hard to make out its edges, so anti-aliasing isn’t as important. So it mostly washes out, except it’s still a legitimate mark against this technique. To solve this problem (with an equally no resources solution) (as well as it can be solved) the new complementary technique works to remove contrast on moving edges. This looks like an unfocused image on the moving edge.

Shortly after developing this it made sense to implement supersampling for Sword of Moonlight because this anti-aliasing system seems finished, and to supersample an anti-aliasing technique is a common final step, although it does significantly increase the hardware budget to enable supersampling. Supersampling doesn’t automatically buy you much, especially considering its cost. It requires an anti-aliasing strategy to justify its cost, such as the one Sword of Moonlight has. So, long story short, combining these developments produces a very high quality image.

A third thing happened around the same time that’s worth including here: in short, intense scrutiny of the edge contrast technique made apparent deficiencies in the analog control system. A thorough investigation followed, in which not a fix, but a change was made that seemed miraculous in how it produced a much higher quality experience in terms of how movements are transferred from the analog game controller onto the screen. Without going too deep into a description how Sword of Moonlight actually works in this regard is to translate the sensor data from the controller into a very limited digital signal, and then convert that back into the movements you see on your screen. There are benefits to this process versus using the sensor data unprocessed but all that you need to know is the last conversion step is where the major leap occurred.

Finally, in the forum post attached to this blog item I’m going to be publishing previews of the next release, which will also include any patches in the meantime. I will explain the focus of the new release inside.

I've been meaning to sit down and write this blog post for a while now. I've written about this subject elsewhere but I want to commemorate it properly in the timeline.

I think the next release (I'm going to miss "1.2.3.4" ) may be a longer wait than usual. But I'm going to make it available in this topic/thread well before it's officially published. Its focus is on upgrading the magic and weapon buttons similar to the extensive additions to the action button over the years. I may decide to include my planned upgrade to the menu button at the same time to complete the set.

I want to share the new features and may publish them in an incomplete form in my KF2 demo as well as in here in preview form. The difference between the final release version and the preview is only that the preview won't be in the updater menu, so it must be downloaded from this forum thread when it appears. The preview will be 1.2.3.5 and the final version will be 1.2.3.6. I'm also halting patches on the current release, if I can help it. If I feel any "quality of life" changes are worth sharing I'll patch this preview release from hereon out. (If I stumble on a serious bug I will try to patch the current release if my conscience gets to me.)

Work on the shield system is going well. It's pretty labor intensive and time consuming. The work that led up to it actually happened a year or even two years ago. So it's been an ongoing project. The new work I've done this year is already dozens of hours.  I couldn't tell you precisely, I just watch the days melt away. I decided I wanted to resume work on this because I was amped by this anti-aliasing/supersampling development, I wanted to treat myself to something I've withheld from myself since I first picked up Sword of Moonlight more than ten years ago.

Yesterday I was going to write this blog post but the day was consumed by first working on refining an effect where the shield must be pushed back when pushing against a wall (because there isn't room for it between the character and the wall and it creates strange optical illusions because it doesn't poke through the wall) by having the shield only push back when the said wall is in front of it. Usually push effects are 360 degrees because there's no sense of a "front" in a full 360 degree game (which most games aren't) however a shield is definitely in the front. It gets more complicated when turning a corner like this since cornering can be very iffy. The effect has to be stable rounding a corner, and also react to dashing (high speed) into a wall or other obstacle. But the worst of yesterday came later, that was a struggle with the walking effect that arises because the shield needs to be not synchronized with the walking effect (so the arm doesn't appeared glued to your head) but at the same time it's very close up and so any sudden movement in the effect is amplified by having the shield as a point of reference. This really put the walking effect code to the test. I got very close to burning out on it. The nastiest problem was since I've so far decided to let the "hop" input work with the shield raised. Hopping is inputted by poking the direction pad and tapping the action button simultaneously, which results in pretty high frequency input into the walking effect system that's followed up by a leap. That's probably the hardest test, i.e. to not glitch too badly, or ideally at all. I mostly got it working. Good enough for now. (This easily becomes a full day of work.)

For the record, right now the shield is pretty high quality in terms of button presses and movements. I've also improved my animation to the point it's presentable. I still have a number of aspects to address. I haven't decided how everything works. For regular jumping so far the shield is just forced to be lowered. That may not make sense if lugging a shield by your side is unbalanced for jumping. But as general rule most kinds of inputs force the shield to be lowered unless there's a reason not to do so. So far regular running doesn't lower it. Dashing and crouching doesn't. Most other things do. It comes back automatically if you're holding down the button.

May 12 Update:

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.5.zip

https://swordofmoonlight.itch.io/k/devlog/252682/shield-and-counterheavy-attack-demo

Attached is a DATA/MY folder that shows how to set this up. ItemEdit is needed to make Move Set profiles that just need to assign the number of these files to the first slot. It currently only supports the first slot. If left blank it uses the equipment type number, which is what the 2 and 5 files are. These are also used by the Nothing equipment. Note, to use the Nothing equipment you have to leave at least 2 item slots open. I've actually reserved 5 for later on.

Final 1.2.3.4 Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip

I've decided to finally retire this version (1.2.3.4) with this patch that (1) fixes the afterimages in the arm animation that I broke in recent patches (they were drawn on top of each other) and (2) fixes phantom pause that can happen when the program in "minimized" causing the game to keep playing and using potentially high CPU/GPU resources.

I'm planning to write a blog about the recent round of developments that culminated in the new supersampling mode and in its topic/thread I'm to float an odd numbered demo version 1.2.3.5 which will include important patches and tests of the new shield system as it's mid development. Odd numbered versions aren't available to the updater menu.

This was a very fun version but a hodgepodge of patches too. It's linked to my KF2 project's initial demo and happened to be "1-2-3-4" so I've stuck with it longer than I should, especially since my work has been unfocused here lately. I've got a lot of unfinished efforts underway. I've no particular goal in mind. I think the new "arm" enhancements is a good thing to structure a release around, but it's going to be a slow build to releasing it.

Here are some images of KF2 with the Iron Gloves worn on the arms that appear when fighting. I swear I spent upwards of 8hrs editing the arm version of the gloves. I honestly don't know why it takes that long to adjust a 3D model. Time just seems to melt away in 3D modeling. I don't know if that's normal. It may just be a labor intensive activity. Rebuilding meshes can be difficult.

I haven't published it yet but as of today equipment is finally on the two arm setup. I didn't have to work on it because there's no arm equipment in the demo on itch.io since there's none at the start of the game. I made these gloves just so I could work on it. I'm not crazy about how they appear. They should be even whiter than they are, but I darkened the MDO materials some. I like how the gloves appear in the menus. It's weird how they don't really translate to being cool to look at on the arms.  I plan to redo the arms before I'm done with something completely different. The forearms are super long. I guess that's some trick of perspective that generally works for the weapons but not for the angle on the shield. Technically the original animations are the "soft" variety, so it may be sometimes in the game the forearms would shorten. But SOM only understands the hard variety for arms since there's a lot of special infrastructure involved for them.

The shield seen in the insert is not finished. It's very nice and a lot of work has gone into the new shield system, but there's a lot more work yet to be done for it. There's many different aspects and needs for shields.

I shared an image of shields in a dedicated topic/thread a while ago. Today I changed my shield animation to a more exaggerated or stylized one mainly for two reasons. One was these gloves are very bulky and have some teeth like appendages that project out. I made it to hold the shield so the teeth would not clip through it. The handle on the shield isn't ideal for that but it can be redesigned eventually. I don't know if this is a natural way to hold a shield. It's a little more statuesque, but is it practical I don't know. The other reason is for now I'm assuming the gloves can be used as makeshift shields to deflect attacks and I wanted the glove animation to be approximate to the shield animation. They don't have to be identical but I thought they should suggest each other at least. The other way of holding the shield just didn't look like how you'd hold up a gauntlet to protect yourself... or it didn't look right or good.

This new pose brings the shield much closer to your face, so it's larger on screen and when pulled toward you (or when pushed up against things) it now covers the entire screen, so you're forced to play blind. That really gives a suggestion of protecting your head with the shield. I thought about scaling back the distance or basing it on the hand location (which will probably happen eventually) but ultimately I feel fine with it.

Currently pressing both buttons pulls it up closer to the face. Once I get to managing the damage reduction provided by the shield this will be a little better than the regular protection. It takes two hands suggesting you're also pulling your limbs in to be behind the shield. And you can't run... well you can, but it pulls the shield down... because pressing 3 buttons is the full running mode. I'm a little concerned pressing both buttons is going to come into conflict with my eventual plan for holstering weapons that I was really happy with. I like this too (and it has other uses) so I worry what will be required to not be forced to choose between them or decide on a different inputs.

Alternative holstering inputs would have to rope in the Menu button, which I'm generally against. I've also realized that mapping the menu button to the face buttons  doesn't make sense because it ties up the thumbs which are needed to use the planned quick-select system. That tells me that the four shoulder buttons are going to be locked in for SOM. Tapping the menu button could conceivably have a different function, but the quick select is needed on the shoulders. A game like Armored Core might make tapping the Menu button rotate your "subweapons" instead of opening a menu but in King's Field menu is pretty normal to have handy.

Speaking of menus today I worked on delaying equipment changes until the arm equipment isn't visible onscreen. I was working around equipment things to manage the models for the left arm.

One last thing. Currently the arms are fused together so it's not simple to manipulate them independently (that's not implemented) but the centering changes for two arm weapons since being perfectly center generally matters a lot for a two arm animation. I was centering when the shield was up too. But since I changed the pose to move the shield even further to the right side of the screen I decided that the shield arm should be pushed a little off the side of the left screen. So I split the difference between centered and the position of single arm attacks when shields are on screen.

Currently the shoulder distance is fixed at 0.2 meters, which isn't the original SOM distance but is the KF2 distance. Eventually I'll work on extracting that distance from the ARM.MDL skeleton. The single arm distances is 0.14 meters, and for shield 0.17 meters. You'd have to match that 0.2 value to make a new arm model with two arms. I don't think it makes since to think of it as moving the head over (ouch on your neck) so instead I think of it as rotating your shoulders. But because the arms are fused they don't currently have the right depth for that. It actually wouldn't be very hard to move the shoulders independently, but "hard" is relative in writing software... it really comes down to making a day of work out of every little possible project. You have to pick your battles day by day. But anyway I think this looks better to make the shield arm less prominent and pull the weapon arm closer to the center area. I'm going to redo KF2's arm animations (and design too) but the vertical swords for example look like meat slicers, and they tend to look better closer to the center than off in the margins, and even for the knife (Dagger) it's better if the target zone is as close to center as possible.

Strikeout: Day 2 I realized I was being stupid yesterday because it doesn't make sense to push the shield to the left if the centering is supposed to represent twisting shoulders. And it even makes sense to put the shield shoulder further out as if leading with the shield... I'm going to edit a new idea I had into a new reply post...

Important Fix Patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.4.zip

Somehow about half the resolutions were "cursed" by the change I made how the effects depth buffer is cleared (reset) to try to get a little bit better performance.

I still don't quite understand it, but only my KF2 project seemed to be affected, and the solution is when the "render target" changes it automatically resets the "view port" so it just needed to save/restore the view port. It looked just like the buffer wasn't getting cleared (water would disappear for one thing, sometime a pure black screen--yikes) but there must be another explanation.

Anyway this fixes it, and I hope no one had this bad experience with my demo in the past so many days since that change. The weirdest thing is it only hit some screen resolution settings, which makes absolutely no sense.