Proposal: Bucket order "bottom to top" is one of the more important bucket orders, but is only available after switching to advanced mode.

[JD3D_CGI]

The purpose of bucket orders seems to have shifted from memory efficiency (although that is still an issue) to avoiding stuck buckets.

I find that rendering from bottom to top works best as most grass and cars and detailed stuff is on the bottom of the scene. Most of the heavy processing is done down here and so therefore getting that out of the way first really makes sense.

Sadly, the only way we find it is to choose "top to bottom" - then go to advanced, then "reverse bucket order".

I propose that Chaos changes the default options.

Add "bottom to top" as a default option. Remove "chequered" - it's pointless now we have progressive rendering.

[hermit.crab]

Thanks for the suggestion, however, we are looking to solve the last bucket issue by other means.

[JD3D_CGI]

Yeah, with light cache.... but that wont work with BF + BF for example, and this must take literally 2 minutes to implement

[GregCooper]

Are you able to provide any details as to the other means you’re looking into? I’ve often wondered if there was a way of quickly analysing the frame at the beginning of a render (perhaps something in the light cache) to determine the areas that will take the longest to render and then starting with those buckets or dedicating more resources to resolving those areas first

[hermit.crab]

Yes, with multithreading for the last bucket.

[JD3D_CGI]

I mean, multithreading is great an all - but rendering from the bottom down is a solution that will work now - it should be a accessible without goign into advanced mode and I bet it works 80% of the time.

[Micha]

hermit.crab A side question - at V-Ray for Rhino the GPU buckets are so large and often I get stuck buckets. Is the size limit to this big size for VfR only or is it a general limit?

[hermit.crab]

Micha The GPU bucket size is internally optimized and cannot be controlled. It is a general thing, it is not V-Ray for Rhino exclusive.

[Micha]

hermit.crab Thank you, good to know. For me the large bucket size cost extra render time. Most if I rerender a little region of a current rendering or if I render not so big images like a 1280x720 animation. I have a lot of buckets of 3 GPU running over the screen, but they are so large that a lot of time is lost at the end. I loved the dynamic bucket size of the CPU mode. At the moment I avoid to use the bucket mode for small images or animations. Is this the recommended solution?

[Joelaff]

Yeah, bucket size must be use controllable. Only the user and their scene know what is “optimized,” and it is rarely the default settings.

The Fixed GPU bucket sizes make bucket rendering in GPU completely useless for us, as discussed numerous other places.

Users need more control, not less. You can hide all you want in the Expert mode, that is fine, but let’s get user adjustable block size for GPU.

Looking forward to better last block management, but we will likely still need user settings as “auto” modes rarely work in all cases in anything. Like “auto” exposure in a camera, or Teslas driving into parked emergency vehicles. The user needs final say in everything.