simple machines forum

Please login or register.

Login with username, password and session length
 

News:

Remember to make your own backup of posts before submitting.

 
 
Pages: [1] 2 3 4 5 6 7 8 9 10
 1 
 on: Yesterday at 10:48:21 AM 
Started by Holy Diver - Last post by Holy Diver
Patch

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

Continuing to update via patches, this patch fixes a twitch when bending over in front of walls I introduced in a recent patch and fixes a bug that had let projectiles pass between level geometry polygons when aimed at the seams, and upgrades the wall clipping math.

The last detail is significant, but first I must add there are some files changed that require using SVN Update. These are upper arm sections for two arm equipment items and a new MHM clip model for the tile that is like half of a column embedded into a wall, and changes to their PRT files.

After I made the change to this MHM model (the old one modeled the column with just a slab) they revealed the clipping issue I sought to address in the past days. After I finished that yesterday I looked into the projectile bug which I've been aware of for a least a couple years, and I discovered the MHM hit detection code there was particularly bad (SOM's code is not the work of geniuses, in case anyone is wondering) so I just rewrote it all and managed to fix the bug along the way.

As for the new wall clipping logic, it uses a significantly different approach that is much more accurate with the goal of being able to pass through any opening that will accommodate the clipping radius (developers should be able to assume if there is a 1 meter opening players will be able to pass through it.)

I'm pretty confident I implemented this correctly, but it's new. Because it's more accurate a problem arises because if you consider a corner, if you approach it, you might hit both walls, in which case whichever side happens to be first in the model data will predominate. If the code is very accurate it will make it impossible to touch the other wall. I might change this by adding some reflection logic, but the end of result of this change is the model is more "sticky" so to remedy this the best I could think of was to reverse the order that the polygons are considered every other time. That way the other wall in the corner can exert an influence in the case of a draw. In this way the stickiness mostly goes away, but it's a short order fix to a brand new system. I just have to get it off my work stack right now.

The old system was sticky too, so I guess very possibly this new system is better, but the top priority is removing those instances where the old model resulted in invisible barriers. I guess I never noticed since as long as they don't create a passage narrower than the clip radius usually you wouldn't notice them.

The technical differences is I used the section of the clipping circle (on the ground) and the wall's plane (upright) as the clipping radius for testing 2D penetration of the polygon outline. Usually this is much smaller than the fixed radius that was being used. But in one case at least, it can be a problem, so I resorted to a hybrid system that maxes out at a half radius, which was the old system's way. That problem case is if you find yourself right on the wall's plane, which can happen if you approach it from beneath an archway.

Another step lessens how far the clip shape is ejected from the wall so that if it's on the wall's lip instead of being ejected all the way out, it just ejects to where the clip shape (column) would be stopped by its own geometry. Like if you pushed a cylinder against the edge of a wall forming an exterior corner then depending on how far the cylinder is from the corner, more of the cylinder can pass behind the plane of that wall before actually coming into contact with it.

I think the old system dealt with this by using half the radius for the 2D geometry penetration test and using the full radius for the plane test. I think that's an interesting hack but leads to the problems this change addresses. In other words it had pretended like the walls were inset by half the radius. But only for some of its math. Part of me wonders if this is actually smart, but I think it's not something that can work with the new system since its radius isn't a fixed value.

Also for this second step (ejection) the code could be a lot better. Instead for time sake I've just treated every polygon like it's an upright rectangle. It can be improved (later when I have time) by clipping the top and bottom to the base and height of the clip shape and finding the point on the diagonal where the clip shape touches the polygon if it's not a rectangle polygon. Most clip geometry is rectangular, so this is good enough in the meantime.

 2 
 on: August 04, 2020, 07:00:02 AM 
Started by Holy Diver - Last post by Holy Diver
For the record I fixed a bug yesterday that made the bicep equipment piece not show for full body armor like the Forest Armor (although technically it doesn't have anything covering the bicep) and Full Plate armor (which does.) I think Verdite may have tried to explain this to me once.

I also fixed a SomEx.dll bug that didn't update the arm equipment for full body armor. This started only since back when I worked on making the inventory sortable/reordable and recalling the menu state.

I haven't published a patch for this since I've identified a new problem with clipping that requires (I think) a change to the clip test. I changed the MHM model for columns with a beveled base, and forming a 1m passage from two of these reveals the problem since it's impassible. It happens I think because the clip planes of the walls extend beyond their edges, so two diagonal clip planes cut into each other forming an invisible wall.

I may look into why projectiles sometimes go through walls at joints, which may be related to this problem. I'm also considering making platforms take friction into account so that when you walk past these columns you don't climb up onto the base like someone who doesn't know how walking works. (They're the same height as stairs but they're not meant to be stood on.)

 3 
 on: August 03, 2020, 12:14:06 PM 
Started by Holy Diver - Last post by Holy Diver
Patch

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

Yesterday I forgot about how the arm/hand equipment pieces have extra models that displace the ARM.MDL sections.

This patch addresses that omission and makes that system a little more flexible since before all 3 MDO files were required, but now if one is absent it will use the ARM.MDL geometry.

Most of these items have dummy models for the shoulder/bicep part of the arm so I took the drastic option of deleting those files. The problem with this approach is you need this version/patch of SomEx.dll to make it work without those models. I didn't want to upgrade the models with the new bicep/shoulder work I did.

Two items have alternative models for this section. I have to take a look at them. One seems to have a pauldron or something that is closed off, so technically it's okay I guess. The other has a hole in its shoulder like the old ARM.MDL that I have to fix when I can get around to it.

All of these models require work to switch over to soft shading to match the new ARM.MDL file and I think that this system should be more flexible, and ideally the ARM.MDL should not be displaced as long as the pieces aren't in conflict with it, so that they don't have to copy its geometry since that's error prone and inflexible. But changing how this works on a more fundamental  level will require more elaborate extensions and even more work.

Luckily unless you pause the game these arm models fly by so fast you can't see them well. But the hole in the shoulder is definitely possible to pick out. I have to fix that. Really it seems to me that the body equipment should cover the shoulder. Of course both can as long as they don't come into conflict. I actually thought maybe that's how it worked, but it turns out not to be the case. (I'm not as familiar with SOM as you might guess, yes I know more than anyone surely, but there's a lot I haven't looked at that people who've made games all have to deal with at some point. That's caused communication problems is the past. Making my own game with SOM is a big help here, although unfortunately my memory tends to slip away faster than normal.)

 4 
 on: August 02, 2020, 02:39:27 PM 
Started by Holy Diver - Last post by Holy Diver
Today I published a body of work that’s been underway for some weeks. I’m doing a write up since things have been quiet around here in the meantime. I’ve been doing three projects with some overlap, 1 has been my ongoing work on the Sword of Moonlight animation file format, and 2 at some point I realized a simple way to have the animations playback at full speed at 60 frames per second, as opposed to playing out at 30 frames per second, and 3 because of this change numerous other parts of the player software had to be upgraded to double speed at the same time. At the same time I’ve been looking at the model of a human arm that appears when you use your weapon in the games, and how it is positioned on screen, since Sword of Moonlight does it differently from King’s Field. I don’t know if it’s based on Shadow Tower of if it just does it its own way.

All of these things have come to a head keeping me from publishing anything until now. By working on the animation front I’ve been able to refurbish the arm model in order to support changes to how it’s displayed. It’s long been at odds with some extensions. It’s been possible to make an all new arm model, but in this case I’ve been able to take the original and work on it further without disturbing its information content. That’s a milestone in its own right, since it shows it’s now possible to improve on the original animations that are included with Sword of Moonlight’s sample art work and retelling of King’s Field. I wanted to bring the arm up higher and make it larger on screen. I couldn’t do that without editing it to look nice up close.

The arm effect is also upgraded to look nice at 60 frames per second in what was one of the greater challenges I faced. It now has four times as many animation frames. It turns out showing something commonplace moving fast in your face in first-person is hard to do with great efficiency. I’m releasing this work as a patch to the current release this time around. It coincides with a crash fix and I’ve just been dumping patches into this release right now while I work on King’s Field II. I worry about getting swept up in a side project as its deadline draws near.

I just wanted to write something for the front page blog. Instead of making this a "release" I'm just linking to a patch, below. I'm not sure why I feel like just patching this release, but maybe it's because I'm having to rush things to be able to work on King's Field II and I feel like eventually if I keep patching the loose ends will get tied up. Like I haven't been documenting a lot of things and I worry I am not giving myself enough time to do proper releases right now, which is one reason this patch is identical to what I would be releasing. (This is explained in the link, quoted below.)

Feature/crash fix patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
http://svn.swordofmoonlight.net/data/my/model/ARM.MDL

I was about to possibly put out a new release but in the last minute I somehow crashed the program in a way that hadn't happened before, so as a result I want to patch this crash that was introduced in the previous patch, and as it just so happens the patch includes what would be in a new release, so I'm possibly just going to keep rolling things into this release via patches.

I may make a blog post with or without a release. I will have to see what I feel like doing.

The crash happens in the jump system because I had it to read past the end of a buffer. It's a wonder it didn't show up until weeks later, but that stuff just happens.

This patch includes the new 60fps code I've been working on for a long time, and it changes how the arm is displayed when attacking, so I've included a new-and-improved ARM.MDL file (link above) that you want to make sure is in your DATA/MY folder.

This ARM.MDL is a lot better but the animations are identical to the old one. I think that its animations should probably be changed too, eventually, but what to change them to is a major decision I can't deal with right now. I do think the chop should be centered and not twist around. The thrust seems pretty lame too.

A lot of work has gone into this upgrade to 60fps animations and effects. The attack animations now have four times as many frames, but to do that they are blurred together to form a sweep of afterimages. And the transparency effect used is not great, but it's the same as the one for fading things in.

I definitely want to program a better system for the transparent elements before long. By that I mean a full BSP triangle sorting/partitioning system.

If you can take time to browse my contemporary posts in the forum I'm working on numerous things, but mostly model editing and model conversion tools. That work is beginning to wind down. I feel like I've been working on this for a very long time now. So hopefully I will finally see the light at the end of the tunnel and be able to prepare a new demo of my KF2 project.

I'm hoping that once all of the technical pieces are in place the project will almost finish itself. The problem solving stuff is all on the front end. The art already exists, so it just has to be transferred over as fast as my legs can carry me. I don't expect to have a final version by the end of the year, but I want to have a playable version of the full game.

EDITED: Please refer to this (http://www.swordofmoonlight.net/bbs2/index.php?topic=309.0) older topic/thread for patches. Usually I put patches in the newest blog post discussion, but I've opted this time to not make a new release.

 5 
 on: August 02, 2020, 09:21:52 AM 
Started by Holy Diver - Last post by Holy Diver
Feature/crash fix patch

http://csv.swordofmoonlight.net/SomEx.dll/1.2.3.2.zip
http://svn.swordofmoonlight.net/data/my/model/ARM.MDL

I was about to possibly put out a new release but in the last minute I somehow crashed the program in a way that hadn't happened before, so as a result I want to patch this crash that was introduced in the previous patch, and as it just so happens the patch includes what would be in a new release, so I'm possibly just going to keep rolling things into this release via patches.

I may make a blog post with or without a release. I will have to see what I feel like doing.

The crash happens in the jump system because I had it to read past the end of a buffer. It's a wonder it didn't show up until weeks later, but that stuff just happens.

This patch includes the new 60fps code I've been working on for a long time, and it changes how the arm is displayed when attacking, so I've included a new-and-improved ARM.MDL file (link above) that you want to make sure is in your DATA/MY folder.

This ARM.MDL is a lot better but the animations are identical to the old one. I think that its animations should probably be changed too, eventually, but what to change them to is a major decision I can't deal with right now. I do think the chop should be centered and not twist around. The thrust seems pretty lame too.

A lot of work has gone into this upgrade to 60fps animations and effects. The attack animations now have four times as many frames, but to do that they are blurred together to form a sweep of afterimages. And the transparency effect used is not great, but it's the same as the one for fading things in.

I definitely want to program a better system for the transparent elements before long. By that I mean a full BSP triangle sorting/partitioning system.

 6 
 on: August 01, 2020, 04:33:36 PM 
Started by Holy Diver - Last post by Holy Diver
I thought I was almost done here until yesterday I realized I still had to ensure the new MDL files are in this "modern" configuration, and it turned out to be a bit of work that I was just able to see-through today.

I also to the opportunity to find out about some of the last details of the format to see if it was possible to mark the new files in some way. I ended up setting the 4th bit in the first byte of the file to mark it. That makes it easier to not attempt to convert them as if they're in the old-fashioned style.

I also found out that there is possibly some extra data in the rigid animation data that almost looks like a way to extend the format. But I tried to use it to make extra space in the file and it didn't fully work. That means either some part of som_db.exe doesn't respect this extensibility feature, or it could be that there is actually supposed to be something in that extended region and I just don't know what goes there. The program didn't crash so I can't get an easy hint at what code is failing.

Luckily setting the 4th bit seems safe. Interestingly the first 2 bits are tested for rigid animations, instead of just the first bit. That suggests maybe there's a third mode. When I set the second bit the animation plays but the geometry attached to the skeleton is garbled like a mess of triangles.

I had hoped that extracting the skeleton in the style would be simple, but it seems like it's pretty difficult to do. But the process is identical to what x2mdl already does before outputting the MDL file, just in reverse. So it's not disproportional, but it's not cleverly simple either. In order to prepare the data it's necessary to convert it all into global space, just as if you were playing back the animation, and then apply the skeleton to that data, and then convert it back into local space. The algorithm for doing that is pretty involved, but it's the price to pay for the files being backward compatible.

I've chosen to not store the skeleton inverted, but if I did it could be simpler. I just think that the skeleton section should be straightforward and recognizable as a skeleton and you can reason that if the model is stored in a way that can displayed without animating it (as SOM_MAP does) that somehow the animation can be mapped back onto the skeleton.

Converting a MDL file into another format should be a last ditch effort. It's not meant to be an art format. Models should be saved in a master format.

I also developed a back door for repairing any files made with old versions of x2mdl. Until this year my understanding of the MDL format was incomplete.

 7 
 on: July 29, 2020, 04:26:16 AM 
Started by Holy Diver - Last post by Holy Diver
Attachments * 60fps swing effect.png 
Yesterday I ended up working on the problem of the swing (attack) animations being underwhelming or ghostly. I tried about 5 or 6 different strategies and compared them all and unfortunately none of them hit it out of the park. I learned that displaying a graphic like this (whizzing by your face) is actually very hard to do without dedicating an entire effects buffer to it, which is against how I think about SOM's design ethos.

But in the process I identified other problems which made me more concerned than the fact that you can't really get a feel for you weapon as flashes before your eyes. I wish you could see your cool weapon in all its glory but in general if you slow the attack down to do that it looks too slow and if you try to remove blur it looks too choppy, at least at 60fps. The only fix might be to disable do_aa and use traditional AA and maybe use a 120fps display?



So what I observed is the gap between the ghost images is too great. To close the gap so that the "swoosh" feels more solid and not like a "Triple Fang" sword I realized I could use the animation upscaling system from this topic/thread on the arm model, and that would generate between frames. Previously it was exempt from upscaling because SOM already plays back attack animations at double-speed. I'm not sure why but probably so artists can get a good look at the animation in their editing software.

But the problem then is there's too many frames of animation, so I'd already been trying to increase the number of afterimages, so all I had to do was add an extra afterimage to the mix.

And finally, I realized the fade-in effect used when models "spawn" could be used to change the transparency of the afterimages. I also realized this effect can be improved, but it will have to wait. When the spawn effect is improved it should improve the swing effect too. But the swing happens fast in your face so you can't really take in the detail and you don't see the transparency artifacts. (Although it's possible there are bigger problems, I don't know, but when I swing the knife in KF2 (my project) in front of water the handle is mysteriously missing and I can't convince myself if it's just depth-sorted to be behind the hand and that's enough to make it invisible or what. It's visible over land. Anyway, I noticed the knife handle is comically small and I will probably enlarge it at some point.)

This effect is complicated because of the dissolve extension (do_lap) that do_aa uses means there is really two screens blended together 50/50, so what really happens is each screen has 3 images of the swing graphic and the last image of the previous frame coincides with the first image of the current frame so that this image in the middle is the strongest. The transparency is biased so the first image of the previous frame is the lightest afterimage. So there are 5 images on screen at once, and the first is the lightest, the next is between the first and the third, and the third (middle) is the strongest image, that maybe you can see if the weapon is bulky enough (usually it helps if the weapon is light on a dark background or vice versa) and the last two images don't exactly mirror this but they get fainter, but not as faint as the first.

So it kind of looks like a tail but the 4th and 5th image are kind of premonition of the most solid image taking their place. I'm not sure how the eye works but I do think it registers afterimages on a delay so you can see a ghost image in front of something that's just beginning to register but afterimages definitely have a tail, but we just have to accept that the dissolve effect is the way it is in this case.

I can't improve on this except maybe to try slightly different transparency levels. You can't choose just any transparency you want for the images since they interact in a complicated way and most combinations would not have a bell shape curve. If it looks good or not can depend a lot on the animation. The original chop animation is generally not good because it twists in a way that makes any sword look like the Triple Fang and because it doesn't keep the blade on top of itself the afterimages don't stack and it tends to look like the blade is missing aside from the faint triple-fang image.

The Moratheia demo's animations look very good in the new system because their swords tend to slice directly down the middle of the screen, which is probably ideal, and they don't twist, so they tend to have a strong diagonal line. But you still only get an impression of the weapon. I wish you could really see it clearly, but all told I think that's not the largest priority. It would give the games more charm but I'm not sure it's even possible at a high frame rate. It might depend on the monitor.

Edited: Oh yes, another benefit of these afterimages is the low-poly arm model up in your face gets smoothed out a lot by being superimposed so many times, so it can't be distracting. And I think being more ghostly and smooth helps to make it kind of fade into the background.

 8 
 on: July 28, 2020, 04:55:36 AM 
Started by Holy Diver - Last post by Holy Diver
Update

What have I been up to? I've been continuing to work on editing facilities for hierarchical MDL data.

I think I have a new release reflecting the contents of this topic/thread but I think I want to include some changes to the arm model at the same time, and that just so happens to represent an opportunity to use the new hierarchical MDL editing facility.

Yesterday I edited the ARM.MDL file significantly. My starting intentions were to fill in the hole in the shoulder and recalculate its lighting "normals" so it looks organic instead of like a copper knight from KF2!

The changes I'm making to the arm model display in the game is to bring SOM to be more in line with KF2. I think the arm model doesn't look very good in SOM. I don't know if its animations are identical to Shadow Tower or not (its model is) but I find them very underwhelming.

SOM puts the arm very low below the screen so that you can't really see it, and it's noticeably relegated to the right half of the screen, whereas KF2's arm tends to be centered in the screen. I've heard people remark that SOM's arm doesn't feel good like KF2 and I pretty much agree. In general I'm laboring to make SOM more of a beast of KF2 than its original incarnation. Maybe this is just my preference but I tend to think this is an improvement.

After trying out SOM's ARM.MDL at the same position as the KF2 model you can see much more of the arm and for some reason the bicep part of the arm looks gigantic. I think that's probably to do with it being right up in your face. I don't know exactly. 3D graphics can be weird that close up.

What was immediately apparent is model is too low-poly for being that close up. The bicep looks like a distorted wooden board. When I was working on it (this is the first time an original MDL has been edited, which is a milestone in its own right) I also added some new vertices so that the texture map would sit flat in places. But after seeing it in the game I had to go in and double the number of polygons on the visible part of the bicep so that it's recognizable as an arm up close...

Plus a weird effect on the shoulder is if it's low-poly and visible on screen, while it's rotating the silhouette of the low-poly looks kind of like a very low-resolution wave-form, or like an equalizer graphic showing music playing, which is not what you expect from a round body part, and is extremely distracting. So this necessitates having a higher poly-count on the shoulder. Maybe ideally the shoulder shouldn't be visible at all, but it's not a problem if it's round I think. I'm just beginning to innovate on the arms. I think because of SOM's style of not keeping the arms out and visible (which I hate in games) might benefit from pushing the arm forward while swinging and pulling it back as the swing completes, as if the shoulder is moving forward in front of your character's face.

But the bicep still looked huge at this point. I mean like a beach ball. For some reason the subroutine that draws the arm sets its scale factor to 1,1,1 and earlier I'd played with it, and I thought that it was only affecting the bicep at some point. So I stopped doing that.

But I realized maybe that could be useful to just isolate the bicep and scale it down.

But when I did this I realized that the scale factor was global and not in fact just affecting the bicep.

So I did a little digging to set up a feature that just scales the bicep, and obviously not along its length.

So, now I think, since I don't want to modify the ARM.MDL model in this regard and because the bicep's huge appearance might just be an optical illusion, what I'm looking at is setting up an extension that lets you to adjust the bicep's size.

And as you can imagine, you might use this to relate on screen how strong your character has become according to their Strength rating.

But I found setting it to something like 70% scale looks more like an arm. I think that this wasn't a problem SOM's designers had to contend with since you can't really see the bicep in the original style.

Like I say, I also don't like the attack animations, and I may very well change them at some point to use the KF2 animations, but probably the timing will have to be adjusted. But I don't think I'll do that before the next release drops.

I have to patch this arm before I can do another release. The new 60fps animation makes the attacks look mostly like a blur of light. I think that's actually realistic. It's what I see when I wave my arms in front of my own face... but I don't know if it's what people want from a video game, since they may want to be able to see their weapon and attacks. It's possible From Software knew this and that's why the animation system is designed to expose an image at 30 fps, I don't know. At 60 fps with 30 fps animations the animated images are double exposures. I worried that it wouldn't look the same, but now I'm accustomed to 60 fps and when I fall back to 30 I do notice the animations and they seem bad to me. I guess my brain had just gotten used to it?

Anyway, I will probably experiment with drawing the arm/weapon twice when using the dissolve extension (it motion-blur style blends two frames) so that it can be less ghostly. That's counter intuitive, but it should make the arm/weapon stand out instead of disappearing into a motion blur. But there will be ghost afterimage behind it.

If this looks good I will probably keep it as a default, since seeing the weapons and equipment on your arm adds character. When KF2 ran at like 15 to 20 fps on the PS this wasn't a big problem I think.

Anyway, I've made progress on the art tool chain, even though it's kind of my private tool chain, but I intend to collect it and publish it somehow with my KF2 project. If anyone wants to use the tools you can contact me in the meantime. I've identified and corrected a number of issues with the old x2mdl command-line tool. The only big projects left is to add scaling animation support to it and to add soft animation support to the cpgen tool. I'll have to do that to finish my project's doors probably this week sometime.

It's been a long road to take the art tools to the next level. It represents the largest chunk of my work so far this year.

 9 
 on: July 23, 2020, 11:04:55 AM 
Started by Holy Diver - Last post by Holy Diver
Attachments * MM3D skeletal MDL.png 

Signs of progress in the editing software (attached). I added a feature to change how some of the "bones" are displayed. There was a line mode, but now it's possible to mix "bones" with "lines" in case the line mode is more appropriate. Having giant bones dragging on the ground between this guys legs was a bit disturbing. (It has to be set up by hand since the conversion tool isn't able to make that call.)

 10 
 on: July 18, 2020, 08:06:24 PM 
Started by Holy Diver - Last post by Holy Diver
Attachments * MDL before & after.png 
After a full week of butt kick hell I present to you, voila:



This animation in particular proved the most difficult since it works like the skeleton's death outro. It may be more complicated by the fact that this model has a rotation in its initial pose. There may be some more wrinkles among the MDL files but I think if so they'll be few and minor trouble to fix. But I'm not adding code for hypothetical files since this work is purely to salvage the original MDL files. It's been multiple days of work, but it doesn't matter, since I'm committed to SOM. I do regret the time it's taken off my KFII project's deadline and that I'm trying to publish a new demo.

This just completes phase 1 of this project. Hopefully the rest is not as time consuming and frustrating. I should add that it's a blessing that these models are in this convoluted format (notice how crazy the transform stack is and how many unnecessary nodes there are) since they could've been in a format that could have also been disorganized but also impossible to automatically extract a meaningful skeleton from, in which case it could've been a great loss. So, in a way this is another bright spot along SOM's golden path. The MDL format isn't an editing format. In run-time formats it's common to discard unnecessary information, but usually these days skeletal model formats are organized in terms of an explicit skeleton.

Going from how these files work it seems like the tool they were developed in could represent a skeleton but it could also "parent" skeletons or objects to objects instead of joints in the skeleton. That produces these weird spiky results. I don't know if it's just how the software works or if it represents the habit of SOM's artist(s) or some post-processing software.

Pages: [1] 2 3 4 5 6 7 8 9 10