Very strong "fuzziness" artefact with TSR

[WhiteRaven_000]

Hi,
I’m developing a space sim and I’m struggling very heavily with Anti-Aliasing.
The best AA method I found so far is TSR.
It smooths very well the images and gives a very good look to the game.

However, it generates a terrible “fuzziness” artifact every few seconds.
An object becomes “fuzzy” for 1-2 frames, then it goes back to normal.

To describe it, I took some images and a GIF (I apologize for the terrible quality, I hope they give a good idea of what I’m struggling with ).

Normal situation:

Fuzzy artefact:

Notice that the fuzzy artefact has definitely lower quality than the “normal” visual.
I also made a GIF (of terrible quality) to show what happens, and how short is the “fuzziness” effect.

I understand how TAA works, and I understand TSR is an evolution of TAA.
I suspect that this “fuzziness” issue has to do with the velocity, as in the sim my objects can travel at >100m/s.
The “fuzziness” does not seem to happen at speed <100m/s, and it generally happens more often, the higher the speed.

In order to improve, I tried all the TSR-related console commands, but to no avail.

Rescaling the game to have in-game speeds <100m/s in Unreal units would be my least favorite option. I’m also not sure it would work, as all models would then become smaller, and eventual accuracy limitations of the TSR might still exist.
Switching to FXAA shows many jagged edges in the meshes, so I’d like to avoid.
MSAA requires forward rendering and has limitations with lighting, and I’d also like to avoid.

Is there a way to improve TSR to remove this “fuzziness” glitch effect?

Thanks!
WhiteRaven

[3dRaven]

I’m guessing you are getting fuzzines due to TSR being a resolution upscaler.
It’s rebuilding the image from imperfect data.
If your ship is travelling through space it doesn’t get enough samples from previous frames to do a good job at reconstructing the image of the ship, so it probably guesses what is in the missing areas (not sure if ai is used like dlss).

The technique might just not be good for a space sim with fast moving objects.

[WhiteRaven_000]

Hi 3dRaven,
thanks a lot for your input

It’s very likely that there’s some fundamental limitation in how TSR is implemented.
When switching to TAA, I get the same effect, plus a lot of jittering.
I wonder if TSR might have some parameter which, if trimmed, could improve the final result.
The fact is that TSR works very, very well for 99.9% of the time. Therefore, for the vast majority of frames, the information is there and it’s valid.
It just glitches every now and then
I wonder if these glitches could be avoided somehow, maybe in a future TSR version.
Maybe the root cause is in the accuracy of the velocity vectors? Still using floats instead of doubles? I wonder

[3dRaven]

From what epic has said about TSR is that it uses motion vectors for reconstruction of faster moving objects to reduce jittering.
Perhaps 5.2 will have some updates to make it cleaner.

[WhiteRaven_000]

Hopefully yes
Thinking about it, I will open a ticket. It’s better to have this topic tracked somehow, it might be useful to the dev team.

As an update: I tried the ludicrous speed of 472km/s (no kidding!) and TSR was still working very well, except the glitch I reported above.
It still happened just every now and then. Interesting.
At such ludicrous speed, it’s lighting breaking down, with flickering shadows all over the mesh. But the mesh itself looks great!

If it were just the velocity vectors, the glitch should happen more with higher speed. But at this ludicrous speed it actually behaves in the same way as “low” speed

[3dRaven]

Perhaps its a matter of the shadow technique? Are you using distance field shadows?

[WhiteRaven_000]

Good point, never thought about it.
Surely at high speed the lighting breaks down. I disabled all shadows on my actor, but nothing changes.
The glitch is still there.

Working in parallel, I could reproduce the same glitch in a clean project.
However, it’s not clear to me what triggers the glitch, as in the clean project I rarely observe it, and it’s much harder for it to manifest than in my game.
However, it’s clearly there somehow.

[3dRaven]

Are you using lumen to light it? The light propagation also needs samples to fill in information about gi if used.

[WhiteRaven_000]

Yep, I’m using Lumen. Both with and without Lumen brings to no change

On a parallel discussion, I received feedback on a Niagara bug, where large world coordinates induce a reset of all Niagaras which travel “too far”.
The reasons seems to be hardware-related: current GPUs work with floats and don’t support doubles (or support them very badly).

I suspect the issue here might have a similar root cause…

Edit: link of other thread Niagara Particles Reset in Large Worlds after 5.1 update - #9 by Michael.Galetzka

[3dRaven]

UE 5.1 was supposed to have internal 64bit floating point operations to support big worlds though.
Perhaps rebasing the worlds origin could fix this after long travels?

Set World Origin Location

[WhiteRaven_000]

Ah yes, the SetWorldOriginLocation function, I used it in the past precisely to overcome the “small world” limitation.

Indeed, it mitigates the TSR issue!
I try to run it every few seconds from my Player’s Pawn.
It seems that this stops the TSR from messing up my ship’s mesh
At least, I tested for a couple of minutes at >2km/s and there seems to be no “fuzzy” event.

On the other hand, objects further away are still affected by TSR ghosting (e.g. a space station), so it doesn’t solve all of TSR’s challenges.

As a side effect, Niagara systems with WorldCoordinates will be heavily affected and majorly messed up.
The rebasing also causes a little “hitch” in the game. It seems to be ok and affordable, but it’s there.
I will take a look of whether I can/should modify the Niagara systems to be in local coordinates instead.

Regarding UE5: yes, it supports double-precision coordinates, and you can go very far from the origin without having the game become an abstract painting, but I understand that GPUs have basic limitations which are still in float precision.
For example, my understanding is that certain translucent materials cannot be displayed at >1000km. I believe the root cause might be that the SceneDepthBuffer node within materials doesn’t give anymore results >1000km.

All in all, not easy

[3dRaven]

You could measure the distance between world resets (cache the location on reset as start) and only call them if the distance from the last reset to current position exceeds a certain value. It would reduce the amount of hitching and it would only occur when passing into a new sector (flying around the same area would be smooth)

[WhiteRaven_000]

Yep, thanks for the good suggestion: that was how I had it implemented in UE4

[aoshi11]

I also have artifacts when I have this muzzle flash with TSR but I do not have it with MSAA. First part of the vid shows TSR and you can see around the edges irregular jagged speckles of bright artifacts. The later part of the vid I switch to MSAA and it doesnt show those artifacts. But I can’t use MSAA because of the very obvious jagged edges on my meshes.