[jc4d]

Hi all,

I was wondering if would be possible to "link" the document output size with the render region size in a temporary way, is not the same render a document of 4000x2500 with a render region in X=100% and Y=20% than render a document of 4000x500, the voxelization, SL are way too different where you can see a huge improvement of performance, so I don´t know how tricky would be that when you set a render region and hit render the document size take that percentage to make a temporary document/render size when Render render view is used.
I hope it makes sense.

Cheers
JC

[JDHill]

I think there are basically two ways to do what you want. Say that you want to render the image in 4 quadrants (not sure why, since we should really prefer to use cooperative instead). One way to do this would be to cut your resolution in half, then render using a region set to Blow-up, where you render 4 images, each with the region set to render a different quadrant. The second way, you would also cut your resolution in half, but this time, you would use shift lens to render each quadrant, instead of render region. This method is limited to a maximum of 4 quadrants, though, since lens shift only goes to 100%.

That said, my question would be: what is the reason you are doing this? Is it for getting a quicker preview of how part of the image renders, or is it more that you are trying to cut the image up, in order to render different parts of it on different machines? If the latter, as I mentioned above, you should use cooperative for that instead. Rendering in tiles, one machine might finish much sooner than another, sitting idle until the rest had finished. Then, there is the question of resuming renders; with cooperative, you could choose to render further on just one machine, and still merge everything together seamlessly.

[jc4d]

Thanks for your reply JD,

I was thinking just to make a "quick" preview renders of some areas where I need to check if the displacement (geometry vs mxm subdiv.) is enough or not, or to check if a some place needs more or special attention with the camera active to avoid surprises after hours of rendering (thanks to photoshop here and the clone tool) at the final resolution.
I was just thinking in the performance point of view that is faster to render as I said 4000x500 than 4000x2500 with the region at 100%x20% all that black space takes so much computing time that goes to nowhere.
Of course I could use blowup as well but could give "false" appreciation of the model in certain places so I could over model or submodel when at the final resolution that it requires can be just a waste of time at the end.

As a side note, blowup doesn´t respect the camera film offset.

I hope is clearer now

Cheers
JC

[JDHill]

Thanks, yes, I understand why you want to do this now. First, the black space in a region render should not cost CPU, only memory and disk-write time. So if you find it to be slow, you might want to disable MXI writing when doing these region tests. Second, in the specific 4000x2500 -> 4000x500 example, the problem is that we can't just change the resolution that way, because it alters the camera perspective. The same is true if you create the setup manually: set region height to 20% and then change render settings output height to 500 from 2500 to try to force the blow-up render to render using only that many pixels; you can't do it without destroying the perspective. I can't really give you a tool to get around that.

There is a hack workaround (it is actually implemented in the Rhino plugin) related to the shift-lens method I mentioned above, where given an arbitrary rectangle, both resolution and film size are compensated to retain perspective, with the image plane being shifted to match the rectangle using shift lens. But this is still limited to the 100% lens shift, so in your example, the most extreme region that could be rendered using this method would be a rectangle 4000px wide, 500px high, with x-coordinate of 0 and y-coordinate in the range 500-1500. You could not render the regions from y 0-500, and from y 2000-2500 at all. Since it is so limited, I don't see the point in trying to add it here; in Rhino, it has probably cause more confusion than benefit.

Regarding shift lens vs. blow-up region, this is already reported in the bug reports section; but just to clarify, I was not suggesting they be used together above.

[jc4d]

I see, thanks for the detailed explanation. I never thought about disabling mxi writing to save some performance and you are right about changing the final resolution it will "destroy" the perspective so is a no go for that.

I´m with you on adding things that could lead to more problems than solutions and anyway this is just for preview render so putting so much effort to that doesn´t make any sense.

Cheers
JC