Testing Builds? 
Better quality with npr and less rendertime: Great !
Patch please! 
If I read that right, you are talking about saving a bit more time by the user not choosing to do the comparison on every pass?
If so, then does that mean that the user will be able to set how many passes will be rendered before the next comparison?
Well i thought that each pass had a fixed number of samples, and that with npr they were just âbetter distributedâ, at the cost of more time to calculate where to place them
If I read that right, you are talking about saving a bit more time by the user not choosing to do the comparison on every pass?
If so, then does that mean that the user will be able to set how many passes will be rendered before the next comparison?
it is not so slow you think - i think it make cycles only 1% slower
Well i thought that each pass had a fixed number of samples, and that with npr they were just âbetter distributedâ, at the cost of more time to calculate where to place them
no, every pixel is processed between 1 and max nr of samples per pass.
ok, and how does plain cycles work instead?
1 sample only each pass
so for example if i have a 1000x600 px render each pass is computing 600000 samples, while this npr stuff computes a lot more each pass, right
I think he means based against the noise map to determine which pixels get an additional sample or two(or however many)per passâŚI could be totally wrong though.
this is how i thought this npr was:
normal passes, 1 sample per pixel
every X number passes (X is settable?) a noise-check is done and a b/w noise-map is generated (where white are instable pixel, black stable ones)
then again normal passes, 1 sample per pixel - but now that a noise-map exists, for the next X number of passes only the pixels that are in the brightest areas of the map will be sampled. A threshold should be set to decide how stable(dark area) a pixel should be to get ignored in the next passes. This threshold could be considered as the âfinal qualityâ parameter, since when the noise map is completely under it the render will stop
could this work? could this be quicker?
an adaptive sampling method, it sound really goodâŚ
it works so:
here is a buffer called minimap - every 16 (user setting) samples are stored here
after 16 samples (=frame) - this buffer is compared with rendering, cleared
and filled again later with 16 samples (next frame). this create that noisemap.
after 2 frames - npr is activated and render every pixel between 1 and max samples - based on how bright the noisemap is. gray pixel are rendered with half of max samples.
this slow down passes - but samples/pixel-rate is the same
the effect of this is:
samples move from non-important pixels to important pixels.
if your noise-free zone need 1000 samples for good quality,
it is possible, that noisy areas are rendered after 1000 passes with 10.000 samples.
the idea of NPR was to auto-detect this areas - this is very difficult.
it is not 100% perfect - but it works ok
renderings look a bit better - so you can save a little bit time
it is a experemental feature.
are you going to submit a patch soon, or, is it still too early in itâs development/tinkering cycle?
npr is done - but i need to add gui-controls
i will add also some next simple features (noise measure, object/material samples, stop sampling)
and then i will pubish it - in some days
Console output:
render pass / samples per pixel / mean noise level per pixel
mean noise level - is just a trick or hack
it works so:
every 1. sample is saved on buffer #1 and 2. sample on buffer #2
after a pass, i compare both buffer - and calc mean noise level
seems to work - it go more or less lower
remember: it is pixel based, not picture based!
after pass 100, i get 218 samples per pixel and / 0,039 noise per pixel
interesting also: material ball example - is more noisy (higher level) than simple monkey head
Reading this again and found that itâs very similar to multiple passes in yafaray, though I donât know how it does the ânoise detectionâ part. Still, i find this concept really cool âŚi wish could code, but I canât
hmmm⌠i have a problem with integrating new cool object/shader settings.
it is more complex i thought
The Kernel is separated from other source.
I have no direct access to scene/object/shader from Kernel
So i decided to add that settings later, if i understand code 
New Feature added (back_stop) - not really clean yet (AA-issue), but huge speed increase for images with big background areas:
it works so: after nr of samples (user defined) - path tracing is full disabled for background pixels
so i set it to 1 (only 1 sample for background!!!) - and look
32 samples test
cycles: 31 sec
with back_stop=1: only 18 sec
this should never used with DOF!
For what seems to be a simple idea it sure has what appears to be a big decrease in render time, keep up the good work.
Also, I know you said before that the patch will be released when ready, but I and others would appreciate it if you at least give us an initial version of your patch with just the NPR rendering and the back_stop functionality. Not only will that help in the testing of the patch due to the wide variety of scenes it will likely be used on, but it will also help to promote your work (and possibly lead to some of this being commited to Trunk just after the 2.62 release) 
^+1!
Patch! Patch! Patch! 