Tweet
I've been working on a project involving outputting a lot of high-rez stills recently. I'm mostly rendering by hand into the VFB, and have been running into the usual problem of certain buckets taking forever to resolve at the end of the render. Sometimes it can take almost as long for a few of the final buckets to finish as it's taken the whole rest of the image.
One of my workarounds for this is to use resumable rendering, and once the final set of buckets have been picked up and bucket subdivision starts, I will kill the render to force Vray to keep using as many CPUs as possible. I've noticed that problem areas which are subdivided often resolve exponentially faster when broken up like this.
This mostly works fine, but I'm mystified as to how and when Vray decides to subdivide, beyond obviously the point at which there are fewer unrendered buckets than there are CPUs available. In most cases, once subdivision has started, killing and restarting the render will result in all or most of the unrendered tiles being subdivided to the first level. However, sometimes this doesn't seem to happen -- each CPU will again just be allocated a 64x64 tile (this is frustrating). Other times I've seen strange mixtures of all three bucket sizes pop back into the VFB.
Is the existing tile size at the time the render is aborted written into the .vrimg file in some way? Or, otherwise what is the reasoning used by Vray in allocating a tile size when restarting a resumed render? Is this simply an image tessellation issue?
One of my workarounds for this is to use resumable rendering, and once the final set of buckets have been picked up and bucket subdivision starts, I will kill the render to force Vray to keep using as many CPUs as possible. I've noticed that problem areas which are subdivided often resolve exponentially faster when broken up like this.
This mostly works fine, but I'm mystified as to how and when Vray decides to subdivide, beyond obviously the point at which there are fewer unrendered buckets than there are CPUs available. In most cases, once subdivision has started, killing and restarting the render will result in all or most of the unrendered tiles being subdivided to the first level. However, sometimes this doesn't seem to happen -- each CPU will again just be allocated a 64x64 tile (this is frustrating). Other times I've seen strange mixtures of all three bucket sizes pop back into the VFB.
Is the existing tile size at the time the render is aborted written into the .vrimg file in some way? Or, otherwise what is the reasoning used by Vray in allocating a tile size when restarting a resumed render? Is this simply an image tessellation issue?
Comment