Bucket

[glorybound]

Can someone explain the bucket size? Is larger buckets better then smaller bucket? I have always left my bucket size at 64 and I have played with 128, but I don't see any difference. Can anyone shed some light on the for me?

Thanks in advance

[vlado]

Depending on your AA filter, V-Ray will trace an additional frame of pixels outside of each bucket; if you use a large filter and small bucket size, the additional pixels may be quite a big fraction compared to the bucket size itself - which will slow down the rendering.

On the other hand, larger buckets require more memory, especially if you use the Adaptive subdivision sampler with a lot of render elements.

Normally bucket size of 64 or 48 is a good balance; I like to set it to 32 for faster feedback when doing test renders.

Best regards,
Vlado

[pailhead]

I always wondered what would a diagram of this look like. Since we have two boundaries, one being a bucket of 1x1 pixels, and the other being a single bucket the size of an entire image. Theoretically, what would happen in these extreme cases?

[zeronove]

to Vlado

are these values good for high res size as well?

I mean, when I need to render a final image that is for example 3000x2000 pix, the bucket size of 64 seems to me too small!

During last period I'm doing some test with the other option for the bucket size (region count), it is useful when you make several changes between img sixe (from draft to final and so on); I thought that using this option the bucket size influence on the rendertime remains the same but probably I'm missing something

[vlado]

Well, you can calculate that: if the bucket size is 64 x 64, and you are using the area filter (size 1.5) with the adaptive DMC sampler, V-Ray will calculate each bucket as 66 x 66 pixels; now 66*66/(64*64)=1.06347656, which means that on average, 6.3% more pixels are calculated. If the bucket size is 32x32, this gives 34*34/(32*32)=1.12890625 or 12.8% more calculations for the AA.

For the Catmull-Rom filter (size 4), this becomes 68*68/(64*64)=1.12890625 or 12.8% more pixels than there are in the image. If the bucket size is 32x32, this becomes 36*36/(32*32)=1.265625 or 26.5% more calculations.

And so on...

Best regards,
Vlado

[pailhead]

So what prevents us from rendering a 800x600 image with a single 800x600 bucket? RAM?

[vlado]

Each bucket is assigned to one render thread, so if you had just one single bucket for the whole image it would a) render on one core only and b) take an awful lot of RAM.

Best regards,
Vlado

[zeronove]

mmmh, ...from what Vlado writes I understand that larger bucket size means less waste of additional pixel so it's better to push my bucket size to the maximum that my available memory can manage efficiently, is that correct?

It make sense to manage the bucket size as a sort of percentage of the final resolution? I mean: 64x64 is good for 640x480; 128x128 is good for 1280x960 and so on (or something similar)?

[pailhead]

But, the time you may save rendering less pixels... may be replaced by more time a larger bucket requires to communicate with ram?

I'd really like to see this clarified a bit more...

[ene.xis]

its cristal clear me thinks!
it s all down to memory speed and other hardware limitations...and that may vary a little...that said i think one must trial error a little

[victor.nsy]

I love feedback and often test the render even at the very last stages of
rendering cos sometimes I get unexpected splotches ... so my bucket is often
set no bigger than 64 x 64.