Testing noise levels in OTOY’s Octane Render

Not so long ago from publishing this piece OTOY, the developer of Octane Render released first version of 2.1x development cycle. Among other welcome changes & new features (like render passes) speed improvements came along too.

“We improved the sampling in the direct lighting and path tracing kernels. In most scenes this should reduce the time to get to a similar level than before. And the sampling is now more optimized in a multi-GPU environment and in network rendering.” – wrote Marcus a.k.a. Abstrax (source: OctaneRender™ Standalone 2.10 via OTOY’s Release Candidate sub forum).

So what are these new optimisations exactly? Here is a bit more info:

“We also implemented a new path termination strategy, which is a bit tricky to explain: In the past the there was this ominous pin “RR probability” which in most cases only worked good when set to 0. With the new algorithm we try to provide a system where you can tweak render speed vs. convergence (how fast noise vanishes). Increasing the value, will cause he kernels to keep paths shorter and spend less time on dark areas (which means they stay noisy longer) but may increase samples/second a lot. Reducing the value will cause kernels trace longer paths in average and spend more time on dark areas. The current default of 0.3 works good in most scenes, but play with it. For example, in two interior test scenes it actually payed off to set the value to 0.5 – 0.6 which increases the samples/second a lot and then just to render more samples.
The direct lighting and path tracing kernels also have a new option “Coherent mode”, which increases the render speed, but causes some “flickering” during the first samples/pixel and should be mainly used for the final rendering and if only if you plan to render 500 samples/pixel or more.

The three changes above together should help you to speed up rendering quite a bit. How much depends on the scene of course.”

Needless to say speed improvements were more then welcome for majority of users as 2.0 brought a bit of a slow down. It is somewhat understandable considering addition of new features like displacement, fur, etc. – You can’t expect get better speeds with additional complexity (added with features) on a code. But again OTOY’s team worked things out, made some improvements & came back with solution. How does that work? Well, that’s what I’m going after..

Problem?

Now after some tweaks You might need different amount of samples in order to get rid of noise & that brings up a challenge : How to test things out?

Back then (at 2.0 days) someone at OctaneRender forums said (I rephrased) that we need less sampless to get cleaner image & thus judging performance from samples/seconds perspective isn’t the best way to look at speed.

You can always do that test in old fashion way, just to render a scene, save out, tweak a thing or two, render, save out..after that simply try to compare images side by side. However that takes insane amount of time & again I don’t see a lot of those around who would like to invest their time into such test.

Solution?

Latelly I’ve noticed a tweet from BOXX technologies (well know boutique builder specialising in building custom workstations for VFX, CG work). They were trying to come up with an algorithm to compare render times on CPUs & GPUs runing Vray RT.

The methodology that was used in their tests came very interesting to me. They’ve used a plugin called Image Quality Calculator developed by the University of Manitoba’s Physics and Astronomy Department that runs on ImageJ, Java-based image processing program developed at National Institutes of Health.

Then I though to myself: What if, we could try to use this for testing out noise in OctaneRender to figureout differences between versions or how newly introduced parameters effect end result? We can’t compare samples or speed – but with this tool we can compare noise output after certain amount of time & that’s what matters most!

For sure this plugin isn’t perfect & might have it’s own caviats.. I’m looking forward to come out with some scenes & tweak bits here & there trying to observe their influence on speed, but for now I simply wanted to share this idea with You.

What do You think? (drop a line). Any ideas about how to take the most of this test are more then welcome Guys, as in the end (hopefully) this will give us (end users) better understanding of how all these different parameters work together to help us reducing noise.

To be continued..