Bucket and progressive rendering
Progressive rendering
progressive rendering
The idea of progressive rendering is to render the whole image at once and refining the quality progressively. We start with a very coarse image, sometimes even in lower resolution, and add more samples bit by bit. Each additional step of refinement is called a pass. In every pass, we add a certain amount of samples to each pixel until the final quality is reached.
The purpose of progressive rendering is to immediately get an idea of how the final render will look like. You can make creative decisions based on a very low-quality image without having to wait for a final quality rendering to finish. However, it also comes with a few downsides you should be aware of.
The pros:
- quick feedback of how the rendering will look like
- ideal for interactive rendering where the rendering updates while you change shaders or objects in the scene
- you can stop rendering at any time if you think the quality is sufficient
The cons:
- you might have to wait for a long time to see one area of the image reach final quality (a mouse tracking feature can be helpful in this case)
- less memory efficient since the renderer has to keep all the scene data in memory all the time to be able to render the whole area at once. This can be even worse with GPU renderers where generally less VRAM is available.
- depending on the renderer, number of samples per pass and other technical details, progressive rendering can be slower than bucket rendering
Bucket rendering
bucket rendering
In this case, the image is rendered in small areas, called buckets. You will usually see the final quality in this bucket when it finished rendering but you won't see much of the overall image at first. The number of buckets is determined by the number of CPU cores your machine has - or, in case the of GPU renderers, the number of GPUs you have available.
It is important to note that the size of the buckets can be crucial for the render times. Each bucket will need to sample neighboring pixels outside the bucket to prevent discontinuities between buckets, so the smaller the buckets are, the more overhead
you generate because of the additional calculations. However, buckets that are too big can also drastically slow down the rendering process (aka the headlights problem). You may run into situations where one bucket seems to be stuck in one particular area of your image while all other buckets already finished rendering. So there is just one bucket left that is, for example, stuck at rendering a headlight of a car which is usually very processing-intensive. By decreasing the bucket size you will make it less likely that one big bucket will slow down the rendering too much. This generally applies more to CPU than GPU renderers since you rarely have many buckets with GPU rendering. Plus, GPU renderers usually prefer bigger buckets over smaller ones.
The pros:
- final quality in each finished bucket
- more memory efficient since you only need to load objects or texture tiles that are currently being rendered - meaning you can render bigger scenes with the same amount of memory
The cons:
- you will have to wait for all the buckets to finish before you get any usable image
- no interactive feedback, you won't see the general look of your scene until the rendering finished completely
- a single stuck bucket can slow down a rendering noticeably