A quick note on bucket size and shapeīased on our tests, it’s better to set your bucket size to numbers that are powers of 2 (512 = 2x2x2x2x2x2x2x2x2) or 3 times the powers of 2 (48 = 3x2x2x2x2). If you are not sure, better to stick to the smaller default of 48 pixels. Pro tip: to avoid issues when rendering high-resolution still images on cloud farms, make sure first that your image is going to be rendered on a single node before you try a bigger bucket size (256 or 512 pixels). With this said however, later we will see that smaller bucket sizes can play a role in solving problematic hanging buckets (but again, never so small as 1-2 pixels per bucket). Simply put, we never recommend setting your bucket size to 1 or 2 pixels. When you choose a rendering pattern that leads to the buckets skipping around the image, this again worsens the delay created by having a small bucket size.If you don’t have enough RAM to store the whole image as it renders, the delay that smaller bucket sizes create is worsened, leading to longer render times.If the bucket size is small, it means each bucket has to do this many more times compared to a bigger bucket size, and that time adds up.

Buckets load and unload data before they render their part of the image, which takes time.Why is this so? There a few reasons that explain this general principle: And based on the tests we’ve run, the bigger the bucket size (meaning more pixels for each bucket), the faster the render time. Buckets affect rendering timeīuckets are basically a group of pixels. If this isn’t all that clear to you, you can learn more about the relationship between rendering and CPU cores from our article that explains what is a render farm. If you are using a render farm like GarageFarm.NET for rendering, you get access to more processors and therefore more buckets that are simultaneously rendering an image resulting in faster render times.

Vray final render settings rhino