Faster rendering with lower Reinhard burn value?

[Vizioen]

I’ve been using this trick since I don’t know when, I think it was a trick of Peter Guthrie back in the day, but I’m not even sure it does anything still with the newer versions of V-Ray and if I’m actually messing some data up by using this. As I’m reworking some templates I was wondering if it is still valid (if it ever was).

So basically the trick was in the Color Mapping settings in the render settings dialogue you would set the burn value of Reinhard to something low like for instance 0.3 and the mode set to None (don’t apply anything) and what it would do was speed up the rendering process, because it would tell V-Ray to not spend so much time on the areas with values over 1.0. (I think?).

Could anyone (almighty @_Lele perhaps?) shed some light on this “trick”. Is it still(or was it ever) valid? Or am I messing up some important data for V-Ray to use for certain effects or AA or whatnot. I haven’t had issues or anything just want to understand better. Thanks!

[sirio76]

Reinhard cuts out part of the energy when you lower the burn value, so you will get an image with less dynamic range, the less contrast you have the faster the render.
Today I would never lower the burn value because the speed gain is limited and you will have far less option in postproduction.

[Vizioen]

Well I tested this by subtracting in 32bit float a render on 1.0 from one on 0.3, and indeed I see some minor difference, the 8bit RGB barely has any difference. And (although not very representative because it was a not so complex scene and quite fast), the difference was 14 sec (1.0) vs 11 sec (0.3). I would have to test on a bigger render, I will probably a bit later, but overall the difference is not so bad. I wonder what the render speed difference is on more complex and high resolution renders and if the data I lose over this is actually that bad.

[_Lele]

The approach is not working anymore.
I’ve tested it again today, the differences in both rendertime and looks are negligible.
See attached, the render of a bumped metal with a 10.0f square light reflected (hence the filled highlights.). Max subdivs were set to 200 (or, 40000 camera rays.), noise threshold was left at 0.01.
From left to right, the beauty, the beauty measured, normalised, and colorised (it will show gradations better), and lastly the samplerate RE.
Bottom row, the differences (Modulo of a-b) between the beauties and the sample rates.

This is because we now have a number of other technologies that would not work correctly with the old color mapping approach.
We are investigating ways to ameliorate the rendering of very strong highlights, but we haven’t got anything to show just yet.

​

[M.Max]

I’ve been using the same trick for years when I need to reduce render time and don’t care much about the 0.1% accuracy difference.
the difference is much less compared to years back( we got cleaner image now and higher render time ), but it is still there in extreme cases like the render below where I’ve increased the exposure on purpose to make the difference more clear .

Burn value 1.0 vs 0.05 ( 9m 42 s to 8m 11 s)
Both with color mapping set to None , so we can maintain the dynamic range and only affect the sampler .

Image 01 :Raw render ( can’t visually see the difference)

Image 02 :Tone mapped render (can’t visually see the difference)

Image 03: the raw render but underexposed by 8 stops ( there is visible noise in both but the one with lower burn value show more noise )

[_Lele]

Yep, the increased noise is a side effect of the lower burn reducing variance, and hence sampling.
The log will tell you exactly how many rays, of which type, were cast for the image, as well.

[M.Max]

@_Lele

Yep, the increased noise is a side effect of the lower burn reducing variance, and hence sampling.
The log will tell you exactly how many rays, of which type, were cast for the image, as well.

Yes, exactly. the sampler will do a bit less work there .
I’ve posted these tests to show @Vizioen ​ the side effect of this “trick” to use it carefully.

[Vizioen]

Hi guys, thanks for replying elaborately. So doesn’t this show that the approach actually still works, albeit not so good as it used to be? Or am I misunderstanding?

I find a 15% decrease in render time (in the case of M.Max’s scene) a nice reduction actually. The extra noise is in most cases acceptable for me.

[_Lele]

Compared to how it was, it’s hardly worth it (it used to decrease rendertimes a lot more, with worse side-effects.).
Mileage will vary, but as i have shown it won’t cut down times on intense highlights appreciably, which is where most of the sampling time goes.
Feel free to try it on a few real-world samples, and if it is worth the bother for you, go ahead and use it.
I wouldn’t suggest it for general use, however: much more rendertime can be had spending time optimising other aspects of a scene which are often left untouched (f.e. moving from max bitmap loaders to vraybitmaps can shave 30%++ off a render.).

[Vizioen]

@_Lele

Compared to how it was, it’s hardly worth it (it used to decrease rendertimes a lot more, with worse side-effects.).
Mileage will vary, but as i have shown it won’t cut down times on intense highlights appreciably, which is where most of the sampling time goes.
Feel free to try it on a few real-world samples, and if it is worth the bother for you, go ahead and use it.
I wouldn’t suggest it for general use, however: much more rendertime can be had spending time optimising other aspects of a scene which are often left untouched (f.e. moving from max bitmap loaders to vraybitmaps can shave 30%++ off a render.).

Thanks Lele. Concerning the max vs vray bitmap loader, that’s a crazy amount. Unfortunately, running the converter on the whole scene sometimes messes up a few things: for instance, multitexture plugin doesn’t like VrayBitmap. I requested having a convert only selected option a while back but afaik it hasn’t been implemented yet. It was taken into consideration. Perhaps you could bump its priority a bit, pretty please

[_Lele]

@Vizioen

Perhaps you could bump its priority a bit, pretty please

We’re slightly behind schedule with this, but we’ve been working at improving the converters.
The hope is that when they’ll be finally out (as soon as we can manage.), they’ll be a step forwards in both features and usability.

[Vizioen]

@_Lele

We’re slightly behind schedule with this, but we’ve been working at improving the converters.
The hope is that when they’ll be finally out (as soon as we can manage.), they’ll be a step forwards in both features and usability.

Great to hear, thanks Lele and team.

[kosso_olli]

@_Lele

moving from max bitmap loaders to vraybitmaps can shave 30%++ off a render.

That sounds a lot! On all the tests I did over the years, the difference between Max and V-Ray bitmap loaders was negligible. Can you please elaborate on which cases the speedup is noticeable?

[_Lele]

It’s scene and camera dependent, of course.
In your case, you’re much more shading than texture-heavy (headlights, car paint, tons of SSS), when compared to a complex architectural scene with many hundreds of textures (say, ~600 for the evermotion scene i last tested yesterday.), but with comparatively simpler shaders.
Further, as the vraybitmaps load on demand at rendertime, unlike the max ones that preload all the maps before the render starts, there are important benefits by virtue of skipping stuff (f.e. a scene that sees a little of the interiors from the outside, or vice-versa.).
Scenes i used to benchmark the loader and .tx files were between 2% slower (sharper filtering of the textures may also lead to slowdowns, but to render more details) and 38% quicker depending on scene and camera view.

[Pixelcon]

On a bit of a side note, should we be adjusting the filtering strength on vraybitmaps to boost sharpness, or leaving it largely unadjusted from its 1.0 default?

[_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.