Flickering in animations with recommended settings

[uforis]

Are there any other determining variables with regards to flickering in animations other than the LC settings (3000 subdivs, 8 retrace)? I still have a lot of flickering in my project despite these settings, on both VRay Next CPU and GPU. I tried update 2 as well, but I'm getting unhandled exception errors on VRay GPU caused by the Dome Light with HDRI texture.

[^Lele^]

you can definitely continue in the same direction with the settings, but it may be you're not flickering because of GI.
Would it be possible for you to send a scene, or part thereof which exhibited the issue, to support@chaosgroup.com?

[uforis]

Hi Lele,

Yeah I sent them a package of my scene, but they were unable to reproduce the issue, but I'm pretty sure some pieces of the scene were lost in translation so to speak, for instance the HDRI texture, although I included it in the archive, was not being found when the opened the scene. I set paths to relative which may have caused this issue, but I successfully shared a project this way in the past. Although I ran resource collection, some things don't transfer correctly, and in their words, "it could take days to debug." Maybe I packed it up incorrectly, or there's a better way to do it. There is also a huge time gap for me, not to mention how long it takes to debug animation (over night renders).

What's your procedure for debugging flickering? I just want to learn more about what is causing the issue, and I didn't get any particular insight into the problem from CG reps. Why for instance, why is 3000 sudivs and 8 retrace and acceptable standard, and does adding more subdivs and retrace potentially solve the issue? I tried adding more, and while it helped a little it didn't solve the issue. I have really appreciated your tips in many threads regarding producing flicker free animations Lele, you're a tremendous wealth of knowledge. 90% of the time these settings seem to work, but I'm definitely puzzled by why in some cases they do not. Is BFBF the fall back option if all fails, and what settings there would be recommended?

Thanks again for your great contributions here on the forums, I have learned a lot from you, but apparently there's a long ways to go!

I had another thread in the problems forum here, maybe you can have a look at some of the renders I posted to see if you might have an inkling of what could be causing the issues.

[uforis]

I can confirm the flickering is occurring in both the GI and Reflections channels. All other channels look fine. Do you think the default DMC settings for min samples might be too low? Maybe I need to lower by LC sample size to get a more consistent result?

[Alessio]

If you say you have flickering in the reflections maybe there is some problem there that generates a problem in the GI?
Have you tried to render without GI to check that there is no problem in the geometry? I'm thinking about overlapping faces...

[^Lele^]

"flickering" is a broad term, unfortunately.
it does have sub-classes, but then we get more into language than engineering, eheh.
Overlapping faces would generally be nasty, but you can try and see if a simple change mitigates that: set "Secondary Ray Bias" (V-Ray Global Switches, advanced mode, at the bottom) to something like 0.001.
If it doesn't flicker after that, it was due to overlapping faces.

LC.: i wouldn't touch sample size: if at 3k/8 for subdivs and retrace you get very odd results, there is something else afoot, very likely.

I'll bug support and get a hold of a copy of your scene.

[uforis]

Hi Alessio and Lele,

Thanks for the feeding. I ran a test on the Secondary Ray Bias, setting it to 0.001 as you mentioned, and it didn't help. I don't exactly see how overlapping faces could create the problem I am having, but regardless the secondary ray bias didn't help anyway. So is there there something further I would need to test regarding overlapping faces?

Can either of you tell me anything about using BFBF?

Thanks for your help.

[^Lele^]

uforis BF/BF is going to be slower, and if you are having flickering issues, it may not help (surely not with rendertimes).
I have requested the scene you gave to Vlado, and will look into it asap.
I'll then maybe able to give you a specific hint.

[uforis]

Thanks Lele, I think there were some problems with the package as I mentioned before, with some links lost in translation. If you have some guidance on how to package up a rather large project before sending it let me know. I think everything should be in there, but the links were lost (I had it on relative paths, which has worked transferring projects before). For instance, running Resource Collector does not collect any the environment map used for the Dome Light, etc. I manually placed it and re-pathed it into the archive folder before packing it up. If you need a new package please let me know!

Edit: Should I used VRay Scene exporter instead?

Strangely, I am having faster and better quality render times using BFBF, with no flickering to speak of yet, with GI Depth at 12, Noise Threshold at 0.002, Secondary Ray Bias at 0.001 (as you mentioned), and Full Lighting Evaluation with 16 probabilistic lights (matching the number of lights I currently have in the scene). I will post some results shortly illustrating the comparison. BFBF might be my preferred method, as it starts rendering straight away. Waiting 5+ minutes for a 3000 subdiv 8 retrace light cache to compute is kind of a huge pain, and it seems after 5 minutes of BFBF rendering I'm already getting a pretty great looking frame with the Denoiser. It could be that because I am using GPU rendering for these tests, (2 * 2080Ti + Threadripper 2950x in Hybrid), that LC is slower because as far as I can tell it is done 100% on the CPU (which is still a pretty good CPU with minor overclocking). I don't want to jinx it, as I'm not done rendering the full 192 frames of one of the 8 second clips I have been having these problems with, but usually I am able to tell if there is flickering within the first 10 - 20 frames rendered. So far, after about 80 frames, not a single flicker! It's weird because I tested BFBF a few weeks ago, and I still had some problems, but I definitely had different values in the GI Depth, Secondary Ray Bias, and probablisitc lights. I'd be curious to know if you have any other flickering debugging methods.
Thank you so much for your help Lele! I've learned so much about VRay throughout this struggle.

[uforis]

Brute Force, Light Cache (3000 Subdivs, 8 retrace): https://youtu.be/RnuqfO_GpRc
Brute Force, Brute Force: https://youtu.be/k1mDjpYEFmg

Pretty short clips, and some compression artefacts from converting to MP4 quickly, but you can see that there is quite a bit more flickering in BFLC, whereas there is none in BFBF.

[^Lele^]

Oh, i see!
If BF/BF cures the issues, then a higher retrace will do too (with a very high retrace, the LC would be all but discarded in favour of BF "patching up" the LC inaccuracies.).
Notice you may still have to raise the LC subdivs a bit, because of the main source of light being behind fine, moving geo (which is akin to torture for path tracers in general).

I haven't managed to grab a hold of the other scene of yours yet, but haven't given up!

[uforis]

So if there is still flickering with BF/BF, is the issue most likely overlapping faces? Can overlapping faces be created by VRay displacement modifier? I guess there is no ironclad setup for rendering flicker free, it seems like there could be many culprits, but at least falling back on BF/BF seems to help. I'm kind of puzzled by LC at this point. I am able to get ~ 1200-1500 passes from BF/BF before Light Cache even finishes at 3000 SudDivs 8 Retrace (5 minutes rendering on Brute Force vs 5 minute LC calculation). The adaptive mode doesn't seem to speed things up that much, and when you have a lot of lights in the scene, it seems LC can take even longer to resolve.

[Alessio]

Hi uforis
now that I've seen your scene I would definitely go with BFBF and don't think about LC.
With so much geometry moving I have to make a choice and sacrifice the render time for the quality.
BUT (because there is always a "but" ) it's not always true that BFBF is slower than other solutions... I mean a little level of noise can be removed with a mild denoiser and this probably will save a lot of rendertime.
Just my opinion

Ale

[uforis]

Hey Alessio,

Thanks for the tip. Yeah I think I will finish the project with BFBF. I guess the trees moving could be making things hard for the LC to remain consistent from one frame to the next. Any further tips about using BFBF specifically? It is interesting the things moving around the scene makes it tough for LC. I'm wondering, are big production studios using BFBF to make their animations for the film industry with VRay, with a super low noise threshold and no render time limit, with a lot of GI depth?

[^Lele^]

I only ever used the LC in movie production, even in scenarios worse than yours, and with the tech a good ten years younger.
The alternative was to use BF with IBL, and a very low bounce count, for exterior shots where GI wasn't important.
Using BF for interiors is ill-advised, if render times are key.
We're of course talking of reaching the same N.T. for both cases, and bouncing light the same amount of bounces (ie. 100 for BF too.).
It goes without saying that reducing the amount of work to be done (higher N.T., lower bounces count) will lead to BF being competitive, but you are then comparing apples to oranges.

More LC subdivs and a higher retrace *will* clear that situation just fine, but will require a bit more experimentation than simply switching to BF and waiting it out.