This is not actually a bug but I didn't found a better place to post this. So, I'm sorry if I'm posting in the wrong place!
Currently, I divide my render in layers to better manage the amount of sampling each part requires so the render times are lower.
So, I render all with transparent background to composite together latter. This technic is great to decrease render time.
However, it's a bit frustrating to watch Cycles waste time rendering empty space around the objects.
At first I thought it was because of the other layers that where not excluded from the active layer but then I did this simple test with only one layer and the result was the same.
Please check the image. In the upper image I did a "normal" render and in the second I used border region render (shift+B) and the render time dropped to half.
Is there a workaround to this? Or is this really necessary to cycles? The two renders are identical. At least I can't tell them apart. So, in theory, Cycles don't need to render the transparent part of the image. This extra second adds a lot to animation renders.
I'm sorry if this is hard to read but today my english it's not flowing..
Oh.. and a big THANK YOU to all you developers that make Blender possible. It is the greatest and most complete 3d package I have worked with. You are making history!
Thanks for reporting but this indeed does not belong in the bug tracker. It's a known issue basically, in principle it could detect that it doesn't need to take more samples but then it needs to be sure that there is no tiny geometry or background texture that might need sampling.
In the integrator panel, you can disable Progressive which gives separate control over AA samples and other samples, this can help to reduce render times for scenes like these. But for now this is not considered a bug, just something we can optimize once.
Hi there Brecht!
Thank you for your reply.
I'm not telling this is a bug, I know it isn't. But as Cycles is the main Blender render engine now, meant for production, I think that every time saving feature is a priority. In the (very) simple example I gave, the transparent part of the image takes half the frame render time. That's a lot for something you are not going to use! This is not a problem in a still render but in an animation time starts to add up.
I will take a look at the non-progressive settings. Never bothered much with it but I think is time for me to learn it.
Can I ask you another Cycles related question?
I'm buying a gtx660ti and although it has more cuda cores I read it's slower than the 500 series due to something Nvidia did. I know there's some tricks to speed things up like turning off double sided normals.
My question is: will Cycles be optimized for this new cards? Will the series 600 be faster than series 500 some day?
Thank you a lot for your time Brecht! And congratulations on the excellent work you are doing in Cycles! I love to work with it and love the node based workflow. "Thank you" will never be enough.
I understand it's important in some scenes, and I'll get to it some day, but for now we have a simple policy that this bug tracker is for bugs only.
I don't know if the 6xx cards will ever get an optimization or if it's even possible. NVidia made a choice to make their cards more competitive for gaming at the cost of performance for applications like raytracing. Newer cards will get higher clocks speeds and more cores again so that will make up for the architecture changes.
The double sided normals thing is unrelated to Cycles performance, I'm working on a fix for that but it's waiting on some work from others, probably not for this release but the next one.
Yes, I know.. I'm sorry for that! I find this forum a bit confusing.. probably because this is the first time I'm using it.
I appreciate your reply. Keep up the great work with Cycles! Thank you Brecht!