Cycles Adaptive Sampling

Hi, this was already post on News section but I like to have a thread to discuss/test this patch from Lukas Stockner.
The settings are hard to understand and there are also questions about the UI.
Is Performance slot the right place, should have Adaptive sampling an own slot and so forth.

Patch: https://developer.blender.org/D808

Testfile (Work only with patched Blender): http://www.pasteall.org/blend/31896


This render take 01:08.74 with pure pathtracing (Cycles default) and 00:46.04 with adaptive sampling.
I cant get suitable results for “Real” scenes but I think it is may a setting problem.
It would be nice if anybody upload a Windows build to get more people involved.
I could post a Linux build but it would work only on Opensuse distribution, I fear.

Cheers, mib

Hello,
well there is no build for this still, so no way to test… But your test seems quite strange to me, there are almost no diffuse bounces… This is really not a real scenario.
I am curious about the performance of a lonely object on a white ground, something similar to product shot, since that is a scenario which I use very ofen and I would expect there the method could bring significant improvement.

Hi pildanovak, you are correct, this file was only a start point to discover the settings.
I got also good performance boost on studio scene:
01:21.24 vs. 00:48.28


Cheers, mib

Is there an build available for download - I couldn’t see one in the links above.

I’d like to run some test scenes of my own.

Count me in as one needing a build (Win64).

With the reports of major speedups being mentioned now, it would be nice to get it a whirl.

My OS X build is here if anyone wants it (no guarantees it works properly): https://dl.dropboxusercontent.com/u/1706676/blender_adaptive_cycles_patch_osx64.zip

(side note: please keep comments here, do not post in the patch review page!)

For my personal opinions, the UI needs a lot of work. As is, I think the vast majority of users will only use it through sheer luck. IMO it should be in the samples at, not performance. I don’t think separate warmup and update intervals are useful enough to warrant separate controls, and having update interval defined in total AA samples is going mean you need to change it manually when switch to branched path or rendering a simple scene that only needs <100 samples. Whether there’s actually a better solution than a fixed number of samples is debatable (wall clock time and % of samples have their own issues), but I think it’s something worth discussing.

I tried it on the 2.72 splash screen image (Mike Pan’s ice mountain thing) and was able to get about a 14% speedup. Most of the complex scenes I have take too long to render, I don’t feel like waiting out a test with them. :smiley:

In my experience, it would seem to me like the warmup number needs to be greater than the interval number to get the render off to an optimal start.

In this case, I would say to Lukas that he can remove the warmup sample control and hardcode it as double that of the interval control. Also, don’t you have to change the sample settings manually when going to branched path tracing anyway? I don’t know how one could design a system to intelligently determine how to do it in a way that satisfies everyone for every situation.

I agree, the UI isn’t that great, I’m always open for suggestions here (if you wrote the code, you don’t realize that some parameter might be obscure :D).
A separate tab might be reasonable, the current placement in the performance tab is just due to the tile settings being there.
The possibility to tweak the warmup samples might not justify the separate control, which factor relative to the map interval would you suggest (2 or 4)?
Another thing I noticed is that in the last 2 months, I didn’t touch the exponent setting once, hardcoding 4 might be reasonable.

This would leave us with 3 settings: “Use adaptive distribution” should be self-explaining; the error exponent could probably be improved by adding “1 corresponds to a noise-free-looking image” or something like that; and if someone doesn’t know how the map interval should be tweaked, the default value will work as well.

I’ll have a new version ready in 1-2 days (the debug passes killed the current version, but I already updated it, currently I’m adding Importance, Variance and Sample count as new debug passes) and try to create working Linux and Windows builds (both x64).

Looking forward to it, thank you for your hard work in doing this and thank you for keeping us posted, I think this patch along with the MLT sampling will revolutionize the way Cycles is seen as a viable engine in the eyes of both professionals and hobbyists :slight_smile:

Hi lukasstockner97, 3 settings seams to be reasonable.
Does error exponent above 1 make sense at all, you get only faster render with more noise if I understand this correctly.

Cheers, mib

I have been waiting for this for a long time
The first time I saw it in LuxRender, and wanted it in Cycles

<span id=“result_box” class="" lang=“en”><span class=“hps”>

Hmm. GPUs favor large tiles. Does this work per-pixel or per tile? Does it work with GPU rendering at all?

Hi Piotr, it seams per pixel, the render in post 3 render fastest with 4 tiles.
After som testing I got 01:26.46 vs. 00:40.24, time in post 3 was with 8 tiles.
Faster than with smaller tiles on GPU.

Cheers, mib

The adaptive stopping is per-tile, while the adaptive distribution works per-pixel inside one tile, so activating both will give you per-pixel sampling. GPU is supported, both CUDA and OpenCL, I usually use 128128 on GPU and 1616 (without adaptive distribution) on CPU.

Any win64 build?

Thanks for the explanation Lukas. I’m looking forward to using it :slight_smile:

Out of curiosity, is this a porting/implementation of LuxRender http://www.luxrender.net/forum/viewtopic.php?f=8&t=10955 ?

After looking at the code, I guess the answer is yes (?).

From: https://developer.blender.org/T38401

The code is based on the SmallLuxGPU metropolis sampler, after I first tried the PBRT code, but that one didn’t seem to work nearly as well.

so it will probably be based on Lux’s code.

The quote from T38401 refers to the Metropolis sampler, not the adaptive code. This one is inspired in its functionality by SmallLuxGPU, but doesn’t use the even/odd samples estimator. Instead, I hacked together my own estimator based on sample variance and the TVI function. The most important influence is the Noise-Aware MLT from the Arbitrary-Importance-Functions-for-MLT paper.

Lukas, might I suggest some sane defaults for most values, with only error exposed to the user by default, with the other settings hidden behind an “advanced” checkbox? Things like the exponent value are a bit nebulous to most artists, and even to someone like myself who (mostly) understands what’s going on behind the scenes. Something more quantifiable like a “Quality” value exposed by default would be nice for most artists, with the option to dig into the other values for more technical minds willing to do the required reading. Too many poorly understood values and things start to look like the jumble that LuxRender’s Blender implementation has become.