Add support for motion blur

[josefkaragoli]

Describe the project you are working on

3D project

Describe the problem or limitation you are having in your project

Godot doesn't support TAA or any other temporal effects so quick motion of objects looks unrealistic and too fast.

Describe the feature / enhancement and how it helps to overcome the problem or limitation

Motion blur would alleviate this by giving a more realistic and predictable look when objects move fast

Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams

This could be added in the WorldEnvironment but more logically the new CameraEffects resource in a Camera.

If this enhancement will not be used often, can it be worked around with a few lines of script?

There is a shader for motion blur https://github.com/Bauxitedev/godot-motion-blur but it doesn't take into account moving objects, only the movement of the camera.

Is there a reason why this should be core and not an add-on in the asset library?

it is core

[Zireael07]

I thought I'd made such a proposal, but apparently not. Seconding.

[josefkaragoli]

I thought I'd made such a proposal, but apparently not. Seconding.

Yes I also thought I'd seen a proposal for this but couldn't find one

Is Godot 4.0 meant to be feature-complete by now? If so then I think this will probably be implemented in 4.1 since temporal stuff doesn't really work well in a forward renderer

[mrjustaguy]

Feature Complete only when it gets to Beta, still in pre alpha stage..
Personally however, I think Godot 4 is IN the Alpha stage, just hasn't been made official.. I mean The level of stability/bugs present in master is roughly at the level of 3.2 alpha in my experience

[Calinou]

Per-object motion blur requires the rendering backend to expose motion vectors, which is not planned for 4.0 but for a future 4.x release.

[josefkaragoli]

TAA and motion vectors are now available

[Calinou]

TAA and motion vectors are now available

Indeed, but I don't think motion blur will be implemented in 4.0 unless a contributor steps up to do the required work. It's more likely to happen in a future 4.x release.

[Lauson1ex]

TAA and motion vectors are now available

Indeed, but I don't think motion blur will be implemented in 4.0 unless a contributor steps up to do the required work. It's more likely to happen in a future 4.x release.

Additionally, current motion vectors implementation is incomplete: no motion vectors for skinned meshes and blend shapes, which defeats the purpose of per-object motion blur.

[Calinou]

Additionally, current motion vectors implementation is incomplete: no motion vectors for skinned meshes and blend shapes, which defeats the purpose of per-object motion blur.

There will be motion vectors for those eventually 🙂

[Calinou]

Some technical considerations if anyone is interested in implementing motion blur in Godot:

• The intensity of per-object and camera motion blur should be configurable separately, and the documentation should advise exposing sliders for both separately in options menus. One big reason why people dislike motion blur in games is that you often can't adjust those factors separately, yet being able to do so makes motion blur much more flexible.
  • From a technical point of view, this can likely be achieved by subtracting the camera translation/rotation speed from object speed in the motion blur shader depending on the chosen motion blur factors for each.
  • To avoid the issue where objects you're trying to aim at become blurred with camera motion blur, we could add a third factor that controls a motion blur fade-out depending on the distance between the pixel and the center of the viewport. When set to 1.0, there would be no camera motion blur at all in the center of the viewport, but full motion blur would remain on the edges. Per-object motion blur be preserved in this case, likely by performing the subtraction with camera speed in motion vectors as defined above.
• The shutter speed should be independent of framerate. This will inevitably cause motion blur quality to change depending on framerate (as the distance between frames will vary depending on FPS), but this is often preferable to having the shutter speed change under your feet if you're playing at a variable framerate. The default value should be tuned to cover gaps between frames at 60 FPS – it should not "overshoot" and blur more than what's needed. In other words, the effect should remain subtle by default when enabled.
  • Remember that how you perceive motion blur depends on your display's response times, and the default values should be usable on displays with mediocre response times.
• Motion blur toggle and properties should be in CameraAttributes resource, similar to exposure and depth of field.
  • Motion blur quality settings will have to go in the Project Settings instead (and adjustable at run-time with RenderingServer setter methods), similar to depth of field.
  • When using CameraAttributesPractical, motion blur intensity is controlled by an arbitrary factor. It could be like shutter speed, but used only for the purpose of motion blur intensity.
  • When using CameraAttributesPhysical, motion blur intensity is controlled by the shutter speed (which also affects other properties in the camera, such as final exposure).

There's a slideshow about implementing motion blur in Call of Duty: Advanced Warfare. This is also the same slideshow that was used as a reference to implement interleaved gradient noise for shadow map dithering in Godot 4.

[Calinou]

@gnat Please don't bump issues without contributing significant new information. Use the 👍 reaction button on the first post instead.

[Jamsers]

From a technical point of view, this can likely be achieved by subtracting the camera translation/rotation speed from object speed in the motion blur shader depending on the chosen motion blur factors for each.

Would also be a good idea to allow subtracting only rotation, or only translation, from motion blur: for first person/third person games for example it's usually good to remove camera rotation motion blur, but you want to keep camera translation motion blur to keep the sensation of speed when sprinting or moving in a vehicle.

To avoid the issue where objects you're trying to aim at become blurred with camera motion blur, we could add a third factor that controls a motion blur fade-out depending on the distance between the pixel and the center of the viewport.

This isn't really a solution to the issue - you'll still see the problem happen on the edges of the screen. Regardless, it'll be good to implement this anyway because some games prefer this over subtracting camera motion blur. Destiny 2 does this I think.

IIRC the true solution to this is a dot product clamp.

The shutter speed should be independent of framerate.

Yes, absolutely, this. Something many many games get wrong, even AAA ones (although in their case probably just not bothering because you can just assume consistent FPS on consoles)

[Jamsers]

Did some experimenting and it seems a simple dot product clamp removes most of the objects you're trying to aim at become blurred with camera motion blur artifacts, but some artifacts do remain 🤔

# Normal per pixel motion blur

pixel_vector

Normal.mp4

# Subtracting camera motion blur from per pixel motion blur

pixel_vector
camera_vector

var cancelled_vector = pixel_vector + camera_vector
	
pixel_vector = cancelled_vector

Cancelled.mp4

# Subtracting camera motion blur from per pixel motion blur, with dot product clamp

pixel_vector
camera_vector

var cancelled_vector = pixel_vector + camera_vector

if cancelled_vector.dot(camera_vector) > 0:
	cancelled_vector -= camera_vector

pixel_vector = cancelled_vector

Cancelled.With.Clamp.mp4

[Jamsers]

For reference, here is the objects you're trying to aim at become blurred with camera motion blur problem depicted in engines that have per pixel motion blur (The engine used in the videos is Unity, but this problem happens in all engines that don't explicitly fix this issue, it happens in Unreal as well for example)

Normal motion blur:

FPS.Normal.Motion.Blur.mp4

Camera rotation cancelled motion blur:

Fps.Camera.Cancelled.Motion.Blur.mp4

Normal motion blur:

Platformer.Normal.Motion.Blur.mp4

Camera translation cancelled motion blur:

Platformer.Camera.Cancelled.Motion.Blur.mp4

[Rawalanche]

By far the most important part of game engine motion blur implementation is dynamic framerate dependent. The motion blur should usually be half the frame width (180° shutter angle), not fixed to a specific framerate value unrelated to the framerate the game currently runs at.

Overwhelming majority of game developers get this wrong, and all mainstream game engines which do have motion blur default to wrong, framerate independent motion blur amount. That's why players almost universally hate motion blur and it is the first thing they disable.

If you have 30FPS motion blur size but the game runs at 120 FPS, you essentially have 720° shutter angle capturing just a single frame, getting hideous, nauseating smearing of the image, that looks even worse than 90's south american soap operas.

While this is how a 180°/half frame shutter would look at 120FPS:

The example above is from UE, which does offer current framerate based motion blur but fails at having correct default to drive developers to use it correctly.

Correct motion blur will be almost imperceivable to most players when the game runs above 60FPS. It won't make image in motion appear any more blurry than when its off. It will just make the motion appear smoother/less stuttery.

The shutter speed should be independent of framerate. This will inevitably cause motion blur quality to change depending on framerate (as the distance between frames will vary depending on FPS), but this is often preferable to having the shutter speed change under your feet if you're playing at a variable framerate. The default value should be tuned to cover gaps between frames at 60 FPS – it should not "overshoot" and blur more than what's needed. In other words, the effect should remain subtle by default when enabled.

Shutter speed absolutely should change based on your framerate. Motion blur is not some FX gimmick. It's not something you turn on to give your game more "moviey" feel. It's literally a simulation of optical system, regardless whether its biological, mechanical or digital, with the purpose of making the image motion appear believably continuous instead of just a slideshow of images in sequence. What you want to remain constant is the perceived smoothness of the motion, not the motion blur amount. If your game drops from 90 to 30 FPS, you really do want to triple the motion blurring amount to maintain the impression of same motion smoothness.

I've seen both game developers and game engine developers get this wrong all over and over again, so I am sure Godot will get it wrong as well. I am posting this here mainly so that I can tell you "I told you so." once you get it wrong as well ;)

But in case you actually wanted to get it right, just keep in mind that having the motion blur setting set to current framerate based motion blur by default is equally as important as having the feature available in the first place. Vast majority of game developers don't have any VFX background so they won't know what they are doing, and just keep using the defaults.

[Jamsers]

By far the most important part of game engine motion blur implementation is dynamic framerate dependent. The motion blur should usually be half the frame width (180° shutter angle), not fixed to a specific framerate value unrelated to the framerate the game currently runs at.

No absolutely not, this is the exact opposite of how to correctly tackle this. Game framerates especially on PC will vary immensely (often in realtime), and even on consoles they'll differ based on whether performance mode or quality mode is selected. Your motion blur should look consistent regardless of what framerate the game is running at - this is especially important for gamers running the game at lower framerates like 30 FPS - their game shouldn't turn into a smearfest (compared to 60 or 120 FPS) just because they can't run the game at higher FPS.

Overwhelming majority of game developers get this wrong, and all mainstream game engines which do have motion blur default to wrong, framerate independent motion blur amount.

This is wrong again, an overwhelming majority of (current) games actually implement framerate dependent motion blur. (This is the most straightforward implementation - framerate independent motion blur requires extra effort.) This is easy to confirm on PC by how much smearier and blurrier the motion blur gets on most games, the lower the framerate gets. Unreal is actually the exception - Unity, for example, has no framerate independent motion blur option.

If you have 30FPS motion blur size but the game runs at 120 FPS, you essentially have 720° shutter angle capturing just a single frame, getting hideous, nauseating smearing of the image, that looks even worse than 90's south american soap operas.

This is probably your (and most gamers) main point of contention - when framerate independent motion blur is implemented, motion blur remains blurry and thick even when you're running at high framerates. And that is an issue that plagues the industry - but the solution for that is for game developers to stop trying to emulate "cinematic" 24 FPS shutter speeds, but rather emulate a high shutter speed, high framerate look, especially in gameplay.

But I understand your concern: considering the game industry's track record, what'll probably happen if framerate independent motion blur becomes the industry default is that we'll all be stuck with super blurry smeary "24 FPS" motion blur, even when we're running the game at 240 FPS.

Really, the motion blur frame rate/shutter speed should ideally be user controllable. But I know even that's probably asking for too much. 🤷

Shutter speed absolutely should change based on your framerate. Motion blur is not some FX gimmick. It's not something you turn on to give your game more "moviey" feel. It's literally a simulation of optical system, regardless whether its biological, mechanical or digital, with the purpose of making the image motion appear believably continuous instead of just a slideshow of images in sequence.

This is at the heart of our disagreement. You're 100% right about everything you said here - motion blur is not some gimmick but rather a fundamental artifact of any optical system that captures light in a finite amount of time, and shutter speed is absolutely tied to framerate.

What you (and many gamedevs) get wrong is that the renderer's framerate is not the same as the framerate of the "camera" you're "shooting" the game with.

Computer generated imagery looks fundamentally "wrong" by default¹, so we reintroduce artifacts like depth of field and motion blur. The characteristics of these artifacts are (or should be) based off a conceptual, imaginary "camera" whose attributes we base the look of these artifacts off of. These attributes are identical to the attributes of an actual, real camera. Godot actually has a framework for defining these attributes.

That means the framerate and shutter speed of this imaginary "camera" are independent of the renderer's framerate! The renderer could be running at 120 FPS, but if the "camera" is set to 24 FPS, the motion blur should look similar to an actual camera shooting at 24 FPS. The converse is also true: even if the renderer can only run at 30 FPS, if the "camera" is set to 120 FPS, the motion blur should look similar to an actual high frame rate camera shooting at 120 FPS.

The renderer's attributes, such as resolution and framerate, are borne out of technical limitations, not out of artistic choice. In an ideal world, games would be rendered at, I dunno, 64k resolution at 20k FPS or something. Your game should retain its look as much as possible independent of resolution or FPS. Otherwise, if your depth of field is resolution dependent, it'll practically disappear when your game renders at 64k! If your motion blur is framerate dependent, it'll practically disappear at 20k FPS!

¹CGI (of which games count as also) conceptually is like filming with a camera that has an infinitesimally small focal length, capturing light in an infinitesimally small amount of time. That's why raw CGI is aliased, perfectly focused at all ranges, and perfectly clear in motion. This isn't realistic and no such camera exists, so we explicitly simulate and add in artifacts like depth of field and motion blur to make it look correct to our eyes.

[Rawalanche]

I am not just a game developer. I've spent quite a long time working as a CG Generalist: https://www.artstation.com/rawalanche And when I worked at VFX studio, we ran into MB related issues quite often. Ultimately, the only thing that worked reliably was always avoiding mismatch between displayed image framerate and framerate the motion blur is computed for, regardless what that framerate is, and even if that framerate changes within one movie/video.

For consoles, the fixed FPS is sometimes fine, if you target specific framerates, but for PC, in vast majority of the games, you have only two options. Either having your game be as you say smearfest regardless of framerate, even if you run at 120+FPS, or just turn off motion blur altogether and get less natural image.

Dynamic framerate introduces the "smearfest" only when the FPS drops severely, instead of at all times. And at such extremely low framerates, where motion blur becomes apparent, (usually under 40FPS), the smearing is actually helpful as it covers up lack of motion smoothness.

What I mean by helpful is that if you play a game at 30FPS, if you disable motion blur, people will usually not consider it to be an improvement in terms of image clarity and sharpness. It will usually be to the detriment of apparent motion smoothness. On the other hand, if you have 30FPS Fixed motion blur and your game runs at 120FPS, turning it off will result in absolutely massive improvement in clarity and sharpness of image in motion.

One more thing to consider is that heavily fluctuating framerates aren't desired behavior. Even for wide range of possible hardware performances, you'd usually want the framerate fluctuation of the game to stay at least within reasonable bounds. Having dynamic framerate would mean that regardless of if player playing the game averages 50FPS or 150FPS, they are getting optimal visual motion blur experience.

So the idea here is to not have to choose between lesser evils

And I am currently working on a RTS game with semi realistic graphics, which uses dynamic framerate based motion blur to great success: https://www.youtube.com/watch?v=oJAYC5lcC4E
https://www.youtube.com/watch?v=_OsxYsjyWfw

There are currently 3 options:

1. Fixed Framerate Motion Blur
2. No Motion Blur
3. Dynamic Framerate Dependent Motion Blur

1A. If you set the fixed framerate too low, to 30FPS, the game will just appear smeary and blurry to most players, so turning off motion blur in the settings will be what the majority of them does as the very first thing. Anytime you see almost any streamer try a new game, you can see their entire community shouting at them in the chat to open settings and turn off MB.
1B. If you set the fixed framerate high, like 120FPS, you will get stuttering/strobing at lower framerates.

2. Motion Blur OFF works fine at reasonable framerates. That's why 60+FPS is widely considered comfortable framerate on PC, while 30FPS is the border of playable. Without motion blur, the illusion of continuous movement starts to break down into just a static image slideshow the lower the framerate is.

3. Dynamic Framerate Dependent Motion Blur just does not suffer this problem. At good, high framerates, it's imperceivable, yet adds subtle smoothness to the motion. At poor, low framerates, it actually helps to maintain the illusion of continuous motion and therefore framerate smoothness.

I've just made a comparison:
https://www.youtube.com/watch?v=N1aupcLOWPE

Bottom line is that fixed framerate motion blur can never solve the problem of players hating motion blur and turning it off as soon as they install the game. At that point, why even bother and add motion blur to our games? The players almost feel like we're taunting them.

Anyway, I am fine with having both fixed and dynamic framerate option as long as the default is the right one.

[Calinou]

I made a quick proof of concept: https://github.com/Calinou/godot/tree/add-motion-blur

motion_blur_wip.mp4

Testing project: test_motion_blur.zip (requires the branch linked above)

It's pretty incomplete and needs a lot of fixes before it can be production-ready though (see commit message).

[Darkenetor]

I think the discussion has been conflating two completely different use cases for blur.

1. @Jamsers is right that we add blur to CG because the simulation is imperfect and doesn't contain all the information we're used to parse in the real world, and exaggerated effects serve as guides in covering that gap and conveying the right read of the scene to the viewer. This is a stylistic effect, and framerate shouldn't alter the look chosen by the designer.

2. But at the same time they're misreading @Rawalanche 's excellent point in trying to match the amount of blur proportional to the shutter speed of the game camera. Blur isn't meant to sell the effect ingame, but to smooth the transition to the next frame by priming the viewer with the expectation of movement and preestablishing an adequate amount of focus on the details allowed by the scene to avoid "rug pulls" when the shutter then rolls to display the next frame on the monitor. This a purely functional consideration for viewing ease and preventing motion sickness.

I think that while both cases should be easy to support with the same implementation, the required minimum or defult should be to implement the practical one (2). This both to keep default settings neutral in regard to stylization, and because for a custom implementation it'd be harder for developers to deal with framerate fluctuations. It's also more likely for the stylistic effect to necessitate reimplementing just for the sake of customization.

An intensity multiplier ("shutter speed") should of course be available and tunable at runtime, and with a very conservative default.

this is especially important for gamers running the game at lower framerates like 30 FPS - their game shouldn't turn into a smearfest

This is a good point, and even if risking to clutter the interface with unintuitive knobs I think worthwhile to provide some. Should be fine in advanced project settings.

• A minimum amount to prevent excessive blurring. This is good and working for its purpose when it happens for the odd frame drop, but in the case of a particularly heavy section it'd make a few seconds of 20fps gameplay unplayable instead of an annoyance. I could see a good default anywhere from 25 up to 45.
• A maximum because at some point it's just not going to be noticeable, but instead take up frame time that could be spent on higher framerate improving fluidity even more on top of detail. This is probably too nuanced to enable by default, but personally I could see myself setting it to 115 or 55 and calling it a day.

Far from required and should be good for later consideration. I also see space for cleverness and taking them off the users hands with magical guesswork for both, but again even lower priority. Of course these shouldn't affect rate-independent/stylistic blur.

we could add a third factor that controls a motion blur fade-out depending on the distance between the pixel and the center of the viewport

And while we're on nice-to-haves, this I think is a good option to have on top of everything else and at least in the case of stylistic blur even default to, to simulate the effect of foveated vision that would affect it if the monitor covered more of our field of view. Maybe not disabling it altogether in the middle but a 1.0-0.5 scale, better yet taking a density map like VRS.

[Jamsers]

Blur isn't meant to sell the effect ingame, but to smooth the transition to the next frame by priming the viewer with the expectation of movement and preestablishing an adequate amount of focus on the details allowed by the scene to avoid "rug pulls" when the shutter then rolls to display the next frame on the monitor

Motion blur will still be applied per frame... frame rate independent motion blur just scales the blur length based on frame rate

for a custom implementation it'd be harder for developers to deal with framerate fluctuations. It's also more likely for the stylistic effect to necessitate reimplementing just for the sake of customization.

I need to clarify, while it's bewildiringly rare in the industry, frame rate independent motion blur is not actually some difficult task that requires advanced integrals or anything like that, as John Chapman outlined it's actually braindead simple: uVelocityScale = currentFps / targetFps

In fact Hugo seems to have already accounted for it in his proof of concept

So framerate dependent motion blur will just be
float frame_time_factor = MOTION_BLUR_TARGET_FRAMETIME / MOTION_BLUR_TARGET_FRAMETIME;
(aka 1.0 😅),

framerate independent motion blur will just be
float frame_time_factor = MOTION_BLUR_TARGET_FRAMETIME / delta;

[Darkenetor]

I'm imagining raw delta leading to whole-screen flashing artifacts on frame drops for this, without some kind of smoothing. Unsure if that's already handled elsewhere in the engine before passing it there.

[shakesoda]

in case it's useful for anyone i wrote an implementation of this for my game as a compositor effect. it's not perfect but it suits my game: godot_43_motion_blur_v7.zip. had no idea this proposal existed and there was already a proof of concept impl here, maybe there's room to combine their ideas.

@fire also did up a port of my work on this this morning over here https://github.com/V-Sekai/godot/tree/vsk-motion-blur-4.3-beta1

for different use cases i was thinking it'd be useful to have a knob for controlling the velocity weighting and something of a radial scaling on the screen (racing games may want this kind of thing for effect) update (v5): implemented @Calinou's weighting instead and added the radial effect, seems to solve both issues. compositor effects api seemed like a very well suited way to pull this off without getting into any unrelated rendering bits

update (v7): fixed edge fading logic to scale the blur instead of mixing the final color

[Jamsers]

@shakesoda i... i love you... you're amazing...

ok all joking aside i tested the V-Sekai branch and it's an absolutely fantastic implementation. it's not quite production ready, but it's like 90% of the way there; seriously impressive for a first implementation. all the core aspects seem to be there:

camera motion blur:

Camera.mp4

per object motion blur:

Object.mp4

skinned mesh motion blur:

Skinned.mp4

pertinent issues:

object and skinned mesh motion blur seem to be bugged in some sense, (object) motion blur length seem to be very limited even when intensity is set to very high values

foreground objects seem to not be able to "smear" over background objects

some artifacting in the motion blur effect itself, hard to describe but they look like pointed streaks within the effect itself

the skybox doesn't seem to be affected by the motion blur

of course i don't have the wherewithal to figure out if any of these bugs are in the motion blur implementation itself or maybe godot feeding bugged motion vectors into the motion blur, for example

but yeah, this is amazing, thank you so much for this. after 3 years of waiting Godot finally has actual motion blur. i could cry 😅

[shakesoda]

it's an absolutely fantastic implementation. it's not quite production ready, but it's like 90% of the way there

🎉 🎉

object and skinned mesh motion blur seem to be bugged in some sense, (object) motion blur length seem to be very limited even when intensity is set to very high values

foreground objects seem to not be able to "smear" over background objects

this is an inherent limitation of the way i implemented it, i can think of some alternative approaches that might handle it better but they'd definitely cost more frame time, likely more than i can spare on my hardware.

some artifacting in the motion blur effect itself, hard to describe but they look like pointed streaks within the effect itself

i think this was fixed (or at least reduced) when i switched to @Calinou's sample weighting approach, which the v-sekai branch isn't updated for just yet (but my updated v5 zip above is)

update: the branch is now updated

the skybox doesn't seem to be affected by the motion blur

godot's just not giving correct motion vectors for the sky, seemingly, i noticed this and some other quirks with them - looked unrelated to the effect itself.

but yeah, this is amazing, thank you so much for this. after 3 years of waiting Godot finally has actual motion blur. i could cry 😅

glad to be of help, godot's new compositor api is a really big deal for us finally being able to implement these kinds of things!

[passivestar]

Have to agree with @Jamsers, it's very noticeable that the silhouette isn't blurred, seems to be worth more frame time

Thanks for working on this!

[jcostello]

Have to agree with @Jamsers, it's very noticeable that the silhouette isn't blurred, seems to be worth more frame time

Yeah, a little blur in the silhouette would do the trick

[Calinou]

godot's just not giving correct motion vectors for the sky, seemingly, i noticed this and some other quirks with them - looked unrelated to the effect itself.

See godotengine/godot#67332.

[shakesoda]

Have to agree with @Jamsers, it's very noticeable that the silhouette isn't blurred, seems to be worth more frame time

Thanks for working on this!

i'm looking into adding another pass to deal with the silhouettes based on this paper, although it's not a priority item for me at the moment (as-is, my impl does what my game needs in the time i need it done). i can't spare the frame time for my current games, but i fully agree the option would be really valuable.

[QbieShay]

Due to popular demand, discussion has moved in the VFX server https://discord.gg/4JBkykG
@shakesoda would you be interested in joining and iterating on the effect over there?

[fire]

For cross-referencing https://github.com/sphynx-owner/JFA_driven_motion_blur_demo is one of the newer motion-blur experiements.