Can stuck bucket syndrome finally be fixed, please?

[glorybound]

I don't think I have used bucket rendering in two years. Why is it still a thing?

[^Lele^]

I don't think I have used bucket rendering in two years. Why is it still a thing?

High resolution with many REs, distributed rendering, memory savings with bufferless rendering, better image filtering, checkerboard rendering over a farm, and so on.
It's an option with value, certainly not a leftover.

In the specific case of the stuck bucket described above, even with progressive one would see V-Ray sit obstinately around the group of pixels, at each pass creating more fireflies that would be cleaned many passes later, while new ones were birthed.
Unless one left it for a long time, it'd definitely look like the image wasn't converging at all in those areas.

[matanov]

Guys, we do have an experimental build with a solution and now is the right time to throw every scene you have at us

[kosso_olli]

I think we sent some scenes already. Do you need them again?

Regards

Oliver

[matanov]

I think we sent some scenes already. Do you need them again?

Regards

Oliver

I think we have 3 of yours. If you have new ones or somebody else has something suitable for testing - please

[kosso_olli]

Okay, let me see if I can find some additional ones.

[Joelaff]

Just put a giant high-poly model with refraction glossiness and reflection glossiness in a small area of the frame and add a VRaySun. There's your test scene. It will take a VERY long time to do one tiny block.

Are you implementing something special? Trying to figure out why some simple test scene would not work. If you are somehow able to have the most complex block render first (via data from the light cache) so that they are done before the other blocks that might be helpful. Though you can still get stuck on them.

[^Lele^]

Are you implementing something special?

We're in the early internal testing phase of a novel approach, yes.

Trying to figure out why some simple test scene would not work.

We try and model issues, but the users, pressed by production needs, will find left-field ways to go about things.

If you are somehow able to have the most complex block render first (via data from the light cache) so that they are done before the other blocks that might be helpful.

The rendering process is how long it takes to answer a given question, posed by a scene setup.
If we knew in advance what was the hard bit, we'd know the answer to the question.
The LC, f.e., is heavily under-sampling a scene, and has as yet no idea of the noise threshold to be achieved.
Given rendering is a statistical affair, the LC would miss some of the troublesome areas by virtue of poor sampling of the problem domain (in other words, that glinting sixteenth of a pixel to be lowered to 0.005 noise threshold would not be picked up.).

[Joelaff]

No doubt the light cache is far from a perfect method, but it’s an easy way to get at least some idea of what is going on in the scene.

No doubt it is a complicated problem. Parallel processing always is.

Eager to see what you folks come up with.

[^Lele^]

Eager to see what you folks come up with.

For now, i can share this.
Notice the settings are kept noisy so you can watch the divisions happen in realtime within a minute or two.
Also, the bucket size is chosen big on purpose because it's generally quicker than with smaller buckets (less border to render twice) and because it's easier to see the splitting.
The algo scales just as well with longer renders, with higher sampling and lower noise threshold.
It has some internal name, but i can think of it as either the "mutual aid bucket sampler", or the "game of life bucket sampler" (where samples are food.).
I find it mesmerizing, my OCD is very happy with Rado's work, and i keep abusing the many-core machine to see what a given frame will subdivide to.

The algorithm is elegantly simple and effective: the crux of it is that the CPUs will stay as busy as possible for as long as possible, adaptively, so regardless of screen content.
This is inherently change-resilient (animation, changes to lighting, geometry, textures, to the presence or not in any amount of DoF or Moblur, and so on...), it wastes as few CPU cycles as possible (doing clever stuff to not waste any work already done), and should nearly always result in a quicker time to a given noise threshold.
This is about the optimal that can be achieved without any loss of image qualities (gloss on shaders, light intensities, and so on.).

Work is ongoing and it's not yet ready for primetime.

[joconnell]

That's really cool looking! I just finished up on hawkeye and we had thousands of lights and lots of those hot little glints, this type of thing would likely make a big difference! I'd love a few more brutal cut off controls for lights that aren't realistic but would try to cut off fireflies at source too, while the correct version of things gets resolved in more elegant ways in the background!

[^Lele^]

I'd love a few more brutal cut off controls for lights that aren't realistic but would try to cut off fireflies at source too, while the correct version of things gets resolved in more elegant ways in the background!

Parallel work is ongoing there too.

[olly]

For now, i can share this.

This looks awesome

[Joelaff]

Looks great! Ready to download

[fixeighted]

...and this year's Quality of Life Award goes to....