Buckets starts with buckets that took the longest time

[Undersky]

Long time lurker, first time poster.

I've searched if there were a similar idea posted, but couldn't find anything. The one thing I did find were some idea about dividing the buckets into smaller buckets when needed.

I have just a single wish: Buckets remembering which bucket took the longest to render in the previous frame, and start with those buckets in the next fram (ok, that was actually two wishes...)

This would be either for a sequence or just when test rendering. Usually I just track the mouse pointer (lovely feature, btw) but for sequence rendering it would be great to have this feature.

Right now we have machines with 8 cores at work and there is nothing more annoying than when 7 cores have finished and one core is left behind, chewing away on that last little bit of the render. He looks so lonely.

So, for the sake of the social buckets, don't leave them out in the cold. Let them all work together at the hard parts first.

[stilgarna]

Right now we have machines with 8 cores at work and there is nothing more annoying than when 7 cores have finished and one core is left behind, chewing away on that last little bit of the render. He looks so lonely.

You can lower the bucket size to avoid it. from 64 to 48 or 32...

Best regards.

[Undersky]

Yeah, I know. I already testrender with a bucket size of 16. The problem is that we're render rather large images sometimes and the smaller bucket size, the longer it takes to render (since every bucket takes some time to initize)

[stilgarna]

Yeah, I know. I already testrender with a bucket size of 16. The problem is that we're render rather large images sometimes and the smaller bucket size, the longer it takes to render (since every bucket takes some time to initize)

I just make some test and you're right... It render slower...

[Fekta.studio]

I can confirm that too, after I read this tread, I make a little test to see is that true, and here are the results:

DR bucket size set to 16: render time : 5.42 min., same render, this time bucket size set to 64: render rime: 4.00 min. WOW. a 1.42 min. fater.. I use a lot bucket size 16, and it seems that I must not, like everybody else

[Codi]

Having this as an option maybe would help in some situations, but is all about the specific render you are doing.

There are situations where a small bucket size is actually faster than larger ones, the best size is all about the optimum balance for the specific image you are doing.

If I remember correctly Vlado said that the nice thing about the way VRay picks buckets by default (Triangulation) is that it can reuse information of adjacent buckets to speed up the rendering, so if you use a system where buckets are scattered all over the image this will not be possible and maybe the render will end up being slower.

Just my 2 cents.

[^Lele^]

I can confirm that too, after I read this tread, I make a little test to see is that true, and here are the results:

DR bucket size set to 16: render time : 5.42 min., same render, this time bucket size set to 64: render rime: 4.00 min. WOW. a 1.42 min. fater.. I use a lot bucket size 16, and it seems that I must not, like everybody else

That assumes an image which is fairly consistent.
I can assure you that lowering bucket size in images with problematic areas and lots of cores involved (32, 64 and so on), which tend to remain sitting there for longer, greatly displaces the loss due to bucket init and bucket border AA.

[Morbid Angel]

That assumes an image which is fairly consistent.
I can assure you that lowering bucket size in images with problematic areas and lots of cores involved (32, 64 and so on), which tend to remain sitting there for longer, greatly displaces the loss due to bucket init and bucket border AA.

what he is saying is that you have to keep inmind that bucket borders have to be aliased twice more to ensure smooth transition between buckets. So by making buckets smaller you are actually aliasing much more then you have to.
This is a problem altogether. I would wish, and though none of this is possible, is that the entire image would resolve at once using all cpus as one.

About storing the bucket times from previous frame, I dont think its realistic and its not practical. What I have been suggesting for years is something called a priority map. A black and white image which would dictete where the next bucket would go. Then a user can manually make a priority map sequence to direct buckets.
I think this is much more practical.

[^Lele^]

Aye, i mentioned bucket borders' AA.
Still, on big image sizes and big numbers of cores, having a smaller (not 16, but even 32 px is very good a trade-off) bucket does make renders faster, especially when each bucket takes quite a while to render.
Of course, if you test on a simple-ish scene, smaller bucket sizes mean more AAsed pixels, hence more time.

[sv]

it's been mentioned before but adaptive buckets would be cool if the last remaining buckets could be split down / halved / quartered / etc when others finish so there aren't idol cores...

although i can see the issue of sampling bordering pixels means this isn't as straight forward as it seems.

[werticus]

i always have a think about the scene and try to choose a bucket size and render pattern that will not be too wasteful and render the hard stuff first.

but yes automatic would be better.

[Undersky]

About storing the bucket times from previous frame, I dont think its realistic and its not practical.

Why wouldn't it? I mean, "all" Vray would have to do is to save out a list of every bucket and how long it took to render that image. Then just start with the bucket that took the longest time of those. Right now I usually track the mouse in those long-to-render areas.

Of course there are times when smaller cores are better... We render images all from 128x128 to 3k x 3k right now, and if I have bucket sizes of 64, then there is only room on the image for 4 buckets =P Change that to 32 or 16 and it's about half that time.

[simonreeves]

What I have been suggesting for years is something called a priority map.

I thought I had seen this before too, and it seems its in Brazil (as I'm using it on the job I'm on at the moment inhouse).

The small buckets thing is a tricky one, I find being able to render around your cursor in small buckets really useful compared with render region etc. If only it had it in the viewport like XSI's (though its still better than selected buckets before hand like in brazil [old version at least]).

[Undersky]

Hey reevsy, you old fart!
Yeah, I agree, the mouse tracking is a wonderful feature. You can't do this in Brazil, however, in Brazil 2.0 you can click in the image and the next bucket will render that area. Not as intuitive as Vray's, but it's better than nothing.