I have found out that many people have this issue and no real answer has been given so far.
We used to have the ability to exclude objects from motion blur in UDK and its also a feature we’ve had with another engine.
Could we please have an official answer, this is affecting one of the cool features we have in our game and puts our UI work to a halt two months before our planned release
In the Actor you can find the Motion Blur Scale. That value was once needed to disable motion blur on object that move with the camera (e.g. platforms). This is no longer needed as the motion blur now correctly handles such relative movements. The value will be removed soon or reactivated if we realize me miss some cases with the new implementation.
Fourth’d. Not having Depth Priority Groups anymore is a pain in the butt.
If anyone gets a solution to this, I’d love to know it. Even though Motion Blur is supposed to handle depth properly and not blur stuff up close (i.e. gun does not blur) stuff like UI widgets still do, which means you can’t have motion blur and a visor, in-world HUD, or menu without it getting all blurry when you turn.
Is there an option to set the motion blur depth or “start distance”, much like you can with Depth of Field effect?
Might be per pixel process after whole frame is rendered. I have no idea how its actually implemented, but it might be possible with some kind of off screen camera projection in post processing. Just a thought.
We have heard your requests and have entered a feature request to add options that would allow a mesh to be excluded from Motion Blur, for reference UE-26214. I will keep you informed as we investigate the best way to implement this feature.
The request has been determined by the developers as something that cannot be integrated as a feature at this time. The reason for this as explained by the developers, is that motion blur is based on the per pixel stored velocity and TemporalAA needs the same information.
If we wanted to have no motionblur on some objects we cannot just store 0,0 velocity as it would break TemporalAA. We would have to store another bit (Gbuffer) to disable it, and we don’t want to pay the performance cost for the feature.
Objects that don’t move in screen space should just work - they should have a 0,0 velocity. Usually that can be fixed by content which also helps TemporalAA. We will consider adding a 3D UI pass rendering without TemporalAA before or after tonemapper, but that is another feature and its integration does not have a specific timeframe at the moment.
Thanks for taking the time to request the feature and we appreciate your feedback.
Hey Andrew and Eric! Thanks for the update on this. Let me ask, is it possibly a bug then if you have widget component for example that is attached to the camera and you rotate that camera with it as the primary view target? When you do, the component attached I would think since its relative to the camera would possibly cancel out the velocity all together since it also doesn’t move in screen space technically. However, it blurs almost to the max extreme but I have also even noticed a slight jitter as if the child component is like a frame behind when updating its wvp matrix. If that were true, it could be creating inconsistent velocity data I would think. Maybe this is contributing to it and boils down to an issue with when the children matrices are updated for the current frame. Maybe I’m wrong on this but if you are saying anything that shouldn’t be moving in screen space wouldn’t contribute velocity data, then its likely this could be the culprit of that. Just wanted to check on it anyway just in case because this is an important feature to 2 projects I’m working on. Thanks guys!.