I'm designing a 3D game. I have a question about object animation. My question is in case i ensure the 6o FPS game run (on some today's average machine) the distance object is being moved (for e.g. in screen pixels) doesn't matter just because the games frames runs 60/sec? Or maybe if the distance will be to big the animation seem be skippy/not fluent despite that 60FPS?

I know that It's rather newbie/trivial question but PLEASE don't down-vote, just try to explain. Thx:-)

I'm not sure that I fully understand your questions, but, presuming that the frame-rate remains at exactly 60fps throughout, animation should remain as fluid as designed.

The overall scale of the distance moved should have no real effect, I would think. (At least until you get to literally-astronomical distances, or extremely small ones.)

However, here's the thing: it is, I think, very unlikely that you'll get exactly 60fps throughout. You might get 59.5 one frame, then 60.1 another, and 59.7 the next, and so on. And that can indeed result in animation seeming no longer fluid.

As a result, it may be wise to incorporate the time since the last frame (the “delta-time”) into your animation and/or movement code.

Derek911 said:
Or maybe if the distance will be to big the animation seem be skippy/not fluent despite that 60FPS?

While we can say 60fps is in general enough to make a smooth impression of animation, we are still just point sampling time, with the usual problems:

Some object moving at constant velocity may cause a recognizable sampling pattern, e.g. object (or background) moving 1,1,2, 1,1,2, 1,1,2, … pixels every frame. So you see a larger jump every 3nd frame, and the animation does not appear smooth.
To avoid this, many games try to link animation speed directly to framerate, which quantizes the available speeds they can use. E.g. 1, 2, 3 pixels per frame, but not 2.7 pixels per frame.
This was especially common in older games. Even resulting in games running at different rates depending on the TV norm of the country, like 60Hz in US but 50 Hz in Europe for the same game.
Often even the CPU had a different clock per region to adjust to TV refresh rates.

Today it is much more common to ignore the issue, and just hoping high FPS are good enough. This works because FPS became higher with time, but also because physics became more complex, replacing constant velocity movement of Pac Man with acceleration causing variable velocity of Super Mario.
But especially for 2D games with a scrolling background at constant speed the problem is still very noticeable and a (minor) issue.

Besides linking speed to refresh rate, we now have a new option, addressing the point sampling limitation directly. And that's motion blur.
We can make a fake motion blur effect from one frame and motion vectors (very common), or we can blend multiple renders at different times and compose one image form all of them per frame (very rare).
So instead sampling just one moment of time for the period of time a single image is shown, we now take multiple samples. It's expensive, but the correct solution to the problem.
Or we try to achieve the same result with just one render and smearing moving objects, which already helps a lot but has disocclution artifacts. Artifacts would be less acceptable in 2D than in 3D.

Sadly i have never seen 2D games using motion blur, although i'm convinced it would feel much better, and GPUs are powerful enough to do even full multisampling.
I would be very excited to see this. If anyone knows some exceptions, let me know… : )

JoeJ said:
Sadly i have never seen 2D games using motion blur

Ha, i just remember: I myself made such game : )

I did it for the ball in this game:

The ball could become fairly fast, so i rendered it N times with additive alpha blending. It felt very smooth, independent of the balls speed. When it was very fast, it started looking like an egg more like a circle.
I have used alpha blending also to achieve anti aliased edges of the blocks.

Image quality was high, but success was not… :D

For myself, I… generally don't like motion blur in video-games; I prefer the view to be nice and crisp.

(Note that, if I'm not much mistaken, there's little such blur in human vision--some, but not much. The heavier blur that may come to mind is perhaps an artefact of familiarity with cinema, the cameras for which are I gather more prone to blur than is a human eye, and where it helps to cover the relatively-low frame-rate.)

Returning to the main question, it hadn't occurred to me that we might be talking about pixel-perfect movement, which was perhaps silly given the mention of pixels. ^^;

In that case, indeed, I'd be inclined to suggest movement-speeds that are integers when measured in pixels-per-frame.

Of course, if the frame-rate varies then once again there's likely to be some unevenness in the animation, I fear.

Hmm… Which may be covered, to some degree at least, by an intentionally low animation frame-rate: Let's say that we have an animation running at 6 animation frames per second, i.e. with ~0.17s between animation-frames, and 10 rendering-frames passing per one animation-frame. Then the difference between a rendering frame-rate of, say, 58FPS and 60FPS--i.e. between ~0.0172s and ~0.0167s per rendering-frame, coming to ~0.00054s, is a small fraction of the total time per animation-frame--specifically, about 0.0032, or about 0.3%. As a result, the variation might be less noticeable.

Thaumaturge said:
For myself, I… generally don't like motion blur in video-games; I prefer the view to be nice and crisp.

(Note that, if I'm not much mistaken, there's little such blur in human vision--some, but not much. The heavier blur that may come to mind is perhaps an artefact of familiarity with cinema, the cameras for which are I gather more prone to blur than is a human eye, and where it helps to cover the relatively-low frame-rate.)

Most people don't like blurring effects, but that's caused from exaggerated use of it, i think.
For example, we could generate a blur along motion by always keeping the last two frames, and displaying a mix of those two plus the current.
This would give us an effect of motion trails (but also lag), like i have used in the title screen of my game. Or the unwanted ghosting effect of TAA, which is the same thing.
That's not what we want for correctness, agreed.

Real world cameras do better, but rarely perfect. Afaict, they have their shutter open for a period of time. Setting this time affects both motion blur and exposure. The longer the shutter is open, the more light accumulates on the image sensor.
So if they use a period which is half as long as the frame to get the right amount of exposure, they capture only half of the time period they want to get the correct amount of motion blur. The resulting animation is much better than having no MB at all, but it's still not really smooth either.

For offline CGI it is common to use the whole period a frame lasts, which is ideal. It samples a temporal segment of signal we try to capture, not just a simple point in time, which is right.
I assume, if you can do this correctly, you won't find many people who complain about the blur. They should not even notice the blur. They should only notice the animation looks smooth, and the quantization to still image frames is less noticeable then in other games.

That's tangent to other truly subjective things, like DOF on / off, sharpening filter on / off, or general preference of sharp vs. smooth images.

Thaumaturge said:
it hadn't occurred to me that we might be talking about pixel-perfect movement, which was perhaps silly given the mention of pixels. ^^; In that case, indeed, I'd be inclined to suggest movement-speeds that are integers when measured in pixels-per-frame.

But that's a very hard limitation on game design. Nowadays things mostly have to move at gradual speeds, like in the real world. But if we still want smooth animation for that at low FPS, MB is the only option to get it.

Thus, even people disliking blur in general should keep open minded about MB. I mean, currently we can not really afford it, mostly. But the time will come, assuming chips can still shrink a bit.
And the current standard is not bad either. Most games have SS MB, and it helped a lot with making them appear smooth when this came up.

But i really miss it in 2D games. Playing a Super Mario clone a lot, my biggest issue with it's gfx is not the old school pixel art, but the chunky background scrolling.
I'd love trying to fix this with MB, but not entirely sure how noticeable the blurring would be.

Thaumaturge said:
Of course, if the frame-rate varies then once again there's likely to be some unevenness in the animation, I fear.

Which even MB can not fix. I have no variable refresh rate display, but i don't believe this can fix fluctuation in frame rates either. It may however help if you miss the 60 fps target just slightly, e.g. when getting just 50 fps for some time.
I also doubt blowing 30 fps up to 60 with something like DLSS3 frame interpolation can help much. This only makes sense if we already have 60 fps, but eventually a display supporting 120.
We really want a high, stable and constant frame rate first, imo.

Thaumaturge said:
Hmm… Which may be covered, to some degree at least, by an intentionally low animation frame-rate: Let's say that we have an animation running at 6 animation frames per second, i.e. with ~0.17s between animation-frames, and 10 rendering-frames passing per one animation-frame. Then the difference between a rendering frame-rate of, say, 58FPS and 60FPS--i.e. between ~0.0172s and ~0.0167s per rendering-frame, coming to ~0.00054s, is a small fraction of the total time per animation-frame--specifically, about 0.0032, or about 0.3%. As a result, the variation might be less noticeable.

Yeah, as you said earlier:

Thaumaturge said:
As a result, it may be wise to incorporate the time since the last frame (the “delta-time”) into your animation and/or movement code.

We want to sync to real time, no matter what's the actual frame rate. This also includes animation and physics interpolation / extrapolation. If the animation has a key frame only each second, we likely want to interpolate between key frames. If the physics are 5 ms ahead display time, we need to interpolate with the previous step. That's the most important and will resolve most issues. Though, i can't remember any game which failed on this. It's standard, and everybody gets it right to this point. It's usually good enough, but if we want silky smooth animation beyond that, we either need crazy high FPS or MB. The latter should be cheaper if we accept some error.

Thaumaturge said:
Note that, if I'm not much mistaken, there's little such blur in human vision--some, but not much.

Hard to say, becasue we never know how much the brain improves and interprets our sensor data.
But if i shake my hand, i can see the two positions where it stops and reverses direction somewhat sharply. In between i see arcs where the light hits the fingers. The arcs show the path around my wrist. It's smeared and blurred. I see no individual fingers.

JoeJ said:
Most people don't like blurring effects, but that's caused from exaggerated use of it, i think.

I'm not convinced. Perhaps it's been done subtly, in such a way that I haven't noticed--but that just means that I've never noticed it being done well, and have no examples to turn to. :P

JoeJ said:
The resulting animation is much better than having no MB at all, but it's still not really smooth either.

I think that the resulting animation is better at the low frame-rates of cinema, but I suspect that it's not better at high frame-rates, or in interactive media. (At least for general use; I daresay that it could be used well--"sword-trails" are effectively a form of motion-blur, after all.)

JoeJ said:
But i really miss it in 2D games.

I… really don't! As long as the animation is done well, I tend to find that it works well for me, I think. And adding motion blue would reduce the nice crispness that a 2D game can have.

JoeJ said:
Yeah, as you said earlier:

Not exactly: I was describing two different things there.

In one, we use delta-time to keep the animation in synch with the frame-rate; in the other, we have a fixed frame-rate, but it's low enough that fluctuations in delta-time aren't all that visible.

JoeJ said:
Though, i can't remember any game which failed on this.

Oh, there have been older games that lacked the incorporation of delta-time, I believe. Of course, that results in the rather larger issue that the game runs faster on faster machines--potentially to unplayable degrees!

JoeJ said:
Hard to say, becasue we never know how much the brain improves and interprets our sensor data.

That's the thing: I'm not talking about what the eye detects, but about what we see--after our visual system has worked on it. And I think that--outside of unusual circumstances or particularly high speeds--we generally don't see much motion-blur.

Thaumaturge said:
I've never noticed it being done well, and have no examples to turn to.

Pretty much any UE4 game is an example of good SS MB.

Thaumaturge said:
I think that the resulting animation is better at the low frame-rates of cinema,

Why should real world footage or user camera control make a difference? The concept of achieving the illusion of smooth animation using a series of images is the same for both.
It's more a proof on how important MB is, because a 24fps movie looks smooth, while a 30fps game without MB looks like stop motion animation monster movies from the 50's.

Thaumaturge said:
I… really don't! As long as the animation is done well, I tend to find that it works well for me, I think.

But you can't do animation well if your background scrolling speed won't match framerate. If it scrolls in sequences of 1,2,2, 1,2,2, 1,2,2 pixels, the result is not smooth but chunky. No matter how many nice animation frames you have drawn for the sprites.
And more fps won't fix it, at least not with practical numbers.

The discussion is the same as asking: Do we still need anti aliasing for 4K? or 8K? Unfortunately the answer is yes, as stair stepping at high contrast also creates such patterns with some jumps on the pixel corners of an edge. That's still noticeable even with very high resolutions. Lesser so than with 1080p, but still an issue.
It's the same for temporal issues than for spatial issues. Basically MB is the temporal equivalent of spatial AA. We need it just as much, and we use the same methods to solve it: Multi sampling, or analytical integration of the area under the curve which falls into our pixel or frame.
The pixel or the frame time both represent some area we try to integrate, and taking a single point sample to approximate an area always causes the same issues leading to lower quality.
I don't say that's not acceptable, but it's not a question of personal taste. It's a question of approximations vs. correctness.

Thaumaturge said:
And I think that--outside of unusual circumstances or particularly high speeds--we generally don't see much motion-blur.

Yes. For the same reason you might not consciously notice MB used in many games, aside of extremes like swinging a sword, or moving camera quickly with mouse, etc.
The effect is subtle and will not increase an overall impression of blur (unlike early TAA, or DOF). The effect is smooth animation, nothing else.

Let's try not to have lengthy tangential discussions on a For Beginners topic, please. ?

@derek911 - the answer to your question depends on what kind of animation is being used. Usually 3D animations are done via keyframes which play back at a specific rate. So if you had an animation with a frame rate of 30Hz, and your game runs at 60Hz, then you would have an animation keyframe every 2 updates (60 / 30 = 2) which gives the exact position of the model's ‘bones’ or vertices as appropriate. On the ‘in-between’ updates you'd have to interpolate between the keyframes on ‘either side’. This is all handled for you in most engines and animation packages.

If the animation actually moves the object (e.g. it has “root motion”) then the animation controller will feed back movement information to the game engine, and this too will be scaled by the above proportion of animation-frequency to game-frequency.