Right before pressing the render button, selecting the right resolution for our image can be a puzzling decision, as size most directly relates to render time. However, it is not a linear relation. An increase of 200% in the resolution panel actually means four times the pixel number. Depending on the specifics of the scene, this can lead to an increase in render time from two to five times or even more.
We are aware that, for some of you, the way the uploads worked on RenderStreet was less than optimal. When we originally conceived the user interface for RenderStreet, we were of the opinion that FTP support is a thing of the past, something that has to do with the way the internet worked in its initial days, when the web was not so advanced as it is now.
Putting this week’s post together was a bit of a challenge because while I have worked a bit with Cycles, I still haven’t acquired the kind of experience you get after going through many projects. I started on the assumption that Cycles materials do influence a lot the rendering time but was baffled by how to optimize Cycles materials. There are no settings in the materials panel that would take a bit from the realism and speed up the render like in BI, so I thought that one way to use materials effectively in Cycles was to compare the different shaders, and learn to wisely pick the best ones for a specific scene. I made a kind of benchmark test with all the shaders and posted it on Blender Artists hoping to get opinions from you and other Cycles fans.
I am proud to announce that we have been accepted in the Microsoft’s startup program BizSpark Plus. This is an important achievement for us, and proves the value of our technology and business approach to the rendering market.
We recently became aware that baking very large animations takes quite some time on RenderStreet. We set out to see what the issues are and how we can improve the baking time. The first impressions was that there’s no chance to improve it, because most of the baking is done on a single thread. But we kept on researching and found there are ways to do it.
Today we’ll look into Blender Internal materials settings that can cause render times go up.
With materials, same as with lights, the more we try for realism, the more complex and slow computations become. In Blender Internal, raytraced reflections make objects come to life but kill the render speed.
This week, we’ve quietly pushed a number of updates on our site. Most have been bug fixes and algorithm improvements, not worth mentioning here. A few of these improvements are interesting though: FLM file output for LuxRender renders, capturing of the output from “file output” nodes, and faster file downloads. Let’s look at each of them in a bit more detail.
This is the second installment about the light settings.
In the Light Paths panel of the render tab, right beside the No Caustics check box there are other settings that can cut a bit from the realism of the lighting scheme in favor of a faster render. Setting the max bounces to a lower value like 4 might not be so noticeable for some scenes, and depending on the shaders used, you can adjust separately the bounces for diffuse, transmission or glossy light paths.
Just a quick note about the updates we have pushed live today.
Being notified about a major bug in Luxrender 1.2, which will cause version 1.2.1 to be released soon, we have updated our build to incorporate the fix for this bug.
Also, since Blender 2.66a is going to be released tomorrow, we went ahead and pushed it live on our farm today. This includes a number of fixes and makes the 2.66 version even more stable.
We promised LuxRender support since we first launched our closed beta. It’s been a long time since then, and I am proud to say that today we just released beta support for LuxRender 1.2. Since this is the first time we implement support for LuxRender, we thought it would be best to start with the latest version anyway.