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.
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.
--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.
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!
@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?
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.
@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.
