Well I am waiting for my latest render to get finshed I have had this question on my mind for quit awhile, and as normally the poser manual is vague to exactly what to do with this setting.

My dumb question for the day what is bucket size exactly? What does it do to affect your renders? What is the purpose of raising it higher or lower then the defualt 64?

Okay more then one dumb question but I am sure there is someone else wondering the same thing and maybe it will help them too.

Not a very technical definition, but think of it as a block of pixels being processed.

64 would be a 64x64 chunk of the image being processed at once. I usually set mine to 16 and that way Poser is a bit more responsive during a render. Say for instance if you decide to hit cancel during a render, chances are Poser wont cancel until its done with the current bucket. From my messing around with Poser I've never noticed much of a difference as far as render times go regarding bucket size.

One thing that does make a big difference as far as responsiveness is to set Posers priority to below normal.

Handle every stressful situation like a dog.

If you can't eat it or play with it,

just pee on it and walk away. :-)

....................................................

I wouldnt have to manage my anger

if people would manage their stupidity......

 

bucket size and memory required are related because the entire bucket is processed.  large buckets may render slightly faster , small buckets use less memory

I know it has to do with ram and what not, but so basically its how many pixels it renders at a time so If I set it to say 3000 pixel (extreme I know) it would render 3000 pixels at a time ?

okay crossed post with mark. so if I do set it larger then 64 it will render faster but use more memory, but lower bucket size uses less memory and renders slower? that seams weird

***     Bucket*** is the size of the area (square pixel dimensions, generally an integer power of 2, i.e., 4,8,16,32,64) which is calculated as one task.  This is why you see little squares slowly composite an image during a render.

     Each processing thread is assigned a bucket;  when it finishes, it is assigned another bucket.  If you have a multi-core processor, each core will run a thread;  if the processor is HyperThreaded, it can run a second thread for each core - so a HyperThreaded quad core like the core i7 will render in eight threads, which means working on eight buckets at a time.  That is why a core i7 will render much faster than a single core processor, even if both are running at the same clock speed.

     A larger bucket size is more time efficient if you have the RAM to support it.  How much memory is needed depends on render size, scene complexity, materials, and render quality settings.  If you are running short on RAM or if you want to see visible progress (finished buckets appearing on screen) more often, you can lower the bucket size.  If you see Poser decrease the bucket size during a render, you're running low on memory.  If Poser decreases the bucket once, then decreases it again, you probably won't get a finished render.

The system resource load goes up geometrically as you increase bucket size;  a bucket size "4" juggles 16 pixels, but a bucket set to "8" has 64 pixels.

 

edit:  Onnetz and Mark beat me to the post!  ^^

Poser 12, in feet.  

OSes:  Win7Prox64, Win7Ultx64

Silo Pro 2.5.6 64bit, Vue Infinite 2014.7, Genetica 4.0 Studio, UV Mapper Pro, UV Layout Pro, PhotoImpact X3, GIF Animator 5

You get into what happens in memory, and what writes to disk occur. 

Try it with a simple image and set bucket size to 128 and watch the render window.

Then set it to 4 and render.

See what happens .

You normally see the render pause when it hits hair , or some area with reflections.

Firefly looks outside of the current bucket to check for stuff which would influence the current bucket;  an example would be displacement materials.  So,  instead of just looking at the 8x8 bucket, Firefly actually checks a border of a few pixels around the bucket for these effects.  That means some duplication of effort.

That border is less significant if you're using a 32x32 pixel bucket.  Less duplication of effort -and less frequent fetching-  allows the faster render - if you have the RAM to support it.

Poser 12, in feet.  

OSes:  Win7Prox64, Win7Ultx64

Silo Pro 2.5.6 64bit, Vue Infinite 2014.7, Genetica 4.0 Studio, UV Mapper Pro, UV Layout Pro, PhotoImpact X3, GIF Animator 5

Hmmmm interesting now I know a bit more thanks. Right now I have a 64 bit system with 4 gb of ram I3 processor, but im never sure if I actually see poser using dual processing sometimes it does and I can visibly see it when i render and see two lines rendering from top and bottom.

 

Anyways most of my renders I just render figure dressed sometimes not, most the time no hair cause I do notice it slows down when it renders hair. (again now i know why). but most the time I do simple scene and post work the rest in photoshop so my next render I am going to set my bucket size up and see how far I can push my poser 7 on my system :)

(Reposting my last post on this topic.)

Increasing bucket size sometimes makes render time go up, and sometimes go down. A graph of the render time versus bucket size would be U shaped.

At very low bucket size, you need a lot of buckets, and this makes the render take longer. This is because the cost of setting up and tearing down a bucket costs some time since it has to examine all of the polygons to see which ones belong in the bucket. If you have a small bucket size, then there are a lot of buckets to build and destroy and you end up examining the entire scene an enormous number of times.

At very large bucket size, you don't need so many buckets, but the cost of rendering one goes up. A bucket is like a miniature scene. If the bucket is bigger, the miniature scene is bigger and everything that must examine all micro-polys in the bucket takes longer.

Then you have the worst case - running out of memory. Bigger buckets consume more memory. And if you have a lot of threads, each has its own bucket. If the total size of all simultaneously rendered buckets exceeds the available physical RAM left, then you swap to disk, and everything slows down by a factor of 20.

In between these extremes, there is a relatively flat region where changing bucket size doesn't make any difference. This is commonly in the area between 128 and 256, as long as you have enough memory. But if you run out of memory with 8 threads at bucket size 128, then this will be bad and you should decrease the bucket size.

---

Renderosity forum reply notifications are wonky. If I read a follow-up in a thread, but I don't myself reply, then notifications no longer happen AT ALL on that thread. So if I seem to be ignoring a question, that's why. (Updated September 23, 2019)

Thanks BB very well explained it now makes full sense, but now my mischivious side is more intreged to try to see how much I can change bucket size until total failure occurs just for the fun of it. LOL call it my need to know and make havoc :)

Quote - Firefly looks outside of the current bucket to check for stuff which would influence the current bucket;  an example would be displacement materials.  So,  instead of just looking at the 8x8 bucket, Firefly actually checks a border of a few pixels around the bucket for these effects.  That means some duplication of effort.

That border is less significant if you're using a 32x32 pixel bucket.  Less duplication of effort -and less frequent fetching-  allows the faster render - if you have the RAM to support it.

If you are rendering something which uses displacement to replicate fur effects, you need a pretty large bucket. I had a horrible time rendering the sub-image at the upper left of http://www.renderosity.com/mod/gallery/index.php?image_id=2127981&user_id=445066&np&np because the boa kept being cut off due to the displacement extending beyond the bucket size. I eventually used a very large bucket size.

I've always wondered if it would be best to make your document height and width divisible by your bucket size?  That way your last row of rendered pixels at the bottom is not wasted by being smaller than the bucket size.