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.

 
 

Author Topic: 60fps animation, etc.  (Read 442 times)

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« on: June 19, 2020, 08:57:59 AM »

Today I had an idea of a simple way to try to get the animations to run at 60fps, since it's kind of weird for them to be updated every other frame.

I thought I'd just eventually get around to rewriting the animation system, but I thought that would be a big hairy job so it's something I would put off, that would eventually detract from other little projects.

It occurred to me that a week or two ago I was trying to figure out why when Windows hiccups and causes the frame rate to dip down for a split second that this was so disruptive. One of the things I did (which I don't think has been published) was to think about the fact that it's been using triple-buffering for a while. I don't understand why triple-buffering is necessary or helps with Windows but I found out a couple years ago now that using it was key to getting steady frame rates.

That could be either just a quirk of my drivers or Windows's compositing scheduler, but as I understand triple-buffering it just buys you a little extra time if copying your buffer to the frame buffer is causing you to drop from 60fps to 30fps, but it seems more profound than that to me, as if the scheduler is just unreliable and seems to have an easier time if it has the extra slack in the system.

Anyway, the problem with using triple-buffering is the idea of a frame-rate becomes totally squishy, so I wondered if I should be averaging out the frame rate measurements since with triple-buffering you don't actually know when the copies happen and you can't meaningfully deduce anything by measuring time between handing the buffer off, although in practice the scheduler does a good job of keeping it stable, especially considering that there's no real coordination with it, and triple-buffering is treated like a black box, which is the impression all writing on the subject and documentation gives of it.

But the only reason I'm talking about this, is because I needed to change the timing to factor in the averaging, I was already well positioned to think about the difference between the real frame rate and the rate that the world is updated, which is not the same.

I decided at the time to greatly simplify how this is done because I was very skeptical of the side effects of how I found out SOM works in this regard, which could be a whole other longish post, but the short of it is I switched it over to only doing one "step" per cycle of the "main loop", which I'd already done long ago for the clipping phase. Honestly the gymnastics it does are very dumbfounding, and maybe I suppose only made sense back in the day for some reason, I'm not sure. Most of it wouldn't come into play unless you drop below 30fps, which I consider unacceptable today.

Part of the change was I decided 30fps should be the bare minimum frame rate so that anything below that would just switch over to slow-motion style, like how the PlayStation does it.

What I realized today is another way to look at the animation problem is to just double the length of the animations when they are loaded from disk. Then in this way, when running at double-speed they playback at the right speed.

I already did this for the soft animations, which is pretty trivial. The other kind will actually be a lot more work, but should still just be a quick afternoon project.

A benefit of doing this now is there are actually a number of things that run at 30fps and part of upgrading to a 60fps heart beat so-to-speak is tracking them all down and fixing them, which is the larger project in fact.

I'm going to see how far I can take it, and then leave the new mode as a "Bugfix" option that must be manually turned on until I'm confident it's ready to make automatic.

The only thing that seems to need to run at 30fps is the flip book style image based animations, since at 60fps they just look like a blur. I guess if the number of frames were doubled it might look alright.

I wondered if 60fps might be worse for the do_aa extensions, but I haven't noticed a problem, so I'm sure it's better for them than being out of sync with everything else.

The analog control system seems to not work very well at 30fps, and I can't really guess why exactly. Right now I haven't found a reliable way to put the system into 30fps mode, artificially. But when I did get it to that it seemed okay, but it feels pretty bad when the frame rate is unstable, and I'm not sure if that's to be expected or if I've neglected something since I've been working with 60fps for so long.

Honestly, I hear that games often run at 30fps on purpose, but I swear I don't know how they do it, because there's no obvious way to do that with Windows 10. It wants to run at the monitor's refresh rate, and I suppose that makes since if you're not in dedicated full screen mode, which I thought was a dinosaur by now since people expect to have access to so many things on their desktops.

The switch to 60fps animations is not a radically different experience, but I reckon that maybe for VR it'd help to have a higher update rate there. It just feels a little smoother in a subliminal way. It might help with the swing animation a lot if it doesn't run at full speed.

Right now the attack magics do everything at double speed and I don't know if I intend to fix that or not. It's a little different but not unpleasant. It feels powerful. I don't think the fireball flies faster, but it certainly spins faster. Some things are hardwired and others take the frame rate into consideration. Anyway, it's long bothered me to know that the animations aren't 60fps. I'd like to fix that for my next demo, since I'm trying to put my best foot forward.

« Last Edit: July 14, 2020, 06:47:24 PM by Holy Diver »

Holy Diver has 2452 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #1 on: July 07, 2020, 03:11:14 AM »

Just a random update on the animation sample rate post (#60) I now have the rigid body animations working and most of the important things, and it makes a big difference for doors to be smooth (not choppy) in opening, so I think I'm going to go ahead and turn on the fix by default.

I learned and relearned some things about the rigid animations I wasn't expecting. I really need to get some of the stock ones into my new 3D modeling software so I can look at their data up close. I still have to program their conversion to the MM3D format I'm working with for my KF2 project. KF2 doesn't really use them, however I need to look at SOM's doors to figure out how they work so I can finish KF2's doors.

When I first enabled the double-length animations I was surprised the doors were all bent backward (ajar) when they're sitting still, but after opening them they would become like normal, from then on. This is because there are actually two dummy frames in these animations. I can't think of a legit reason for two. But it's something I once knew since it's factored into the database code in this site, and I remember looking at the code that does it before.

Another thing I noticed is there is actually a system in place for scaling in the rigid animations. It works a little differently. None of the models that come with SOM use it. Instead of accumulating the scaling overrides the current scale. The XYZ directions are independent and scales are limited to just slightly less than 2 times because the values are encoded in a single byte. If you wanted to go larger it might work to chain together two or more channels, unless scale isn't inherited, which would make it exceptional.

Back to the second dummy frame, it's possible there is like a master dummy frame in the first animation only. The parent mapping is only in the first frame, which is another odd design choice. There is code that singles out that frame, and all animations begin by processing two dummy frames. But it's strange that the doors look fine after they're animated the first time (no longer bend backward) so I'm not entirely clear on what's going on there, and in fact I found that omitting the second dummy frame (treating it as a regular) frame seemed to help the closing animations to come to a smooth stop. Although I've seen them land hard anyway before too, which may be triple-buffering dropping a frame or something...

So, I've gone ahead and am currently doing this in the unpublished code. The point of my story is it's all very weird. I have a feeling being so weird, the code around animation may be a little "schizophrenic" in places. But I know that the double dummy frame thing probably isn't accidental because the doors don't initialize otherwise, and bending backward can't be explained any other way than the first dummy frame must position the doors bent backward, so that the second must undo that. In which case I wonder if the first is supposed to be a pose of some kind? But if the doors are bent backward it's a little ironic that they don't really bend that way. The biggest problem all of this poses is converting models to the MDL format is more complicated than it should be. I don't think my x2mdl tool actually accounts for this. Technically it's just beginning to shape up.

I also figured out why peoples models come out of x2mdl with all of their body parts clustered around 0,0,0. I couldn't understand until it happened to me. I realize now that the reason SOM's files don't do this might have more to do with them having dual animation channels instead of just that they're not using a "skinning" paradigm. I think that the first channels are probably just moving the body parts into the skeleton's local spaces around it's joints, effectively doing the same thing as clustering around 0,0,0. It's possible I knew this once too.

This clustering problem comes up with skinned models because of the "deboning" processing step I wrote that undoes the skinning actually outputs this kind of model in the most basic cases. So what I intend to do is to have the pose system to always kick in (currently it's opt-in) and by default to just apply the skeleton to the model to undo the clustering. This should be a more user-friendly experience... when it's finally officially published in some form... maybe before the end of the year. (For the record, "x2mdl" has been around since the very beginning when I first began working on SOM, and if it had gained enough users I might have focused on it more. I worked on it early on because that's what people said they wanted, but after they had it there wasn't adoption, or an explosion of animated SOM models, so I guess it was a bust. I've always regretted there isn't a community of users of SOM.)
« Last Edit: July 14, 2020, 06:48:08 PM by Holy Diver »

Holy Diver has 2452 posts

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #2 on: July 08, 2020, 11:56:37 PM »

Quote
None of the models that come with SOM use it.

I spoke too soon. Luckily I found out from the Moratheia demo some SFX files do use the scaling facility, or at least one does. It makes sense, but I think a lot of them still use the soft system to scale.

Most of yesterday and today I've been poring over the SFX system to try to make as much of it agree with the 60fps system as possible.

That started out with the candle flames that need to run at 30fps. I think for them 30fps is actually ideal with the dissolve extension operating, since it makes every frame between movie frames a dissolve of two most recent movie frames.

Luckily all of these movies use the same SFX procedure except for the lightning bolt strike has one that's timing was actually hard-coded into the program, so it can't be changed with the SFX entry. I don't know if it actually needs its on procedure or if it's just a primitive version of the same effect that never got retrofitted.

The dragon magic needed help since for some reason it is different every other time it's used, so that on odd times the head just a little way out of the ground, and I guess the other times it's cut short, but you can't really tell. Extending its run-time solved the problem.

There's probably others like that, but I didn't really see anything much. Many of the effects actually don't look so great at 30fps, so it's probably better to just leave them alone, but it's a little unsettling to have a mix of effects. But the SFX system is not up to the standards of the rest of SOM so I reckon it needs to be fully replaced with a new system someday. It's a black box instead of modular like the rest.

This has taken a lot of my time but I'm glad it's done. It will be in the next patch I put up. I'm sure some problems will turn up but I think the pros outweigh the cons.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #3 on: July 14, 2020, 07:05:23 PM »

First of all, I've split this topic from the "Random News" board since it's grown longer.

It's taking me a little while to determine how best to interpret the rigid animation format's oddities for purposes of converting it to the new editor friendly MM3D format and determine if the player is buggy or not in terms of playing back these animations.

It's hard to describe the problems with the format in nontechnical terms. It's not the data isn't understood and it can't be animated, but there's issues around making sense of its conventions and transforming those conventions in order to salvage the format since they're basically unworkable outside of the environment in which they were developed.

Right now I can't publish anything because I want to first do some work on the ARM.MDL file that comes with SOM to bring it in line with some changes I'm trying include in the next patch or release. The biggest issue with this model is its shoulder is sawed off for some reason (probably to hide it beneath the bottom the screen) and it uses hard lighting facets, which just seems like poor craftsmanship on the part of SOM's team.

I'm looking at changing how the arm is displayed to reflect King's Field II and the other KF games, and I'm thinking about fixing the field-of-view for the arm graphic just to make things simple. This change shows a lot more shoulder. The shoulder thing has been a problem for years actually, ever since I added the do_arm extension that can reveal the hole in the shoulder.

Editing SOM's animated models has never been feasible before, so the arm is just the first on the list of fixes that should be possible after I can complete this work.

I'm also looking at doors. The double door model I chose to use as a subject of my investigation has a ridiculous number of "control points" (CPs) so I have to determined what are its real control points. The code I've seen in the program only seems to be interested in four per door. It's possible the other CPs are just junk. In theory 2 CPs can describe the doors. (The file shows more like 10 or 12 per door.)

Yesterday I noticed the turn rates were too fast at 60fps and so I tracked down a constant pegged at 30fps that seems to determine the rate of things in the SFX system, apart from animation playback. I also found out the NPC turn rates are in the PRF files, however the monster rates are set in SOM_PRM. So they're fixed, and I need to add a way to edit this to the NpcEdit program.

I had two days about two days ago when I couldn't work on SOM stuff, but otherwise it's just been going very slowly since it's tricky waters to navigate around the MDL files and I don't want to miss anything or make a bad choice. I worry I'm not getting my KF2 project finished.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #4 on: July 28, 2020, 04:55:36 AM »

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.

Holy Diver

  • Website System
  • Administrator
  • *****
  • Offline Offline
    • MaleView Profile
    • About/Support Me/Sword of Moonlight
look out honey, 'cause I'm using technology
Holy Diver says,
« Reply #5 on: July 29, 2020, 04:26:16 AM »

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.
« Last Edit: July 30, 2020, 06:03:22 AM by Holy Diver »

Holy Diver has 2452 posts