'Blocky' reflection pass

[Pixelcon]

But what i'm trying to say is that it's not a bug, it's the expected behaviour for the LC in a set of situations, when retrace is off.

Understood

I will send this file over sooner or later this week.

[^Lele^]

I asked Vlado for confirmation (he's the author), it should indeed be always left on: the current implementation of the LC requires it so.

[kosso_olli]

I asked Vlado for confirmation (he's the author), it should indeed be always left on: the current implementation of the LC requires it so.

Then it would be best to get rid of the checkbox, as it evidently creates artifacts and confusion.

[Pixelcon]

Then it would be best to get rid of the checkbox, as it evidently creates artifacts and confusion.

Or perhaps hide it with the basic/advanced UI modes.

[^Lele^]

Agreed on both points.

[Joelaff]

YOu, you want retrace to some degree Maybe you can get away with it off in stills, but for animations, you need it. Granted I try to keep it as low as possible, and you don't always need the default of 8.0 for animations, but you only rarely need higher than that.

[Pixelcon]

YOu, you want retrace to some degree Maybe you can get away with it off in stills, but for animations, you need it. Granted I try to keep it as low as possible, and you don't always need the default of 8.0 for animations, but you only rarely need higher than that.

I did some tests for a still I'm working on and while having it on did indeed make a difference, it was miniscule and I cannot honestly say if it looked better. I will I guess from now on go forward with it on a very low number (like 0.1 or something)

[^Lele^]

There is an issue here which should be clarified: James uses IRMap as primary engine, on a *very* detailed scene.
As the detail is often sub-pixel, the *only* way he can get away with decent rendertimes is without retrace at all.
The moment retrace is turned on, at any level above 0.0, the IRMap will collapse in speed, the final render even more.
So, for size, from a 1h20 minutes for the original without LC and with many visible artifacts in GI (splotchiness, blockiness in SSS shaders, and generally very low detail lighting. If one can get away with it, great.), turning retrace on shoots the rendertimes at over 7 hours, the IRMap alone taking the hour and something to compute.
This is expected, as the IRMap is a technique which required low scene variance to work well (it is 20 years old.), and it will collapse under its own weight if it tries to get married with current sub-pixel details.

Switching to defaults (so, BF/LC, retrace at 2.0), and doubling the NT (truth be told, i also switched to vraybitmap loaders and made changes to the SSS mode) produces an image that's very denoisable, without trace of splotchiness, for twice the original rendertime, so about 2hours and 30 minutes for a render that is better under most metrics than the one done with the IRMap, and requires zero setup.
Now the rendertimes versus quality depend exclusively from the noise threshold, and the denoiser will take care of blurring per-pixel noise properly (with IRMap, blurring splotchy GI only produces bigger splotches. denoisers are expecting QMC-like noise.).

It is a paradigm shift: instead of blurring just the GI, thereby eliminating its noise, one conditionally blurs the entire image with its per-pixel noise, wherever it may come from.

[Pixelcon]

There is an issue here which should be clarified: James uses IRMap as primary engine, on a *very* detailed scene.
As the detail is often sub-pixel, the *only* way he can get away with decent rendertimes is without retrace at all.
The moment retrace is turned on, at any level above 0.0, the IRMap will collapse in speed, the final render even more.
So, for size, from a 1h20 minutes for the original without LC and with many visible artifacts in GI (splotchiness, blockiness in SSS shaders, and generally very low detail lighting. If one can get away with it, great.), turning retrace on shoots the rendertimes at over 7 hours, the IRMap alone taking the hour and something to compute.
This is expected, as the IRMap is a technique which required low scene variance to work well (it is 20 years old.), and it will collapse under its own weight if it tries to get married with current sub-pixel details.

Switching to defaults (so, BF/LC, retrace at 2.0), and doubling the NT produces an image that's very denoisable, without trace of splotchiness, for twice the original rendertime, so about 2hours and 30 minutes for a render that is better under most metrics than the one done with the IRMap, and requires zero setup.
Now the rendertimes versus quality depend exclusively from the noise threshold, and the denoiser will take care of blurring per-pixel noise properly (with IRMap, blurring splotchy GI only produces bigger splotches. denosiers are expecting QMC-like noise.).

It is a paradigm shift: instead of blurring just the GI, thereby eliminating its noise, one conditionally blurs the entire image with its per-pixel noise, wherever it may come from.

I do agree (and excuse me I haven't replied to your email yet but I did pore over the renders you send) that the defaults and the denoiser did a fantastic job with that render. Not all renders I do use IR as the primary engine. It is absolutely used as a last-resort when a deadline is looming and quality must take a dive. In My previous post about testing different retrace-threshold settings is indeed using BF+LC. You might understand why I am a bit concerned that IR will be removed from Vray in the future. That, for me, would is akin to taking off my backup parachutes before going skydiving...

One other small note: While I am super impressed that the denoiser was able to do what it did in your tests, I presume that means the glass material must have the refraction 'affect channels' set to all? If that's the case, then I lose masks for any objects that exist behind the glass... Unless you have some clever suggestion that I'm unaware of, that would required a re-render of some sort just for masks.

[^Lele^]

If that's the case, then I lose masks for any objects that exist behind the glass...

In your scene, i'm looking at some change due to the glass set to "affect all channels", but contrary to what you mention: i see the masks for what was behind glass showing up (f.e. id1 and id5).
Consider this example:


Glass pane on the right is a preset glass, the one on the left has "Affect all channels" active.
The teapot is seen only behind the left panel.

[Joelaff]

Very different ball of wax if you get into a crazy complex scenes. Then you have to spend a lot of time trying to optimize things. Certainly the defaults are much easier, although sometimes much slower too.

I don't use the denoisers because I have yet to find settings that I am happy with that don't throw away way too much detail. (Will try again over the holidays perhaps.) Does the denoiser require Affect All Channels to be on to work with refraction? Only with glossy (soft) refraction like you example, or all refraction?

In the past for complex scenes I have used the Light Cache, and cached that to a file. I see the "Use Camera" option has been removed!?! Ugh! Stop removing features, Chaos. That was very useful. You used to be able to cache a single LC file with samples from your entire camera path. So you only have to calc the light cache once and save it.(This of course would not take into account moving objects, but they could be handle separately if needed and comped in.) Now I guess you would have to cache every frame's light cache using the %04d suffix to the name of the file.

Occasionally I have even had Light Cache as *primary* work well for some scenes, but that can get splotchy really quickly.

[^Lele^]

The camera path technique had unavoidable limitations which led to either severe flickering, or excessive rendertimes (where the pixel would get 100 BF bounces per evaluation at rendertime.).
Not to mention the catastrophic weakness to having to change a single object's shader along the sequence, the potentially very lenghty single-node process, the utterly unknown distribution for spatially very lenghty sequences, and so on and so forth.
Now, for animations, we have a different, much more solid approach, which is the oversampling of each individual frame (3000 subdivs, or 9x the samples of the default of 1000 subdivs.), coupled with a higher sensitivity to LC sample quality (the retrace parameter at 8.0 up from 2.0) in order ro avoid flickering across frames.
The benefits, besides the fact it doesn't flicker no matter the content, are that the LC can now be split across blades, and should a node fail to render a frame, only a single frame's worth of data would be lost, whatever the reason.
Likewise, any kind of change at any point in the sequence will cascade the minimum amount of overall work, unlike for the old method.
Further to all this, the LC is pivotal to most of the adaptive lightling and GI techniques, which are initialised per frame, and wouldn't work with sequence rendering, leading to potentially enormous time losses if those were to be deactivated.

[Joelaff]

The camera path technique had unavoidable limitations which led to either severe flickering, or excessive rendertimes (where the pixel would get 100 BF bounces per evaluation at rendertime.).
Not to mention the catastrophic weakness to having to change a single object's shader along the sequence, the potentially very lenghty single-node process, the utterly unknown distribution for spatially very lenghty sequences, and so on and so forth.
Now, for animations, we have a different, much more solid approach, which is the oversampling of each individual frame (3000 subdivs, or 9x the samples of the default of 1000 subdivs.), coupled with a higher sensitivity to LC sample quality (the retrace parameter at 8.0 up from 2.0) in order ro avoid flickering across frames.
The benefits, besides the fact it doesn't flicker no matter the content, are that the LC can now be split across blades, and should a node fail to render a frame, only a single frame's worth of data would be lost, whatever the reason.
Likewise, any kind of change at any point in the sequence will cascade the minimum amount of overall work, unlike for the old method.
Further to all this, the LC is pivotal to most of the adaptive lightling and GI techniques, which are initialised per frame, and wouldn't work with sequence rendering, leading to potentially enormous time losses if those were to be deactivated.

Okay. Okay!

Gotta say I have not had a desire to use the cached camera path since at least VRay6, since the "animation" setting seems adequate as you describe.

I do wish there was some way to make everything faster... Once you farm reaches an appreciable size, adding more nodes doesn't make as big of a difference (e.g. one more node when you have 40 nodes is not a big percentage gain).

[Pixelcon]

In your scene, i'm looking at some change due to the glass set to "affect all channels", but contrary to what you mention: i see the masks for what was behind glass showing up (f.e. id1 and id5).
Consider this example:


Glass pane on the right is a preset glass, the one on the left has "Affect all channels" active.
The teapot is seen only behind the left panel.

I remember now it wasn't the masks that was the issue (sorry for making you jump through that hoop for nothing), but the reflection pass ends up as a bit of a mess.

[^Lele^]

Well, the data that used to be contained in the refraction -only- is instead passed through to the respective channels. so yeah, compositing will work differently.
Reflection though won't change, it has its own set of controls for what it affects.