lil buckets

[jamesf73]

toward the end of a render when the bucket size gets smaller is great but on an intensive render the smaller buckets will finish and you're still left with the full-size buckets rendering. would it be possible to have a setting where you decide when the buckets subdivide?

that is all

j×

[gadzooks]

"Lil Buckets" would make a great Rapper Name!

[padre.ayuso]

toward the end of a render when the bucket size gets smaller is great but on an intensive render the smaller buckets will finish and you're still left with the full-size buckets rendering. would it be possible to have a setting where you decide when the buckets subdivide?

that is all

j×

I don't know the feasibility in terms of programming on this one, but I second that idea.

[JezUK]

If you know your scene well and know where that issue bucket area might be, you can right click on the image in VFB before rendering to LOCK Bucket Start Position - saved me a lot of time on a recent render. (I have VRay NEXT 1.2 so might not be available in your version).

[jamesf73]

true, but doesn't work for animations or if all of the buckets require intensive rendering

[padre.ayuso]

true, but doesn't work for animations or if all of the buckets require intensive rendering

Or... if you send to render on the network... I do the suggestion from Jez, but sometimes I don't feel like rendering on my station and want to send it on the network.

[zoranm]

I usually reverse direction of render to help out in those situations. For example, if I render something with glossy floor I'd reverse render direction from bottom to top. That way buckets clear the most intensive part first
z.

[thomes]

maybe this could be easy programmed using the vrayrendertime render element. if you do preview renderings this could be calculated before you do the final render.

but for sure this topic is really really a underrated time saver ! how often do you wait for a last pixel to come...sometimes many minutes.

[^Lele^]

Solutions to the problem have been studied for a while now, but none so far proved good and reliable enough to be brought out of the Proof-Of-Concept phase.
It's all but trivial, and surely it has *not* been ignored, by us, or by anyone else in the business, i reckon.
With the kinds and amounts of data a render requires today, it's no surprise no one has come up with solutions.

[JD3D_CGI]

I think all of the suggestions here make sense, depending... we are still in this phase where actual human expertise matters! SO for example, say I was doing a horizontal pain with lots of trees at the bottom but not at the top, I might set the bucket order to go "bottom to top" to ensure it always got the heavy stuff first.

Sometimes "spiral" is the better option.

I heard that maybe in the future, using lightcache they will be able to get a sounding of which areas may take longer and start from there.

From what I gather, lots of cool tech relies on a lightcache pass to take a quick reading of the scene.

[^Lele^]

JD3D_CGI precisely.
The LC may be eventually able to find out more info about the scene, and help distributing workloads better right from the start.
Notice the conditional tense, though: It's still in the research phase.

[JD3D_CGI]

JD3D_CGI precisely.
The LC may be eventually able to find out more info about the scene, and help distributing workloads better right from the start.
Notice the conditional tense, though: It's still in the research phase.

This is interesting... does the light cache know if something is highly reflective or has like, complex refractions etc? or can it just know basic diffuse colours and geometry density?

I would have thought, that the lightcache could use some kind of A+ pathfinding algorithm to give every square a "weight" and walk from the hardest to the lightest.

At this stage, even just geometry density would be a good start.

I am curious about the kinds of challenges you might face.

[^Lele^]

Well, the "premultiplied" light cache, in action since around v 3.4 (i think. could be earlier or later) already substitutes parts of the scene for its own data, when it makes sense to do so.
Imagine you're tracing a doorway behind a corner, a doorway you do not see.
The LC will "have been there" while tracing, and will know the average color and value of the area under one sample.
When the final tracing happens, if a ray goes around the same corner, and finds the LC sample there, it can use that average, instead of sampling the shaders and geo all over again.
While simple when stated like this, it's all but simple to code (i can only assume.), and has many potential pitfalls to avoid.

The same goes for buckets priority, with one added issue, in that the metrics to determine what will render for a long time are many (you mention poly count and reflectivity, i'd add gloss, lighting level, ray marched object like volumes, SSS shaders, complex shading trees, and so on...), and combine to produce variable results (i.e. heavy geo without much light and with simple shaders will render quick.).
Further, the LC isn't doing the same fine job as regular tracing does (1mil samples across the screen at defaults, instead of maybe 1000 per pixel...) , so it can't know the solution to the render problem exactly, and extra care has to be exercised because of it.

I'm being exclusively discoursive here, not exactly factual: i do not code the LC!
Take everything with a pinch of salt.