Progressive VS. Bucket for Final

[^Lele^]

Progressive won't allow for tiled, bufferless rendering, plus it'll "touch" all the tiled textures and proxies in the scene very early on, and keep poking at them throughout the rendering phase, preventing any unloading.
So if your scene is short on RAM, bucket is the one you want to go with.
Progressive is fine if everything fits nicely in RAM, for all the reasons posted above.

[JD3D_CGI]

Just to add some extra information to this debate.... comparing bucket against progressive on Vray GPU, I did this render last night with DOF, motion blur, Phoenix smoke, using BF....

Progressive: 52.06
Bucket: 1.18.07

That was on a GTX 1070 with a AMD Ryzen 1800x in hybrid mode.

That is an absolutely stunning difference.

So stunning it is in fact worrying....

[kosso_olli]

I sent a scene to Lele, but he is still waitig for a chance to profile it.

[^Lele^]

comparing bucket against progressive on Vray GPU

I meant good old V-Ray Next, not the GPU/Hybrid version, for which bucketing is also fairly new, and likely not as optimised as it will be.
Good info, though, i'm sure matanov will want to see it.

RE: profiling: i've had a few hiccups accessing a machine to torture for a few days in a row, will keep trying.

[kosso_olli]

I meant good old V-Ray Next, not the GPU/Hybrid version, for which bucketing is also fairly new, and likely not as optimised as it will be.
Good info, though, i'm sure matanov will want to see it.

RE: profiling: i've had a few hiccups accessing a machine to torture for a few days in a row, will keep trying.

Can I do your profiling on my machine?

[^Lele^]

nah, much more expensive to proof the script to work with any scene than to fix what i need directly. Regardless, we won't divulge the exact data, the profiling is to see if we can make something (not obvious) better.

[dean_dmoo]

Finally got round to testing this. Used the Sint-Oedenrode project and the first image in the set which is probably pretty tough to get through with the dark wood in the shade and vrayenvironmentfog (https://forums.chaosgroup.com/forum/...sint-oedenrode)

VrayNext update1 / max2018 / win10
Dual Xeon E5-2680v2 2.8ghz (total 20 cores / 40 threads) 128GB
3000x2250px
Bucket 0.01 = 6 hours
Progressive 0.005 = 15 hours (as mentioned earlier this is supposedly similar to a bucket at 0.01)

The progressive was cleaner in the reflection and lighting passes but not especially noticeable in the rgb pass. Running a progressive at 0.01 atm to see how that turns out.

Progressive 0.01 = 7.40 hours.min
Most of the passes are closer to the 0.01 bucket now. I again can't see any difference in the rgb pass.

[kosso_olli]

Again, that is an increase of 20%. Too much difference in my opinion.

[^Lele^]

As the resolution and REs grow, progressive will have to keep a *lot* of data in RAM, constantly accessed for reading and writing (in the latest sample it's 6MPx at 32bpc *times* the channels in each RE.).
Something bucketed won't do, regardless of resolution (in fact, it's always only the data which fits in the buckets which gets constantly tampered with.).
That will slow progressive down, but i ain't sure 20 or even 30% for a 3 or 4k image with REs qualifies as "too much", tbh: speed at that point will be a lot dependent on that of RAM, and regardless, it'll never match that of the same system perusing a lot less of it.
What makes you say that? Do you have a paragon? Just curious.

p.s.: when i made the claim (in the other thread) that above 10% was to be reported as bug, i made it in context: small enough screen area, and no REs, to show there is no inherent penalty in the algorithm. Obvious and less obvious usage restrictions do apply.
p.p.s:

progressive (0.005) which according to Lele, iirc, is similar to 0.01 for bucket.

Did i say that? I can't recall it at all, but the noiseLevel RE is there to prove me wrong if i did. Maybe i was talking of the different noise threshold behavior with the GPU engine? Either way, in CPU noise levels should match exactly, if noise pattern won't.

[dean_dmoo]

For me the advantages of progressive for stills outways the speed advantage of buckets for the reasons mentioned earlier in the thread (timesetting, ability to work with wip renders whilst rendering).

^Lele^ , maybe I misunderstood the noise settings in the post. Probably also due to the fact that the default vray settings does the same (progressive at 0.005 and bucket at 0.01).

[kosso_olli]

What makes you say that? Do you have a paragon? Just curious.

Well, if I have the choice between two image samplers, and one of them is 20-30% slower, I will of course never use the one that is slower. One render is finished in 40 minutes, the other one after 60 minutes. Obvious choice...
I tried to give progressive for production a chance since it was introduced, but the disadvantege outweighed its benefits (are there any?)

[^Lele^]

I tried to give progressive for production a chance since it was introduced, but the disadvantege outweighed its benefits (are there any?)

Well, for LookDev, it's hard to not see the benefits of a progressive approach to rendering.
Then again, one hopes one's not doing lookdev on a 10k image as a whole, lest those benefits disappear.
Resumable rendering is another big plus, in a way not doable with buckets (ie. improving the final image quality with added rendertime later on), and so is realtime denoising.
All of these, of course, work exceedingly well within reasonable (based on one's hardware and scenes) limits, stretch any tech too far, and it'll break.

For outright performance, though, you're very right, bucket is, and for the foreseeable future, will be the best choice (again, especially when proxies, tiled textures and bufferless high res renders come into play).

[dgruwier]

I'd be curious to see some more scientific tests, with noise level comparisons based on a ground truth render. Just switching the sampling type and seeing the render times go up or down isn't really saying much without looking into how the image is or isn't affected, and with these super high quality renders it's impossible to really get a feeling for the noise differences. I might give it a shot when I have downtime.

[^Lele^]

I'd be curious to see some more scientific tests, with noise level comparisons based on a ground truth render. Just switching the sampling type and seeing the render times go up or down isn't really saying much without looking into how the image is or isn't affected, and with these super high quality renders it's impossible to really get a feeling for the noise differences. I might give it a shot when I have downtime.

I agree. There are also benefits to image quality when doing noise thresholding over the whole screen, rather than within the bucket.
As far as noise measurements, it's now fairly easier than it used to be thanks to the noiseLevel RE (all one needs is to measure that one, without getting into kernels and assorted, arbitrary oddities).
I'll get profiling Olli's scene asap, and report what's publicly relevant, but please do not hesitate to give it a go yourself.

[werticus]

We use progressive in production and bucket for final render. Mainly because of either ram use or because we are doing animation most of the time. Usually try to be clever about the bucket size and pattern on a scene by scene basis because those settings can make a much bigger difference than you think.