Temporal flickering in what seems like 3D viewport antialiasing

Anyone else experiencing this? Occurs in everything but the Rendered display shading mode. Might perhaps be specific to Radeon graphics cards, mine is a RX 470.

It’s as if the view buffer is constantly pulsating between AA on and off. AFAIK I’m not dyslexic, but it is giving me a headache.

Having tried tweaking the AA/Multi sample options in preferences doesn’t actually affect it so I can only guess that its something else, perhaps depth pass related.

I’d try using screencasting to capture it, but that feature was removed from 2.80.

1 Like

Might be a card setting - you can use OpenBroadcaster Studio (OBS) to get a good screen capture with or without mic input and save as mastroska.

Yeah, that is something that occurred to me too, but I figured I’d first see if someone else had experienced this too, maybe someone even has already reported a bug or something.

1 Like

You can try to enable debug at 26.

If there’s a change in aliasing, it’s possible that it’s the FXAA/TAA switching which is normally tied to the view3d operators.

Can confirm that changing multi sample in preferences has absolutely no effect on the AA quality or lack thereof on 1080.


--debug-value 26 made a table of debug info appear, but no change in the flicker. The debug info does show however that it is in fact the TAA that is on for one frame and off for the next. Very annoying. But bug confirmed I guess.

At least it doesn’t occur in rendered shading mode.

Further inspection reveals it might be the Velocity Resolve causing this. At least when switching to LookDev shading mode the debug table shows velocity resolve as the one popping in and out.

@hypersomniac Is this something that should be reported to you?

Well this is how eevee works. By resetting its accumulation buffer if the scene / view changes.

Workbench (aka solid / xray) does something similar.

If you are anoyed by the flickering you might disable AA for workbench in the system settings > Viewport Quality.
For eevee, set the sample count for viewport to 1.

Thanks for replying! Set the quality to 0?

yep, that fixes the solid view flickering by removing all AA, alas LookDev remains.

Guess I’ll have to try driver level force injection to get normal AA in blender? Or will that be implemented as a choice at a later point?

I’m noticing some very Unity like temporal alias flickering in final EEVEE animations…check out https://youtu.be/AtjLhPtzL9M?t=87

You see the highlights on the counter are not properly flickering. I’m using a GTX1080 and here are my pref settings. Any ideas anyone? I just assume it’s a problem with EEVEE as it did take Unity a couple years to solve the same problem (Unreal has no such issues).


Please let me know if there’s a setting I’m missing. Thanks!

The Cycles Compute device is exactly what it says. It’s for cycles… not eevee.

The multisample parameter is not controlling the whole viewport AA but only wires objects AA (like empties).

The xray/solid/lookdev/eevee use their own TAA implementation for technical reasons.

Drivers should not enforce anything and trying to do so might break things or not work at all.

1 Like

Lookdev IS Eevee under the hood. It reacts to eevee render settings.

1 Like

Again, thanks for the feedback.

Found it, so Filter Size under Film. Thanks.

1 Like

@Craig_Jones @iceythe @hypersomniac
It was the Animation Nodes Auto Execute causing an unnecessary display update. Not sure why it defaults to AE on. So while working with procedural tools that cause the viewport to constantly update I recommend users to have filtering off.

@chippwalters Yours was a final render, right? Not a view-port capture. Might be an option to turn Filter Size to 0 and do AA/Sampling as a post process through compositor perhaps?

1 Like

That’s interesting. I haven’t even tried AN on 2.8 yet. Maybe give Jacques a heads-up on the issue tracker.

I mean it’s not a bug, just inconvenient to have Auto Execute default to on with always as the sub-setting. On tree change seems like a good default. But I don’t think it’s as pressing right now. Plenty of time to deal with changes to the default settings still.

1 Like

@Felix_Kutt Sorry, must’ve missed your question. Yes, it was a final render and not view-port capture. I will try your suggestion but have never found post AA/Sampling to be very good. Who knows?

For starters you would at least have to render at quadruple the size. 512 x 512 would become 1024 x 1024 at minimum so you’d have something to work with. The more pixel data you have to work with the better, obviously. Easiest to keep it to power of two. Generally speaking though aspect ratio is the most important thing to keep unchanged.

Another potential way to go could be if you render it twice, assuming that the sampling noise causing the jittering would be different for each of the frames in the second sampling set, compared to the first set. Could then try to average the samples to maybe alleviate the jittering noise.

Ultimately having access to render passes such as normal vectors and what not might allow for some additional post sampling too. Given enough data to work with what a renderer can achieve should be theoretically achievable in post too.

It’s been a very long time since I’ve done any of this in post myself though, and I certainly haven’t yet experimented with anything of this kind w.r.t. EEVEE, so best be taken with a load of salt to be sure.

Thanks again for the advice. I was able to get some sufficient anti-aliasing using Freestyle lines in EEVEE.

I did not see any difference between Filter Size = 0 or the default 1.5

It of course works better at 2 X 1080p resolution, but I rendered this at 1 X 108P and it works pretty good.

No AA (default Freestyle EEVEE)

With AA (using Fast Blur node)

Node setup:

Perhaps you know a better way to do post AA? I’m all ears :slight_smile: