Can stuck bucket syndrome finally be fixed, please?

[seandunderdale]

Itd be awesome to be able to use select sets to define areas of the render for dynamic splitting of cores, so the splitting can happen earlier on. You would basically be adding headlight and tail light glass to the set, load that in as the bucket splitting selection, and when the Vray gets started on those areas, it breaks down from size 64 f.e to 8. I find the dynamic splitting is almost useless at the end of the render....nice to have, but doesnt have the effect it could, or should. This method would also work for animations since the select set is calculated each frame.

[glorybound]

I haven't seen a bucket in over a year. Why are you not using progressive? Sorry if that has been asked already; I haven't read the entire thread yet.

[seandunderdale]

I find progressive just doesn't resolve super whites as well as bucket mode. Especially for animations of say, a car interior, lots of pingy light catching edges and shaders, progressive results in too much noise, and its made worse by denoiser, not better, especially when you want to use some heavy depth of field in post.

[kosso_olli]

Why are you not using progressive?

Because Progressive is slower on the big resolutions we have to render, needs an excessive amount of Ram and does not scale well over DR.

[Joelaff]

Because Progressive is slower on the big resolutions we have to render, needs an excessive amount of Ram and does not scale well over DR.

This, plus Phoenix is usually faster with bucket due to the Phoenix light cache.

[waaazoo]

yeah, these hanging buckets are really a nightmare. I'm testing again a scene and whatever I try with bucket size, sequence type, I can't get around with hanging buckets. (here, mostly in the foam of a phoenix scene)

[vlado]

One of our developers is looking into multithreading the last buckets; hopefully this will help to improve the situation.

Best regards,
Vlado

[kosso_olli]

One of our developers is looking into multithreading the last buckets; hopefully this will help to improve the situation.

Best regards,
Vlado

Hey Vlado,
nice to see you around here again!
This is great news, I am really looking forward to this

[Paul Oblomov]

I wonder, can someone post numbers of rays, vray has to deal with? Just curious. Some statistics would be nice. I had years and years ago dof through motionblur with very bright pixels stuck for days That was painful as hell...

[q976431]

This issue has been discussed since 2013
And it will be mentioned again at regular intervals
There can be no real solution yet.
The method used by Vray is to automatically split the last block when rendering.
But for a bucket that's stuck
There is no real way to deal with it
Many artists need to wait more rendering time for this
So I think it may be really difficult to solve it in code technology...

[^Lele^]

We hope the multi-threading of those stuck buckets will help (particularly on many-cored machines).

What we've seen thus far, with scenes provided to us by various users and at the net of any bugs we found, was that those pixels which stuck the buckets were simply a product of users' setup.
In other words, users had asked V-Ray to sample a lot (f.e. it's not uncommon to see 256, 512 and so on max AA subdivs, and 0.0001 noise thresholds.), which in conjunction with hyper-bright (in the millions float, or even NaNs) lights' and IBL's values, ensured V-Ray had to go all the way, casting enormous amounts of rays where, f.e., the highlight was hitting the geo just right (while not completing sampling would result in all sorts of visual issues.).
In this scenario, being able to multithread those few pixels under the stuck buckets will help quite a bit.

All that's been said so far on scene setup practices remains valid, however: a scene with stuck buckets that would go on for three hours could be cured by slightly massaging a shader and light or IBL, and render, wholly, in a matter of a few minutes, with very minor, and very manageable, visual differences.
This happened time and time again, but coders prefer not to reply to users with setup guidelines, and rather find ways to do better in code.
It's a commendable attitude, and one could construe it as also being necessary, but it's infinitely more expensive (for resources and time: years of research, and a long time implementing it.) than just spending more time with a scene, ameliorating issues which are self-evident in all the provided forensic tools (log, samplerate/rendertime RE, and so on.).
As such, regardless of advancements on the coding side, tight control on one's scene setup will continue to pay enormous dividends (in other words, LnR TDs will still be able to earn their keep making friends along the way.).

[Paul Oblomov]

Interesting, that there's Max ray intensity - so generally speaking - can it help ? Or why it doesn't then.

[^Lele^]

MRI is only for GI rays.

Vlado experimented with a way to cure hyper-brights a while back, but of course it's at the expense of dynamic range, which isn't always a wanted thing, nor is easy to implement as a simple option to toggle.

The same goes for the old approaches to cure such scenarios (clamping, sub-pixel mapping, etc): they wouldn't work nicely with a number of other techs, and it's so far not been trivial to make them do so.

Alas, research is ongoing.

[seandunderdale]

MRI is only for GI rays.
.

Ive had that value affect whether I got lens fx from headlights...is that still GI rays? If my glow objects were behind a blurry shader, it killed the lens fx. If I lowered the MRI to near zero, I got lens fx back...at the expense of a shite tonne of noise, mind you.

Id still be happy with a timeout on any given bucket like on progressive. Its one reason why I think progressive is so powerful is you can set your time limit, run the numbers by the time you have to render and decide on what you can "spend" time wise. If a bucket hits 10mins, it returns whatever it managed to do. Im not sure thats even possible, but as a workflow Id find that useful.

[^Lele^]

That was a silly oversight on my part: it applies to all secondary rays, so also reflection and refraction (with bounces > 1).
Sadly the issues with said hyper-brights, as we found so far, are often with bounce 0 (i.e. direct visibility/first reflection), as the energies are generally distributed/diminish when multi-bouncing.

A timeout for buckets wouldn't work, the sampling difference with the neighboring ones may well be visible (as it is right now stopping sampling of said areas early: one's left with unresolved fireflies all over the place).