region render is useful to correct some mistakes, and i think sometimes, circle shape was more useful than the rectangle region.
OR....
Having the ability to define more than 1 rectangle. Like, say I need to render a region at the top left corner and bottom right corner, but nothing in the middle. Having the option to render 2 regions would be sweeet.
custom render region shapes would be great, or being able to isolate a material using a real time clown pass sort of thing. Lots of times I need to render the lens of an object, but don't want to hide everything else as I'd loose all the refraction and reflections. Hit a quick key to bring up a clown pass overlay, click on a color to select it and hit render region bam done. Like that idea.
I still hate the fact that even with the background as flat white, my object occupying the 50% of the middle of the image, my FPS goes way up if I render region around the object and crop out most of the white. Why does KS take so much horsepower to render flat white background?
Hmm, I am not a developer, but the way I understand it, is that even 'blank' pixels are still necessary to calculate because the image is being processed pixel by pixel, and it doesn't 'know' that that space is 'empty' until it gets there. (Using region render, over-rides this by saying, hey...don't even worry about calculating this area even once, which is why it shows up black "blank".
White pixel data is still data, in RGB, it is 255,255,255. Not saying that changing your background to black will make it any different, 'rays' will still be cast there to discover if there's anything to be calculated other than your choosen bg color.
Also, think about pure #s for a minute. Let's say I have an image that is 3000 pixels by 3000 pixels. That's 9 million pixels that need to be calculated. If I crop a region in the middle that is 1000 by 1000 pixels, suddenly my total pixel count drops to 1 million. Which I'm sure takes up way less memory too, for the CPU to intake.
This is just my understanding of why you might experience that. I am in no way qualified to give a 100% accurate answer though.
Interesting, but changing background to black give me about a 10-20% increase in FPS.
That makes sense, in thinking that KS doesn't really know when a pixel is "done" baking to get to a certian point, its usually when the user decides it done by samples, time, etc.
My question for someone smarter than us is if I am rendering with an alpha, and I always render with an alpha to a psd file, I'd like it if KS didn't calculate that white space at all. I don't use the white, bkgd, so its calculation isn't needed. Maybe that's an efficiency thing they can take a look at.
Just some numbers for fun
800x800 scene
cube filling 80% of the frame
default diffuse blue material/white background
286 fps full window
613 fps render region cropped to edges of box (550x550 pixels)
Same but with black bkgrd
686fps full window
944fps render region cropped
Thats a huge increase in fps for just taking 250 pixels off the image and changing the background color to black.
Switching to cloudy plastic gets-
104fps full window
155 fps render region cropped
Again, thats a huge gain. There are still white background pixels in that render region that don't need to be calculated. Just think if the render region could use a material as a mask, or an object as a mask for the region. Right click on an object and select "Object Masked Render Region" and it just shows you that object without turning all the other objects off. Keep reflections, AO, shadows, etc. Would be a problem if you started navigating around the scene though....
Like you , I'm woefully ignorant about how the render engines work and what they use to calculate, so Soren could be reading this and just shaking his head slowly.... :) Fun to theorize though!
800x800 is 640,000 pixels
550x550 is 302,500 pixels
That's a difference of 337,500 pixels over 50% less work. So, it's not surprising to me that you'd see that big of a jump.
This video is a little bit old now, but I think it helped me grasp what was kind of going on under the hood in ray tracing. I think Keyshot uses it's own algorithm which may not work exactly like this, but the basic think to know is that the calculations start from your frame and extend into the scene. So starting # of pixels is important in understanding how it many calculations are happening.
https://www.youtube.com/watch?v=Qx_AmlZxzVk
Thats a great primer, i haven't seen that one before. Pretty good explanation.
That still leaves room to see if there is a way to realize the gains that could be had from only rendering object based pixels, and not rendering background pixels. Especially if the render settings indicate that the user wants to render with an alpha. No need to render the background pixels if they won't be used. Cinema (and other apps) allow you to set the background color (C4D uses an actual background object) without using that color in the calculations of the render. i noticed that keyshot does this differently where it actually uses the background color in the calculation of the render. Makes sense to me, but that might just be me :) In my head since I don't see an object in the scene tree being used as the background, then there isn't anything to influence the render.