Cycles noise again..

Well today i had an indoor render scene, lights from outside, and inside.
Some complex materials, tile marble floor with tile reflection, stone walls etc, the whole shabam…

Anyway, i’m kinda… confused or maybe that’s not the right word here.
I used branched path tracing like
(non squared)
diffuse 10
glossy 5
transmission 4
mesh light 4

For AA samples while working and for quick model previews, i used 4 AA samples (quick preview) 24 AA final
Now most will say 24 AA samples dude your settings are way to low get serious…
Your are right but it wasn’t my final - “good final render” quality yet, just a good edit setting for the scene.

So for the definitive - “good final render”, …well that’s the part that amazes me so much…
No really why does … this… well
I tried 80, 400, 800… 2000, 4000
And finally i came to realize that it required 1600 AA samples (6 hours on my octo core). :eek:
to get rid of most grain like noise
( i never had spike like light noise, as i used proper glass material, and light (and reflection) where not extreme
so clamp settings didnt matter that much in my render.)

Before you say… I know you can do all kind of noise reduction tricks using various smart -post processing- filters.
( things like this : https://www.youtube.com/watch?v=as_Wrpmb5BI )
There is something that i fail to understand here… something to me seams wrong, in some kind of way.
Like if would ask how strong is this nail, ehmm well i’ll test and i hammer it down 1600 times before i give it my quality stamp, if a person would see me doing that he would call 911 for some mental emergency.
Don’t get me wrong here i do admire Cycles and the people who created it, its amazing
But it feels to me something needs fixing done differently.
The tool has got good sides, but other sides might work better if there was some kind of a fix
That used the math in a different way.

As when we raise AA samples enormously, the difference between 800 and 1600 samples is really tinny
In fact 3200 AA samples would be even smaller.
Dough in contrast the difference isn’t that small as expressed in render time.
1600 AA samples, required 6 hours of me meanwhile unable to do anything else with the PC
And as compared to 800 AA, 3 hours.
Or 80 AA samples 18 minutes…
Besides that remarkably no one would be able to see the difference between 799 and 800 AA samples
As the more AA samples one uses
The less difference there is in the probability of a final pixel color as compared to the previous AA sample of that pixel.

That’s the case, but then why isn’t the algorithm aware of this, and so be able to smooth out towards this certainty ?
Basically this is statistics math, pixels who share the same geometric shape and reflections, would over a certain degree (like inverse proportional to the AA sample rate) be equal in color as compared too their neighbor pixels, and as compared to the previous AA sample for that pixel region and that single previous pixel.

For the reaching towards a color, one doesn’t need to collect all statistic entries for each AA entry, as it not pure random but since reaching its more like a
loop while construction where RGB(final) = ( RGB(final) + 1/final * RGB (current sample) ) / current sample nr
Well obviously it would be a bit more code like language but you get the idea here, of stats and logarithmic math.

Since these days, most machines get 4GB or more memory, the extra use of statistics wouldn’t hurt.
And buying some more memory is way cheaper then buying a new CPU or GPU.

Also i think power efficiency and render farm time; might aslo get huge $$ savings here,for people like you and me.
No your render doesnt cost much, but there are every hour lots of renders globally
So one could improve a greener world here.
To me such thing would be really a top goal if I could and would create a render engine (but i’m not into it).
Sure we would give in, some tiny inverse-proportional-amount of realism, but cycles never was a physics render engine.

So i wonder has it ever been tried with cycles to tackle noise with statistics ??.
Is there active development on it, whats the status so farr.
Will it be in 2.71 or 2.72 or an add on? , or an alternative render engine CYCLES-v2 ?

Would be possible to see the render, to understand better which kind of light situation you have? Just by example, if you have an external background (not world hdr), turning off MIS in material panels is light night and day for noise. link Maybe isn’t useful for your case but without looking at the render is a bit difficult. (renderer optimization aside, i mean, about avoiding diffcult setups for cycles).

Well its a product proto-type and since its not in production yet, i cannt show it already in public here.
And its now doing its 6 hour run, dough i can tell about the render setup

I saw your link my noise is quite a bit less, but still persistent there
Its a hall environment with one wall with a lot of windows.
The outside environment is a mix of a city mirror ball and an emission, based on the gray of that picture and some math. Also a Sun has been added for better shading.
Emission isn’t set to a high value anywhere outside is out of my mind strength = 1 or < 3 ~
The outside light isnt strong enough to light the scene.
Equally spread over the ceiling (as by 2 arrays) i got mesh emissions from TL lamps, and these are not strong either.

None of these lights in the scene create spikes in objects shown in the hall
(one often gets spikes from strong camera facing lights).
None of the lights points directly into the camera either.

The noise i get is just like well 800 is almost fine but i can see ‘sand’ grain effects in flat faces,
And those grains wont smooth out easily 1000 2000…4000 well 1600 (i dont have the time to go for 3200, or 6400). Thats why i had these questions, as that didnt make sense to me either.

I will also go after this setting you mentioned, i set my allarmclock to do another one just for my deadline.

Dough i would still hope that it is being looked after those sample rates, when one compares the end results. One can estimate what it should be, and so can statistics.

Try more robust, general, not branched integrator (reset all integrator settings to default). For hard scene you cannot guess “right” weight on sampled dimensions.

Thanks for the advice
Dough my point here is the way the algorythm improves the samples
To me it seems there are math shortcuts possible who would require less samples, we would all benefit from it i believe.

( for the record, i prefer to do bordered small test runs to actually get reasonable branched results,
tuning it is much like a child game saying only cold/warm for a hidden item… like a human based genetic algorithm )

Not to be a stickler, but I think you mean though, not dough.

You could look into the metropolis/bidir patch that is in progress, It’s got some newer algorithms that really help with indoor scenes.
https://developer.blender.org/T38401

I recently did an interior scene… try a buildbot version of blender (http://builder.blender.org) with brached path tracing and play around with the ‘sample all direct lights’ and ‘sample all indirect lights’ options… everything will go much slower but you should need significantly less samples and significantly less time to make it noise free

6 hours have passed and the result is without noticeable noise

@marcoG_ITA
Ii had turned MIS of, which actually was wrong for HDR… now i do another just to verify time difference and end result.
>> i’m not sure if that is a recommended setting or an optimized option (the popup text leaves it in the middle)

@doublebishop and @SterlingRoth,
Well i guess you both talk about the same thing here ?.
Is there some download in www.graphicall.org, where it is included, or do the buildbots currently include it.
I’m never sure about whats inside buildbot and whats not in, graphicall.org provides some explaining text usually of whats inside. Although as far i understand these can also contain versions that will never be in final versions. To me its fine if something is experimental, but i prefer not to learn things in a manner that will change in the future, my head gets too full from all the ways i can do things in blender (well there are worse things in life, i just want to learn it in a good way, that’s my main concern here)

Sorry for my broken English,
I’m actually Dutch so English is not my native language, I try to do my best, so thanks for notifying me.

We are not talking about the same thing, what sterlingroth is talking about is a patch which is not stable at the moment… what i am talking about is something which is already in the main branch of blender

the buildbots currently contain what i am talking about.

Why aren’t you bumping up the number of diffuse/glossy samples instead of AA? AA samples are used for cleaning up edges and any motion blur/defocus blurs. After those are clean (usually in about 36 to 64 AA samples-non squared) you are supposed to bump up the individual sample counts to get rid of the remaining noise. 1600 AA samples is incredibly excessive and will be very slow. Or maybe I’m not reading your post right?

That being said, the new ‘sample all indirect lights’ setting is an absolute godsend for reducing noise on indirect lighting, giving you noise free renders in half the time in the cases where I’ve used it. Can’t wait for it to be in an official release.

@jdent02 it actually as far as i understand is just a combined calculation 10AA with 50 Difuse is like 5AA with 100 difuse, see the totals in that pannel.
When thinking of these totals, its also is just a matter of what you like to enter, 6 squared or 36.
I just i keep a balance ( like 10:5:2:1 or so, between all types of what can be rendered ) … which also means you got a point since i wasnt at first aiming gor 1600AA samples; and so these small values then have more impact, better would have been less AA
But it would only be better because some methods other then dif/glos would (maybe??) get to much attention, i question mark this because it because the way how cylces currently improves upon itself, and thats the main noise problem. (nearing to a pixel like a logarithmic function, without stats).

I’ve been reading the long talk about metropolis render for cycles ( https://developer.blender.org/T38401 )
(its not in buildbot yet) (and i dont know about graphics.org); but that seams to address it. I cannt wait to see it in cycles,
it seams already existing in lux ( https://www.youtube.com/watch?feature=player_embedded&v=P_QmdpnKTW4 )
From what i can tell with my zero experience … haha sorry, …but when its ready it will be well …awesome
I think from what i read, even better as lux as besides cycles also has the node system and OSL… super !
(well that might not be fair i’m not into lux deeply i have used a year ago, but used cycles less then a day ago (daily/weekly)

Well I simply have to wait for it, as i cant build it (win7 64bit - CPU octo renderer).
If someone can built and like to share, then please please please drop a link :))

jdent02 is right, the whole point of branched path tracing is to allocate samples only to those branches that contribute most to the noise while keeping the other branches and especially the number of AA samples low. With an AA sample count of 1600 you might as well use non-branched path tracing because the branching itself imposes a performance penalty that is offset only if used properly. There is rarely a reason to bump AA higher than 16 if you use branching.

To quickly find the best settings for branched path tracing, use the render border over a small noisy part of the scene so you won’t have to wait hours for each test render to finish. If you find that you have to bump up all the branches to get a good result, switch to non-branched because that will be faster.

I have the most problems with strong DOF and Motion Blur, where I have to bump AA samples to 64 or more, then I get into a scope where the non-branched integrator is faster. Generally DOF and Motion Blur are just hell for me to get really clean, worst of all in animation where they are mandatory. So it’s still back to the compositor for these effects, most of the time.

@eye208, > but then i didn’t count for 1600AA and i did use the border method, i always do.

But the main thing i addressed here is the way how rendering currently works in cycle.
But i guess people bypass the first part i wrote, all those pixels are nearing to a certain color value.
And sure add low passes the value is still very unsure
But the more samples one takes the more it is nearing to a color for that small area.
And that’s where statistics come in handy…
And to both @hoverkraft, that’s where the new render method is all about.
It will even spend less AA samples to parts that can do with less, by monitoring the noise amount (statistics).

For animation, it is suspected that these new methods if comparable to most recent lux versions
Then we would see a 10 fold or 5 fold smaller required amount of render time in cycles.
Well wouldn’t that be cool.

Razorblade, did you try the buildbot with sample all direct/ indirect light options?