Understanding DMC Sampler

[vlado]

As you can see, bucket render is by far, faaaar, waaaay better than progressive. Even with twice more rendertime... It might be because I don't have crazy settings as you do but I use the default settings everywhere.

Try a recent 3.25 nightly build and see what you get...

Best regards,
Vlado

[m_hinks]

it's 1.0/256, or basically telling VRay to sample more within the display device bounds.
With enough sampling, that's the highest noise threshold which will return a visibly clean image (provided, ofc, the render is used as is, without being stopped up, or brightened in any way).

What does the 256 represent? white to black range? If so why would you need to use another other than that one value. Just trying to get my head round things, I like when you can use maths to work out settings!

[^Lele^]

In VFX i found useful to have an idea of how the shot would be treated in post, as i got bit a few times by the comper's need to gain/expose up the render.
As such, i equated bits per pixel to f-Stops, and if my comper needed to double the brightness of the render i was providing him with, i'd just render it with a noise threshold of 1/2^9, or 1/512.
This, given enough sampling, ofc, guaranteed a noise-free render even when the exposure was raised, as long as it was within the bounds set by the noise threshold.
For a render that you'll watch on your monitor, without particular brightening applied afterwards, it stands to reason that you will not be able to pick up noise if its value is below what the monitor can express.
So, 256 values of brightness.
Telling VRay to look for noise, and clean it up until it's below the 1/256 threshold will insure your images will be visually noise free.

[m_hinks]

Very useful info. So a noise threshold of 1/256 for images in archviz is likely to be a good rule of thumb, where the post is minimal in terms of exposure changes. So you can then just in crease the min and max as needed to get your clear AA. I like this thinking!

[3LP]

Right.

Thanks Lele for clearing out some confusion about noise, make sense I should put the noise at 0.01 to match the bucket rendering, otherwise it just keeps refining!
I guess it might be interesting to add one in progressive as default. Those who'd like to render "indefinitely" could always choose to put the noise to 0 (in stead of doing it the other way around).
It would prevent ppl like me from being in the wrong place for over a year now. I might be the only one, lets hope... I guess it's just a point of view

That being said, you referred to the nightly and Vlado mentioned to try with that one as well, so I did, last nightly (from today actually) :

Bucket :


Progressive :


~Same time, same noise threshold, but progressive is still noisier, although it's way better than my previous test.
At the end of the render, when hitting close to 1000 passes, the cpu drops from 100% to about 10%.

Useful for preview while working (as it's progressive) but for a offline render or a animation on the farm, I would still prefer bucket as it seems to be faster for the noise.

What about the bundle size? You said that we need to play around with the bundle size depending on the size of the render. Does it also depends on the CPU/cores count?
We often use the farm to render stills, that's about 400-600 cores (50 nodes). It would be awful to have to adjust some settings depending on what you will render with.
With buckets, it's straight forward, more core -> faster render -> 100% usage -> all the time.

This is with a scene that has not been uptimised, so I guess that one that would take time to try to squeeze even more out of it would make the bucket even more interesting (as the progressive doesn't care about subdivs)
Now for those who don't know what they are doing and you have a scene that is actually rendering slower than the default settings, well I guess progressive would help a lot as it takes all that knowledge/bad manipulation out of the way.

Hopefully as Vlado mentioned, achieving 1:1 between bucket/progressive like it's planned in SP3 will be a massive game changer for me as I will finally be able to have all the production team not caring about settings, and thus winning a LOT of production time.

Stan

[3LP]

Hey just though I would give this a go with your 1/254 noise threshold, basically it having the noise at 0.004

Bucket :

Progressive :


After 800 passes, the CPU drops down at 2-7%, and it stops achieving 1000 passes, which is faster than the bucket render, but it still has more noise.
Not sure how I need to do to match noise then if it's supposed to be the same, but it's not visually.

Stan

[Vizioen]

Is it still a region render (red line around render)?

[3LP]

Yes it is, and at 200% as well.
Stan

[Vizioen]

Did you decrease the ray bundle size as Lele said?

[3LP]

yes, went down to 8 and even 4, had the same results, didn't tried lower though, but CPU was used to maximum till 90% of the render so I guess it was low enough.

Does anyone have a comparison of a "real production scene" between bucket and progressive that shows that progressive is at least as good as bucket?

Stan

[vlado]

Does anyone have a comparison of a "real production scene" between bucket and progressive that shows that progressive is at least as good as bucket?

If the evermotion scenes count as "production scenes", then yes. Do you want to see the renders?

Best regards,
Vlado

[3LP]

Oh yes sure I'd love to

Thanks!

[3LP]

I know it's off topic, but here is a quick comparison between a render done in RT GPU on 3 GTX 970 (SP1) and on my 4930K CPU (SP2).

Both 22 min of Progressive render :

CPU :
https://dl.dropboxusercontent.com/u/...8_0000_CPU.jpg

GPU :
https://dl.dropboxusercontent.com/u/...8_0000_GPU.jpg

Stan

[super gnu]

double post, no delete button.

[super gnu]

nice comparison. ive just ordered a titan x and associated watercooling block.. my first proper investment in rt gpu.

note: if you did another render with adaptive at the same noise threshold (or all 3 with a fixed noise threshold and no time limit) you might squeeze those results back on-topic.