Download

Motion blur is affected by time dilation in UE 4.25

Unreal Engine Feedback for Unreal Engine team
#3

Thanks for replying! I see now that I’m not the only one with this issue. I got an email from Epic today, saying that this issue already existed (UE-46172): Unreal Engine Issues and Bug Tracker (UE-46172)

Please upvote the issue! Hopefully, it won’t stay in their backlog for too long, since this is a pretty major issue that affects any game with slow motion. I’ve been playing Final Fantasy VII Remake lately, and I’m pretty sure that game would have been affected by this when you press X to select commands in slow motion.

The weird thing is that the issue was created in 2017, even though it only affects 4.25. I’m guessing this bug already existed in a previous version, but it only now became this easy to reproduce.

I was taking a look at the engine code, and I suspect the key to fixing this issue is in the PostProcessMotionBlur::GetMotionBlurParameters function. There is a ViewState->MotionBlurTimeScale there (just like in the linked issue, but in a different line of code), which serves as a velocity multiplier. I think I’m gonna debug that function later and see if there’s something wrong with that variable. It would be extra helpful if someone from Epic could shed some light on the situation, though.

For now, I’ve come up with a workaround using Blueprints. Every time I change the global dilation, I set my camera’s PostProcessSetting Motion Blur Amount to TimeDilation * BaseMotionBlurIntensity (0.5, in my case).

A nice way of doing this is by having a SetGlobalTimeDilation function in your GameMode, which sets the global time dilation and then calls a GlobalTimeDilationChanged event dispatcher. Then, create a MotionBlurStabilizer ActorComponent, with a Stabilize function bound to your GameMode’s GlobalTimeDilationChanged event. In the Stabilize function, you can do this:

(Ignore the “Parent: Stabilize” call. I used this because I have a parent TimeDilationStabilizer class)

Add this MotionBlurStabilizer to whichever actor contains your camera component, and don’t forget to set its camera variable to your Actor’s camera.

I hope this workaround helps some of you while we wait for this to be fixed. :slight_smile:

#4

Try “r.MotionBlur.TargetFPS 0” command. I had a similar (or same?) issue in 4.25 and this took care of it.

#5

Thanks for the tip! That’s an easier workaround, but I wouldn’t recommend keeping the target FPS for motion blur at 0, as that causes motion blur to be dependent on frame rate, so someone running the game at 120fps would get a lot more motion blur than someone playing at 30, for example.

By the way, I have good news! The issue I linked in my previous post has been updated to “Fixed”, so I guess the fix will be included in 4.25.1. I’m curious to see how it was fixed in the code, but I haven’t been able to find the commit with the fix yet. Maybe it’s in a private branch and my curiosity will have to wait a bit. Thanks for the quick fix, Epic!

#6

Good option. Especially if you’ve set the game to a fixed frame-rate like I mostly do in order to provide consistent behaviour across as many platforms as possible regardless of capabilities.

#7

Great find - and hopefully this gets fixed as although r.MotionBlur.TargetFPS 0 is a good temporary fix, I still seem to get the motion blur issue if I pause the game even with that command.

#8

Seems Still getting that issue in game with 4.25.1

So did they fix only global time dilation and left custom time dilation Buggy

#9

I’m still getting the same issue in 4.25.3 with RTX 2060, though “r.MotionBlur.TargetFPS 0” or “PostProcessingVolume->Motion Blue->Target FPS to 0” fixes the issue.

#10

Even with motion blur disabled its “enabled”

This didnt fix anything.

#11

Can anyone confirm if this is still happening in 4.26 Preview 1? If it is, we should let Epic know as soon as possible so they can get it fixed in time for the stable release of 4.26.0.

I would test it myself, but I only have enough space for one version of Unreal.

#12

I freed up some space to install version 4.26 Preview 1, and can confirm that this bug is still present. :frowning: I’ve submitted a new bug report for Epic. Hopefully, it’ll be fixed this time.

#13

It still to this day does not make any sense to me why UE4, with all the push for physically based rendering, still defaults the motion blur amount to a value unrelated to actual framerate. Not only does it lead to issues like these, but it’s also source of the reason so many gamers hate motion blur. It’s not that motion blur is bad, but the unnatural motion blur is bad. The default MB target FPS value of 30 will give you motion blur amount adequate to frame rate of 30 FPS, even if your game runs at 120, making it look like an ugly smeary soap opera :frowning:

#14

Motion blur IS bad.
If you swing your head around really fast, do things appear to blur?
if yes, are you The Flash?

#15

Human eye sees the motion blur. It’s just that for humans it’s borderline impossible to keep eye target fixed to the head, so shaking the head fast is terrible experiment (also not good for brain health). Eye focal point constantly anchors to static points. But if human eye had no motion blur, you would be able to see individual propeller blades of flying helicopter or even common household fan perfectly sharp at all the times. I mean just look inside your computer case at any of the spinning fans. Or just relax your wrist and swing your hand back and forth really fast. There! You are seeing the motion blur.

Honestly it surprises me that you, as someone with 3220+ posts on this forum, miss such a basic understanding of human vision to not even realize you are seeing motion blur all the day every day.

Motion blur IS NOT bad, but it has gained a really bad reputation among games because vast majority of game developers had little to none computer graphics backgrounds and thought that motion blur is something under artistic control with artistic licence. And that’s why I am shocked that even Unreal Engine, which is pushing the boundaries in terms of physical accuracy and photorealism has repeated the same mistake.

The main idea is that if motion blur is done **right, **then it’s perceived as a smoothness of image motion instead of blurriness. If motion blur is done wrong, then it’s perceived as blurry image and user/player has an inclination to turn it off. The right motion blur is hard to spot, simply because it looks natural. But the point is that it’s not about the amount of it, it’s about the amount in relation to the framerate.

Here’s an example in my game. First, this is the WRONG default Target FPS value of 30 Epic decided to use for some reason. You are 4x the real amount of realistic motion blur at 120FPS (the default in editor framerate cap):

WrongTargetFPS.jpg
WrongTargetFPS.jpg1920×1050 355 KB

Now here is the **CORRECT **motion blur Target FPS value of 0, which derives the motion blur amount from framerate. At 120FPS in such a fast motion, your the amount of motion blur relative to that is so small that your eyes won’t perceive it as a blur, but instead as a smoothness of motion, which is the entire point of motion blur:
RightTargetFPS.jpg
RightTargetFPS.jpg1920×1050 494 KB

Motion blur is not bad. What is bad is usually the lack of experience of game engine developers who implement it (I don’t mean Epic here, as they did it right aside the wrong default value. Rather I mean the smaller game developers having their own engines), and game engine artists who use it. Motion blur is something that should be enabled and kept at right values, not something that has to be tweaked for the right look. And that’s where the main issue I talk about is. If even the default values engine developers decide on are wrong, then no wonder Motion Blur has such a bad reputation, when almost always, all the conditions are set up to ensure almost no one uses it correctly.

In fact, one more experiment I would like to point out. Set the Target FPS to 0, for MB to be correctly derived from framerate, and then use t.MaxFPS console command to limit framerate of your game, to for example 60, 40, 30 and then 20 FPS. Then at each of those framerates, try to enable and disable motion blur by toggling the amount between 0 and 0.5 (default). You will see that especially at lower framerates, the motion blur will make the motion of your game appear much smoother, even at framerates as low as 30, compared to disabled motion blur, where the motion will look stuttery and choppy.

Just keep in mind to always leave motion blur amount at 0.5, which equals to commonly used 180° shutter angle (half a frame). Never ever use amount of 1.0 unless you are going for that ugly, Argentinian soap opera look.

And if you really, really need artistic control over the MB amount, then always keep Target FPS at 0, to keep it framerate relative, and use MB amount value to tweak the amount, but stay in range between 0 and 0.5, never cross 0.5. For example amount of 0.25 should simulate 90° camera shutter angle (or 0.25 frame shutter speed). :slight_smile:

#16

I disagree. Effects where it matters are usually made by hand.
wheels spinning. Proprllers rotating. Fans spinning. Anything that requires to be blur you cant really rely on engine rendering - otherwise you wouldn’t have professional projects making use of motion blurred materials instead of motion blur itself.

That said, i’ll give your values a try. But 90% of the time within gaming, because the effect is applied to everything and the screen moves - not focusing automatically on objects like our eyes - motion blur is bad.

#17

The fact that rotational motion blur is usually done by hand using some fakes has absolutely nothing to do with the need to selectively apply motion blur to only specific objects. It is purely a product of technical limitation of rasterized postprocessing motion blur, where you can not achieve curved motion vectors. You can use the global postprocess MB for rotational things, it just looks bad. That’s why people have to selectively create cages or materials for quickly rotating objects.

And yes, give my “values” a try. But it’s not really valueS, just a value. Simply set Target FPS to 0, don’t change anything else, and you are good to go.

You also misunderstood what I said. Motion blur does not focus on your eyes. What I said that eyes constantly try to anchor to static points. Their orientation almost never remains fixed to the head orientation unless you go unconscious with your eyes open. That’s why in some games, especially older ones, characters look like lifeless stuffed animals, because when they move their head around, the focal point of eyes unnaturally moves with it.

So when you see motion blur on the screen, it is still right. In fact it’s more right than with the motion blur off, since computer monitors just “fake” the motion by playing many still images in rapid succession, so if you add the motion blur as a factor, image becomes more natural to the brain because it sees the same effect of “blur” on the screen as in the real world outside of the screen. At the same time, if you are seeing too much motion blur, it’s as bad as if you were seeing none. Both extremes - too much motion blur as well as no motion blur - are equally as bad.

So once again, this is why I am so frustrated that UE4 uses the wrong default Target FPS value. MB already has unjustly bad reputation in the PC gaming world, and the UE4 is deepening this problem by encouraging developers to use it wrong by having wrong defaults.

#18

I din’t misunderstand what you had written.
the point is, motion blur happening when you pan the camera - the camera being the character’s head first person. Is just bad.
Not only that, in people like me it contributes to motion sickness to the point that some games (fallout 4 to name one) are unplayable.
this is precisily because motion blur in game does not work like IRL.
Let’s not even go to VR and motion blur, or I’ll barf right here :wink:

And as far as my “condition” its actually almost exclusive to gaming. Boating gets me sick less than fallout 4 tbh.

#19

I still think you do not understand it. The motion blur also happens in real life when you manage to somehow pan your vision while preventing your eyes focal point without anchoring to static locations. The only difference is that the theoretical framerate and therefore shutter speed of eyes is much higher than average camera. But you can still easily observe even non rotational motion blur, for example observing neighboring train tracks when traveling in a moving train. That makes it very easy to observe motion blur with your own eyes, since they will most often focus on some highlight which appears static under such speed.

Your eyes are nothing more than a pair of biological cameras. Furthermore, you constantly keep bringing up your subjective bad experience with motion blur, which just reinforces my point. You have such a bad experience because you’ve experienced mostly games that utilized it wrong, and as a UE4 developer you have also been using it wrong in the engine ever since you started using it, because the Target FPS value was added only recently, and with a wrong default value on top of that.

It’s like if you were saying that all food sucks and is bad, because it makes you feel bad, unhealth and fat, while you’ve been eating nothing else than McDonalds burgers, snickers bars and coca cola all your life.

#20

Not really. I’m also a cinematographer so I have more than a general idea. I tried your suggestion. Doesn’t change much of anything. I still have to turn it off to get something playable.

Regarding motion blur with actual motion, like trains, that too would likely be better off faked with a material. If you are the one standing still obviously.
Otherwise, if you are On the train, then maybe script it so as to turn the value on in the PP or put a post process that moves with the train. Depends on situation. I much rather just have it off given how problematic it gets.

Ps: sure, its not as bad as whoever thought head bobbing was a good idea.

#21

I got an email from Epic saying that the bug is now marked as Unresolved again: Unreal Engine Issues and Bug Tracker (UE-46172) I gave them a link to this thread so they can see all of the workarounds and that I’m not the only one affected by it.
The issue page says that the target fix is 4.27, though. =\ Hopefully there’s a chance it’ll be fixed in 4.26 still.

#22

Just chiming in to say that I’m still seeing the bug in 4.25.4. Sounds like we won’t get a fix any-time soon, so the workarounds in this thread are helpful!