Why IrMap over Brute force for animation rendering?

[^Lele^]

I write wholly ready to stand corrected, so take it with a pinch of salt.

In essence, LC "splats" samples (Let's hope Vlado will never get to read this description of the LC by my hand...).
So one LC samples covers a screen area subtending "some" geometric detail.

In its original form (before leak prevention added samples where geometric detail required it. so 2.x ), this was it, and when the BF GI queried the LC sample for secondary lighting information, if the LC sample was subtending very high detail geo, the BF would get some of that secondary info wrong, returning a pixel-accurate wrong GI solution (your "splotch", or "leak", or "cut" in a seam line).

Now, the issue is partially cured by the Leak Prevention algo, which will take care of fine-graining the LC where required, and shoot samples in those areas which will need it, and partly with Retrace.

So when the BF GI queries the LC, if the LC isn't so "sure" of its sample quality, it will delegate correct secondary sampling to the BF engine, incurring in a render time penalty to ensure a correct GI result.

For animations, the raising of per-frame LC samples is done to ensure a densely oversampled LC solution, which is a very general method to stabilise means, all the more important when said solution will change by an unknown amount in the next frame, while needing to blend right in with it.
The need for a higher Retrace value is derived by both a higher number of LC samples (don't quote me on this, but it ought to make the retrace threshold harder to hit, thereby tending to overuse the LC @ 3000 subdivs, compared to the one at 1000 subdivs), and by said need for temporal coherence.

as a general rule of thumb to go about setting these up, you may try this:

1 x 1k LC subdivs (1k) -> Retrace of 2.0^1 (2.0)
2 x 1k LC Subdivs (2k) -> Retrace of 2.0^2 (4.0)
3 x 1k LC Subdivs (3k) -> Retrace of 2.0^3 (8.0)
4 x 1k LC Subdivs (4k) -> Retrace of 2.0^4 (16.0)

(maths notice: retrace is linear, subdivs squared. hence the correspondence above)

Notice the above will keep the retrace to LC ratio consistent as the LC gets denser and more defined.
It goes without saying that if your 1k LC subdivs solution needs a higher Retrace to be clean (say, 2.5), then the above would need to have 2.5^x instead of 2.0^x to maintain the ratio.

If your head's a bit hurting, right now, well, you know why we like a simpler approach to it all: 1k LC subdivs, 2 retrace for stills, 3k LC subdivs, 8 Retrace for animations. Raise Retrace slightly if needed. ^^

[piotrus3333]

Oh, please believe I've tried ... no luck so far.

https://forums.chaosgroup.com/showth...o+retrace+file

[NicoC]

https://forums.chaosgroup.com/showth...o+retrace+file

Thanks a lot ! you seem to be more efficient than me at searching

[^Lele^]

that's for retracing of Speculars only.
The post is from 2011, and since then it's been extended also to GI, which i believe was the initial question's topic, and for that part i also think it's a slightly different heuristic.
Again, i am *not* entirely sure, so i'll defer to sounder advice.

[^Lele^]

f.e.: these are two renders in the exact same vein as the ones done by Vlado back in the other thread, but with a diffuse-only scene.
The saved LC is pure red, it's loaded, and the render is run on top.
Retrace at 2.0, then at 8.0, then at 16.0.
Besides the direct light from the IBL, notice how it's not a simple distance which introduces non-red Hues, and how the more detailed geometric parts are the first to get special treatment, especially when their lighting contribution to the solution is higher, if the area is covered in caustics, and so on.

[^Lele^]

the correct render

[sharktacos]

Thanks for detailed explanation. The formula for increasing LC in relation to retrace is quite helpful (maybe a future tooltip?)

Reading the linked thread, it appears that Vlado is saying that the threshhold corresponds to the distance the ray travels from the camera. If it is set to 0 then it just uses LC, if it is set to 1 then objects that are pretty close will use GI, but farther objects will use LC. Setting it to 2 makes the distance twice as far so there is more stuff that is within the distance threshold of the secondary bounce ray which will get BF, and the further stuff which outside of that threshold will get LC.

These threshold numbers are not fixed unit distances (like 1cm and 2cm), rather they are, "a coefficient that takes into account the light cache sample size and the properties of the surface that spawned the secondary ray (i.e. how glossy it is etc) so that you get an optimal result."

Okay, I have no idea what that means, LOL! So I guess that just means they are some fancy render voodoo. The point however is that smaller values will move the line closer to the start of the ray, and larger values will move it farther. The higher the number, the more it will use BF instead of LC, making it slower but more accurate.

Did I get that right?

[^Lele^]

Yes, raising Retrace makes it slower, but helps removing (entirely) splotches.

[NicoC]

Again, thank you Lele for the details you provide.
However, I'd still have a question: I don't know what precisely happens "under the hood", but don't Retrace and Leak Prevention kind of double the work ? it's a bit obscure to me ...

Thanks.

[^Lele^]

Again, thank you Lele for the details you provide.
However, I'd still have a question: I don't know what precisely happens "under the hood", but don't Retrace and Leak Prevention kind of double the work ? it's a bit obscure to me ...

Thanks.

I don't think i understand what you mean.
In which way do you think they overlap?

[NicoC]

I don't think i understand what you mean.
In which way do you think they overlap?

I mean, both are supposed to help in enhancing LC precision, right ? with the aim of reducing LC flickering ?

[^Lele^]

Ah i see.
Well, yes, but one's an interpolated method, the other an oversampled one.
In other words, the LC excels at distributing light fluxes through BOUNCES but the tradeoff is it's not so precise SPATIALLY.
We do not want to give away the former entirely to BF (that'd be quite slow.), but we will need BF to compensate for the spatial imprecision of the LC.
What Leak Prevention does is done at the LC stage chiefly to ensure samples don't leak through thin walls, and that noticeable geometric discontinuities get a SLIGHTLY more fine-grained sampling.
The retrace is in fact done by the BF engine (and that's perhaps why you are a bit confused. the option is in the LC as retrace is done ON the LC samples...), on whatever sample the LC cast.
If an LC sample bled (ie. leaked, or passed through a thin wall.), you may need a very high Retrace value to care for that, which would likely force many other non-problematic areas to go through BF tracing.

Activating Leak Prevention has a negligible cost (a few more LC samples, not many thousands of rays per pixel...), and provides the BF engine with a better LC solution to work and in case perform Retrace on, which can be then safely kept low-ish.

[NicoC]

Lele, you're a knowledge mine ! thanks a lot. It's much clearer for me now
You write that activating Leak Prevention has a negligible cost, so I guess it could be ON by default, don't you think ? also, again an obscure value: 0.0 sets it OFF, ok, "default value of 0.8 should be enough of all cases" ... one has seen clearer ! :P then a question comes to my mind, why not simply activating it, at 0.8, and hide it from the UI ?
Well, I guess I'll activate it at 0.8 in our maxstart.

[^Lele^]

Watch out, you may already have a V-Ray Setting saved as "default".
LP is in fact set to default at 0.8, and hidden from the default view.
Try renaming or deleting that V-Ray preset (render settings, advanced, presets), and resetting V-Ray, and you should see the originally shipped defaults again.

[NicoC]

ok, Lele, thanks again