Hello,
We are working on Space RTS project. After updating to 4.9 our ships started to looking a lot more blurry when in motion. I’ve set up new empty project to showcase that problem. Here is screenshots:
In 4.8:
In 4.9:
Look closer one by one to see the difference.
Here is my test projects
Both for 4.8 and 4.9
P.S. I know that i can switch AA Method( in PostProcess->Misc) from TemporalAA to FXAA. But we love Temporal AA from 4.8 
Hey MadScorp,
I opened your projects and am not seeing any noticeable motion blur in both versions. Would you mind describing what the motion blur looks like on your end in a bit more detail?
Are there visible trails being left behind the mesh when it is in motion related to (Temporal AA), or is the entire ship blurred when moving (Motion Blur)?
In regards to your project, it seems you are driving your scenes lights based on the post process volume’s auto-exposure setting. I do not want to dictate how your project will look as this is totally your choice, but your light source’s intensities were very low. These are the driving forces behind rendering your project cleanly in conjunction with Post Processing as they are dependent on one another.
I suggest finding the correct lighting using your light sources first, and your Auto-Exposure set to Min 1.0 and Max 1.0. This will help you gauge the correct lighting for your scene, so when it comes time to add the Post Processing effects, you can keep these optimized and minimal, but still maintaining the visual effects you would like.
There is a setting within your Post Process Volume labeled ‘Motion Blur’. The default values add a bit of motion blur to your objects in the scene, but you can reduce these values to have no motion blur if you would like. Let me know when you have attempted to change these values and if it resolved your issue.
Thank you,
Hi Andrew,
Visible trails are not bother us. Actually they are not visible in our game level( cause we have dark space on the background ), and the projects i provide, have the best PostProcess settings to showcase the problem.
The problem is that the entire ship blurred when moving. It was blurred in 4.8 (but it was not evident ) but in 4.9 the blurring changed (as i can see postprocess behavior was changed - there are some bloom difference, scene color… ). I don’t know how to explain better. Here is another screen (4.9 - top, 4.8 - bottom):
MotionBlur does not affects the result. Maybe “more blurring” effect is the result of combination of several PostProcess changes (in 4.9). Please help us to achieve a result we had in 4.8.
P.S. Thank you for advice about lighting. We will check it out.
Take a look at blue lights. I think that it is the best way to see difference. But if you look closely you will see the difference in other details.
Hello MadScorp,
I downloaded your project and opened both the 4.8 and the 4.9 version. I then tested them both moving and was able to see the slight change in the lighting in 4.9.
However, if you zoom in close enough then this issue does not occur. I tried zooming out and noticed at a certain point that the shadows would soften and then the lights would dim. I do not believe this is a post processing issue as much as an LOD issue.
In 4.9 we have implemented a Hierarchical LOD system.
I believe that this is related because I am able to reproduce the same situation without the ship moving. I recommend looking through our release documentation and investigating this possibility further.
If you are still experiencing an issue after that then please feel free to post here again.
Thank you,
We tried to dig into LOD system, but unfortunately - no results. Also we figured out that in fullscreen the problem is more clearly noticeable.
We still think that AA method is related to this problem, because if we switch method from Temporal AA to FXAA in both 4.8 and 4.9, we get almost the same images with same details, lights and bloom.
It would be very sad to roll back to UE 4.8 because we can’t achieve the same image in 4.9. So we really hope that you can help us somehow.
Hello MadScorp,
I have tested this on my end and I still cannot see what you are reporting. If you still want us to troubleshoot this issue then please link me your DxDiag and I will pool more resources to resolve this problem.
Thank you,
Here is my DxDIag.
But also i’ve created small video to showcase our issue.
You can see that with FXAA image on 4.8 and 4.9 almost the same. But with Temporal AA difference is huge.
link text
Hello MadScorp,
The way Fast Approximate Anti-Aliasing(FXAA) works is this.
FXAA smooths edges in all pixels on the screen, including those inside alpha-blended textures and those resulting from pixel shader effects, which were previously immune to the effects of MSAA without oddball workarounds.
Version 3 of the FXAA algorithm takes about 1.3ms per frame on the standard low end video card. Earlier versions were found to be double the speed of 4x MSAA, so you’re looking at a modest 12 or 13 percent cost in framerate to enable FXAA - and in return you get a considerable reduction in aliasing.
The downside, is that you may see a bit of unwanted edge “reduction” inside textures or in other places.
Temporal Anti Aliasing works as follows.
Temporal AA uses a sub pixel jitter to the final MVP transformation matrix that alternates every frame - and combine two frames in post-effect style pass. This way temporal AA is able to increase the sampling resolution twice at almost no cost.
The result of such implementation looks perfect on still screenshots ( and you can implement it in a couple of hours on a high end project, but breaks in motion.) Previous frame pixels that correspond to current frame were in different positions. This can be easily modified by using motion vectors, but sometimes the information you are looking for was occluded. To address that, you cannot rely on depth (as the whole point of this technique is having extra coverage and edge information from the samples missing in the current frame, so you can try and rely on comparison of motion vector magnitudes to reject mismatching pixels.
So, in a nutshell, yes if switch between different methods of calculation for how anti aliasing is handled there will be a “huge” difference. Simply because they are a different ways of calculating the way the softening of your edges is handled.
In cel animation, animators can either add motion lines or create an object trail to give the impression of movement. To solve the wagon-wheel effect without changing the sampling rate or wheel speed, animators could add a broken or discolored spoke to force viewer’s visual system to make the correct connections between frames.
As I stated previously. I can zoom in and out on your project and produce the blurring of your ship, “not the trail behind you,” that in itself leads me to believe that this is not an issue with your post process while moving. You can zoom in to a distance, “in PIE,” where I see no blur.
This is a screenshot of your scene with the post process volume in your scene and I see no blur at this distance.
Here is a screenshot of your scene, (without the post processing volume, and without motion blur enabled to be seen inside of your game that I disabled through the viewport.) This is also in PIE mode.
The biggest thing I noticed while looking at your mesh is that you only have one LOD. So everything is trying to be calculated on one LOD at any distance you put your camera.
When close up you can have a decent sized resolution of 512 or so, depending on how much detail and resolution you want. Even if you change the resolution of the lightmap on your mesh with one LOD, that will not effect the resolution of the texture applied. What you can do is set up multiple LOD layers, where when you are at your greatest distance it will draw the highest Level of detail that you make. So at where you have the picture you linked previous, you can call a texture size of 2048.
At a certain point you will lose some resolution as software and distance fields do have limitations.
However, now that you have a little more information on how different methods of AA work and knowing that this effect is reproducible in and out out PIE mode without movement, there are some options to look into.
Thank you,
Hi ,
Thank you for some extended info about UE and AA. We will try add some LODs for our static mesh but i am not sure that it can help.
But the most important question now is " Why UE 4.9 Temporal AA looks A LOT worse than UE 4.8 Temporal AA?"
As i’ve noticed there are other people who have that problem:
The best way to see the problem is to run projects i’ve provided in standalone mode in full screen. Look at ships in motion.
Here is some video:
First part - comparison FXAA 4.9 & 4.8 - almost no difference
Second part - comparison Temporal AA 4.9 & 4.8 - huge difference
So again FXAA on 4.8 and 4.9 - the same image. Temporal AA is getting worse on 4.9 while on 4.8 works fine. Maybe there is a way we can influence on Temporal AA intensity?
Maybe we can use Skype (look at my profile on forum) if there are some reasons you still can`t see the difference?
For some reason my comment is disappeared 
So i’ll try again… More close to the point:
Why Temporal AA looks more worse on UE 4.9 then on UE 4.8 while FXAA looks fine on both of them? You can see it on a video i provide
Our game goes for Early access this fall, and we are experiencing really bad looking ships on 4.9, so we will have to roll back to 4.8 if you won’t help us.
There are some other people who complain about the same problem
I figure out that it was some changes in Sharpness behaviour in 4.9 for Temporal AA
I’ve tried to change r.TemporalAASharpness but unfortunately no result.
I am still digging into TemporalAA Settings maybe i’ll work it out by myself. Please check it on your side. Maybe ask the developers. Thank you.
Unfortunately r.TemporalAASharpness do not not affect the image. In any case, as it should. I am look forward for your comments about TemporalAA changes in UE 4.9
Hello ,
Why you are marking the issue as resolved? It’s not at all.
Hello MadScoorp,
I apologize for the confusion. I was marking this as answered for tracking purposes so that I could further investigate this issue.
After a fair amount of research and pulling in more resources from our team I have found that this is indeed an issue from 4.8 to 4.9. It has to do with the dithered quantization to remove banding when we switched the temporal history buffer to 11:11:10 from FP16. It wasn’t intended to be noticeable. It’s on the to do list of fixes.
The above is a link to other issues and is a response by another staff member for what I believe to be the same issue.
Unfortunately I do not have a timeline for when this will be fixed. I will keep you up to date as this problem is handled.
Thank you,
Thank you!
