Follow our progress!

In the studio we have a variety of systems: Maqina Xeon workstations, Dell Xeon blades, off the shelf Intel I7’s, older workstations from Big Buck Bunny and our Justa-Cluster i7 render nodes so we thought it would be interesting to compare render times.

The tests below are not as comprehensive as they might be, but since we also use these systems on the farm and as artists workstations we decided to keep it simple.

Testing

Here is a complete scene from the movie bundled up so you may test blender on your own systems and compare render times with our studio systems.
Being a final shot this includes everything: sintel, bamboo environment, animation, textures, compositing etc.

Or on the command line…blender --background ./scene_05.2b_bundle/05.2b_comp.blend --render-frame 65

This blend file will only render correctly in the render branch of blender which can be found on graphicall, these tests were made with svn revision 29834 of blender.

Quick Render

Included times for one of our test renders. This file is not available for download.
The Scene shows a checken flying: 1024×4380, Full simples (5), raytracing, environment lighting & compositing.

Operating Systems

We are using 64bit Linux – Debian Squeeze for the Justa-Cluster & Ubuntu 10.04 for everything else. I like to keep configurations similar to avoid glitches & incompatibilities.

Compiler

Debian’s gcc-4.4.4I did some quick tests with clang (llvm based C/C++ compiler) and found if anything it’s slightly slower then GCC, however my tests were only with ~3 different test renders and roughly equivalent compiler flags.

I attempted to install Intel C++ compiler but didn’t manage to get the redhat packages installed on Ubuntu (needed 32bit stdc++ libs for 64bit compiler at which point I gave up).

C/C++ flags

Typically Blender developers discourage using any optimization known to be risky. For Big Buck Bunny we were more conservative because we wanted blender to run with minimal problems but for Durian Brecht and I agreed to try more aggressive optimization flags. There have been some occasions when we hit bugs in the optimized builds that were not in debug build but often these are caused by very very big numbers or NAN’s where the result isn’t useful anyway.

Maqina C6850DC 3D Workstation (Quad Core2 Q6700 @ 2.66GHz, 8gig ram)

for the test file you might not be able to render with less then 4 gig of ram.

the render farm software is not currently released but it will be released with all the other scripts and utilities with the production files.

Ton was interested in seeing times for quick test renders so I ran one of our fastest test files on all the systems so I have included times above.

– campbell

This entry was posted
on Thursday, July 1st, 2010 at 12:07 am and is filed under Development.
You can follow any responses to this entry through the RSS 2.0 feed.
Both comments and pings are currently closed.

on OSX with various builds from graphicall.org and my own builds I create often,I get a crash every time I attempt a render of the “05.2b_comp.blend” blend. It opens fine and I can do nearly anything but render just fine. Again, with various new builds from myself and others that are around build #r29850 +/-, crash every time with the following error:

EDIT: narrowed it down, each of the sub-blends(appended/linked) rendered fine EXCEPT for the “sintel.blend”, presenting the same . Of course the “05.2b_comp.blend” & “05.2.blend” still crash on render as well.

The sintel.blend presents the SAME ERROR report on crash as the other “05.2 & 05.2b_comp” blends

@Blenderificus: I get the same results on Windows XP64 4-Core AMD with 8GB RAM. Crash-aroony on render. The sub files seems to render without a crash.

File scene_05.2.blend contains an error on layer #2. Try this…
Turn off layer #2 and use layer #1 in it’s place.
Save the file over top of the original.

Then open up scene_05.2b_comp.blend and try to render the scene.
It worked for me after that.
Remember to visit the Performance TAB and try out something other than Octree. It still seems like a good percentage of the render pre-processing is still single core. That would be a great place for the coding team to focus on optimization.

Really cool! That thumbnail thing is awesome. I’m on Linux and using Blender 2.5 Beta 2; why am I not seeing the thumbnails? Ubuntu Lucid, Nautilus, just the standard stuff. Do I need to download SVN rev. 29834 to make it work?

after much testing on the Sintel.blend, I’ve found that I have to delete nearly ALL the content(meshes & rig) in the entire blend to get blender to stop crashing on render(with the same error I reported earlier). I can usually narrow down the culprit of a crash easily, but this seems like it might be reliant on multiple elements in conjunction. I’ll see if I can get some more time to look over the blend. But at this point, rendering the “sintel.blend” on OSX builds around # 29884(some earlier and some later builds mostly 64bit builds) just crashes every time unless nearly all elements in the blend are deleted before attempting a render.

@ideasman42: i usually try vbo’s as an initial culprit in such cases, and forgot to mention that I had already tested having VBO’s on and off, no change, still constant crashes.

@Atom: I tried the fix you mentioned, however it didn’t fix the render crash. The issue appears to be in the “sintel.blend” file, not the blends that house it. Thanks for the suggestions though 🙂

I’ve tried different raytrace structures(octree, bvh), turning off antialiasing, and a host of other tweaks attempting to get it to render.

IMO a notable item I found was that when I MADE EVERY OBJECT IN THE ENTIRE BLEND NON-RENDERABLE(ctrl+h), I still get the crash. Maybe something is happening during pre-processing the elements to be rendered(even though they aren’t even toggled active to be rendered). Though I’d throw that in.

2x octo-core opteron 2435, 8gig ram
12 threads: 24:05.72
6 threads: 35:55.90
Two observations: blender does not scale with the amount of threads. This processor looks slower then the i7, but other benchmarks shows a completely different story.

sorry for the additional noise on this thread, but wanted to say that after trying MANY MANY tings to get the blend to render on many different recent OSX build(my own and from graphicall.org), I build a 29943 build myself, 64-bit osx, and all seems to render without crashing on OSX now(at least for the “sintel.blend”!!!!

To whomever did whatever commit to clean things up for OSX users, thanks!! the Blender devs rock!!!

Where can I get assistance with the dark render thing? It’s got me baffled.

It’s not dark like the brightness has been turned down. It’s more like Sintel’s running through the forest just before an epic thunderstorm with the sky in the background being dark gray while everything in the foreground looks just fine.

I did a run of this file using a RackSpace Cloud Server (Fedora 13 instance, built SVN render branch from revision 30336). I tried on the 1 GB RAM instance, which outright choked, and then on the 2 GB RAM instance, which managed to render the scene, though needed the swap file since it reached a peak RAM usage of 4572.98 MB of RAM.

Blender reported 01 hr, 09 min, 20.74 seconds for the render. At $0.12/hour for the RackSpace instance, that’s 13.87 cents/frame. So, for those of you looking for some extra render farm space at a per-hour charge, that’s how RackSpace’s servers stack up.

I’ll try a 4 and 8 GB instance to see how they compare; I’m guessing the 4 GB one will shave some time off since it won’t be paging as much, but probably won’t be cost-effective to go to the 8 GB.

Hi,
On my I7860 with 8GB Ram, it takes 58:31.67. By the way, is there a Blender version that can use the power of any GTX460 GPU to boost this or an experimental project to help ?
Regards, and Keep going on your incredible work!