Bucket time limit !

[Laserschwert]

I'd like this "split buckets after n seconds" function, although I hope this doesn't mean those new buckets have to start rendering all over again. It would be cool if those buckets could at least use what the stuck bucket has already calculated and continue from there.

[Sbrusse]

Split and restart is already great but continue from what the previous had already rendered would be even better

Hope this will get done soon, it's a great feature!

[werticus]

I'm rendering an animation at the moment that takes about 2 mins for most of the frame except for 2 buckets that take another 2 mins just for them. This is effectively doubling the render time.

I have 'optimised' it by having the render start on the side of the image with the offending buckets, so that it does not get stuck at the end of the render but rather at the start of the render, this reduced the render time by 50%

So there is a potentially a lot of speed to be gained by some smarter bucket splitting algorithms.

The best option out of all the idea's i've seen here would be that the remaining buckets split (as many times as there are cores or nodes) when there is no new buckets left.

[Sbrusse]

+1
Would definitely be a great addition

[algato]

Hello,
is there any progress for the manual bucket splitting - function ?

[slowgojoe]

Soooo... this was a year ago.. Has there been any progress on this feature? Thank you.

[Macker]

Glad this got dragged up, I had a couple of huge (18k) VR shots which were rendering out in about 2 hours that ended up taking 11.5 hours due to a stuck bucket! It meant I came in yesterday expecting 4 VR shots and only one had rendered out - I had to do the other 3 in very low quality.

[Neilg]

Dont suppose the bucket time limit was ever implemented?

Have a camera view where 4 buckets get stuck forever. it's one big scene with 5 cameras in - all the others render in 2-3 hours, this one angle ends up with a handful of stuck buckets and never completes even after 40 hours. There's no special piece of geometry they are getting stuck on - they're kind of randomly scattered around the image but always in the same place.

I'd prefer it just save out what it's done and let me photoshop over the missing buckets.

[^Lele^]

I'd prefer it just save out what it's done and let me photoshop over the missing buckets.

You could stop the stuck render, save the result, and then draw a region in the blank area to be rendered with progressive, which will provide for a good noise threshold everywhere else but in the most difficult pixels.
Not recommended for animations, but surely workable with some amount of (unfortunate) diligence for stills, i'd think.

[Neilg]

unfortunately I tried to render a 6k version last night and too many buckets get stuck for it to finish the image now. I was doing 2k high tests previously.
They're not in one area, they are scattered seemingly randomly over the entire architecture model. Which renders fine from other camera angles with nothing sticking...

I guess i could make the bucket size huge so there's more chance the sticking wont affect every bucket, but it might still halt the render at full res.
It's a 10hr render so monitoring it and stopping/starting to draw regions isnt ideal.

edit: i'm using triplaner mapping with no uv's on the object. that's the only thing I think could be causing it, everything else is by the numbers and clean. Any known issues with that?

[^Lele^]

And they aren't fireflies (which would stand to reason it being view-dependent)?
What happens if you render a region of those parts with progressive, does it clue you in better?

[Neilg]

No fireflies on any images.
t'll be a little while before i can do a test with progressive - our render workflow is to submit jobs to deadline from otherwise empty max files with all the xrefs turned on and a few test scenes with only the arch / landscape on, then when we need to see something that changed in an xref we re-queue the job. Takes half an hour to get the file open and xrefs switched on otherwise.

Edit:
Did a test at 1500 high with much lower settings so I could get a copy of it -
only ended up with 2 stuck buckets. At higher resolution every bucket got stuck somewhere on this facade - not in this position, at random points all over it. If I re-render with the same resolution, the stuck buckets are in the same place. If the resolution changes, so does the sticking position of each bucket.
This same facade is visible in 2 other images.
There are 3 objects at play under this bucket - glass (modeled from scratch, edit poly with shell), the mullions (shiny metal with edgetex chamfer) and the brick (triplanar, no displacement)

[Neilg]

Solved it - switching of reflective GI caustics in the GI settings did the trick! And thankfully something I can do through deadline so i dont need to re-submit the jobs.

[^Lele^]

Ah! so it did have to do with high intensity, low probability, rays.
I'd say the shiny metal with the edgetex chamfering could have been the culprit, as it has the marks of what generally cause fireflies (high, sharp shininess and sub-pixel detail.).

[Neilg]

Yeah - it's a little weird it was happening on the facade not in direct sunlight though, thats what threw me off. Plus it had some buckets stuck for 17 hours, I don't think they were ever going to finish.


Better than cancelling buckets that take too long, how difficult would it be to implement a dynamic noise threshold in cases like these? I guess on the user side you'd turn it on and set a time limit of 10min or so, then if a bucket takes longer than that, vray increases the noise threshold until it can finish the bucket. Is it even built in a way that something like that could be done?

I imagine it's probably got some nightmarish knock on effects i'm not considering. I guess it would also have to spit out an element which tells users which buckets were the culprit too.