This story was originally published in the Blender Art Magazine issue #41. You can read it in the magazine, and we are reproducing it here for your convenience.
In this article, I am going to write about the story of RenderStreet, the next generation render farm dedicated to rendering Blender projects. I will touch on the topics of how we came up with the idea, what was like building it and how it turned out in the current stage.
Just a quick note to let you know that we have updated the blender 2.67 version we have on the site to the latest released by the Foundation. So the current version is now 2.67b. This ads a number of fixes over the 2.67a version and should increase the stability of the renders done with it.
Rendering anything interesting with 2.67? Let me know in the comments.
It’s here. The long awaited Blender 2.67, with it’s support for SSS and FreeStyle has been released a couple days ago by the Blender Foundation. As usual, we added support for it just a day after it has been released, so you can enjoy this stable release of Blender.
We have also moved all projects that were using the latest SVN version of blender to use the stable 2.67 instead and removed the support for that SVN version.
When we built the first version of RenderStreet, we started with the idea that we can take advantage of Blender’s pack external data feature and make sure the files are uploaded properly, with all the data needed to render them.
As they say, no plan survives the contact with the customer, so a while after we launched we ran into issues with Blender features not supported by the pack operation. Some of them, like the external libraries, were fixed by the dev team. Others, like the font embedding, had workarounds. But it became obvious that sooner or later we will run into something that can’t be supported at all.
There’s an interview with me on the BlenderNetwork site. You can check it out on their site:
http://www.blendernetwork.org/blog/interview-render-street
FreeStyle has been available for Blender for some time, but it required a separate build of Blender. That made it difficult to support it on our farm. With the inclusion in the main development trunk with 2.67, FreeStyle will make it into the official release of Blender, so we can support it at RenderStreet as well. Hello cartoon face 🙂
I am proud to announce that we have recently acquired the blenderrenders.com website. This marks a new step in our expansion, and brings on board the oldest Blender dedicated render farm. Since RenderStreet already offers all the features included on BlenderRenders, we decided to invite all the users from the acquired site to join our farm, and give them an extended signup bonus, to facilitate the transition.
Full press release after the break
We added support for rendering your Blender projects with LuxRender on RenderStreet some time ago. That was all fine and we were able to serve our customers who used both Blender and Luxrender. Though the problem remained that not all people using LuxRender build their projects with Blender. We’be been working for some time on this and the fruits of that work can be seen as of this week.
OSL has been supported in Blender for some time, and we have been working on adding it to RenderStreet as well. It should have been supported some time ago, but we ran into issues building the support for the OSL compiler on our platform. So , because of that, it has been delayed for a while.
One place we should definitely not skip when trying to improve our render time is the Performance panel in Render tab.
Rendering to tiles makes better use of the processor power. In the newest Blender version, the numbers in the tiles section means their size in pixels, but understanding which size works best is a bit baffling. Tests showed that GPUs work best with 256 x 256 tiles while CPU makes best use of the 64 x 64 tile size (regardless of whether we are talking about BI or Cycles on CPU).
It’s been a long waited feature for Blender, and finally SSS is here. That’s Sub-Surface Scattering for those of you not familiar with the acronym. It means that the light penetrates the object surface and reflects / refracts in the depth of the object, not only on the surface.
What does it mean to have support for this? At least more realistic skin, but generally speaking better and more realistic materials for your renders.
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.
Today we’ll take a look at Cycles materials.
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.
