Faster rendering with lower Reinhard burn value?

[^Lele^]

I'm glad you asked: the sharper isotropic filter should work just fine with blur at 1.0.
It'll already pick a higher resolution mipmap, behaving similarly to a slightly lower blur value for max bitmaps.
We're planning on an option to reset it for all/selected vraybitmaps, but if you prefer, i can add the option here, or give you a code snippet to mass-change them.
I'm sure there are scripts in the wild that allow for that too.

[Pixelcon]

Yes VMC is able to take care of that, but it might be worth putting in a checkbox for it in your script...
And thanks for the info, of course, as always!

[^Lele^]

It's done.
As a bonus, the new anisotropy model is turned on as well.

[Vizioen]

Thanks Lele much appreciated

[^Lele^]

I have conducted more tests on the Op's approach, to better understand what exactly happens to sampling.
The short version is simple: the bigger the speed gains, the higher the noise level in the image.
The tonal compression that happens using Reinhard Burn isn't confined to values higher than 1.0 (so, "invisible" at the rendered exposure), and the spillage of lower sampling will impact also transitional areas (f.e. the falloff of a light cone).
That the noise may or may not be visible is not relevant: one has to assume that one sets a noise threshold fit for their intended use (f.e., the image will need exposing up, or the client's display devices add unwanted contrast, etc.), and the fact that the uniformity and amount of noise level is impacted should provide for some concern.
This said, i tested with extreme values, and obtained the most extreme of results: the speed up is more than significant for the tested scene (about 25%), but the difference in noise level is also very visible (i have kept the N.T. to a visible level on purpose, of course.).
The contact sheet is too big to attach here, so i linked it on GDrive.

The top row is the default render settings (Max AA subdivs at 200, N.T. of 0.05), middle row is with burn at 0.01 and no CM applied to the render, while the bottom row is the same, but with the CM burnt into the render, so we know what the sampler has to work with.

In the first column, it's important to check the "Max" values, as they determine the final image's range.
Notice how the third row is around 1.0f as maximum, whereas the original image carried a 1400f max in places.
This is what drives lower sampling around the image.

The second column contains the noise analisys (central pixel against average of 3x3 kernel around it). To a brighter pixel will correspond a higher noise.
Notice how the second row is brighter than the first, sure sign noise in the ouput is higher there.
Also -for confirmation- notice how the very low range third row is low also in noise.
The sampler works towards this image matching the set noise threshold, and then (conditionally) multiplies this render back up to the results we see in row 2, thereby also multiplying noise amount.
In the tonal-compressed render, noise is on average some 25% higher (it's not a coincidence that the render took 25% less time.).

Lastly, i added the sampleRate REs, but because the max AA was very high, it's hard to tell what goes on in them.
So the fourth column uses another noise level analisys to then normalise their values to show the different sampling profiles.
Notice how the second and third row are essentially a match, with ample areas looking "patchy", where the same areas in the first row are nicely filled in. (f.e. the central columns, the top-left deck, the top central woodden panels, and so on.).
Noise there will be higher, and there is a second, important point as side effect: denoising won't work as well.

This is because the tonal-compressed render decouples the noiseLevel Re from the actual noise in the image as, unlike for the third row, we decouple what the sampler and the final render need to achieve by not applying colormapping to the image.
The noiseLevel Re will then be wrong precisely in the places where noise will be higher, suggesting it's lower than it is, and as a result the denoising there won't be as effective.

Of course, there are sliding scales to this, a higher burn will have less issues, but that's because sampling will be more uniform, and rendertimes will be higher.

TL;DR: The OP's mentioned trick comes at a cost in both noise level (becoming unpredictable for level and distribution), and denoising quality.
Quicker renders will have more noise, non-uniformly distributed, and not as well cleaned up by denoising.
The suggestion is to not use it at all, as the UI hints by leaving the options hidden in the "advanced" section.

As a reference to my previous mention of vrayBitmap: the scene rendered in less than 18 minutes, after conversion, compared to 21 and change (about 15%, give or take. The scene has about 600 textures.).
This, while matching noise levels and providing for slightly sharper detail in places (not all textures are very high resolution in this scene.), but otherwise leaving the image essentially identical by the pixel.

[Vizioen]

Thanks Lele for all these tests and very interesting analysis. This also explains why my results with the denoiser were always awful and I couldn't understand why people even used it in the first place. I'll refrain from using this trick. I'm glad I asked, and now I even understand why .

[^Lele^]

I'm glad you took the analysis the right way!

my results with the denoiser were always awful and I couldn't understand why people even used it in the first place.

Ouch, i'm so sorry to hear this.
Keep a decently high Max AA (so it doesn't clip/red in the samplerate RE), and only play with the noise threshold to drive render speed.
Then the denoiser will work its magic, and you should be able to get away with much higher noise thresholds than previously, for a higher final quality.

This thread was super useful and started some slightly left-field discussion on sampling with the devs, so thanks for bringing it up again!

[kosso_olli]

the new anisotropy model

Did I miss this?

[Joelaff]

...This also explains why my results with the denoiser were always awful and I couldn't understand why people even used it in the first place. ...

My results with the denoisers are always garbage, even with default settings, or min 1 Max 100 (Universal) settings, etc. They destroy way too much detail. I find them useless in production for VFX work.

But I guess somebody uses them?

[^Lele^]

Did I miss this?

Highly likely you've already used it!
EDIT: Here's the paper about it.

[^Lele^]

They destroy way too much detail. I find them useless in production for VFX work.

I shall state i have zero experience of denoising in VFX productions (i'd have been hanged.), but have you tried the v-ray denoiser with multi-frame denoising?
If you have, have you tried it recently, since the introduction of the albedo RE?
Very curious to hear your thoughs!

[Joelaff]

I shall state i have zero experience of denoising in VFX productions (i'd have been hanged.), but have you tried the v-ray denoiser with multi-frame denoising?
If you have, have you tried it recently, since the introduction of the albedo RE?
Very curious to hear your thoughs!

Yes, did the standalone denoiser, hoping it would be a lot better, and was still disappointed. It always seemed to throw away too much detail. With a wet/dry mix it may have looked a tiny bit better than not-denoised, but having to deal with all the data of the extra denoisers passes, and the extra steps of denoising (I know I could script that in Deadline) it just didn't seem worth it.

As you know we are typically ADDING noise to VFX elements anyway (render them a little cleaner than needed and a little sharper than needed and then adding noise and softening a touch).

Tries standalone, and tried all the various one-shot denoisers too.I think the Intel had the most promise, but still threw too much away. Post denoising with the likes of Topaz AI stuff seemed promissing, though they are seeming to head towards more of the "app" feel in their latest versions, which I can't stand. (simplified big buttons, terrible UIs with no discoverability-- Just like modern Apple stuff-- breaking every rule that was in the original Apple Human Interface Guidelines that made software so usable. Change for change's sake is ignorant.)

When was the Albedo RE added in to the equation? I think the last time I tried it was around VRay 6.0 (no hotfix).

[M.Max]

I have conducted more tests on the Op's approach, to better understand what exactly happens to sampling.

Thanks for the detailed explanation. This was really useful !

[^Lele^]

When was the Albedo RE added in to the equation? I think the last time I tried it was around VRay 6.0 (no hotfix).

Mh, can't quite recall.
V6 is a sure bet, and the element should show up as "albedo" in the RE list while rendering.

[Vizioen]

So the Albedo RE only shows if you have a Denoiser RE?