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]

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]

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^]

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]

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]

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?