I think we’re in the same place.
I’m at school now (weekend) and have been playing with this unsuccessfully for some time.
To make blender work over a renderfarm, it’s going to need the -b which makes it render an image or animation in the background. You would also add either -f 1 to render a single frame or -a -s (startframe) -e (endframe) to render an animation (or at least a series of pictures if your blender file is set to save as jpeg.
The problem with blender is that it refuses to thread through to nodes on the render farm because it insists on working as one large single process. The solution is to, apparantly, use the “excellent rendering script” from http://pubwww.fhzh.ch/~mgloor/mosix-blender.html which goes something like this…
render.sh - a Mosix/Blender load balancing workload manager
$Id: render.sh,v 1.1 2005/08/05 21:27:11 gloor Exp $
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU General Public License for more details.
You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
example below will render 550 images from test.blend on 10 nodes:
“./render.sh test.blend 50 600 10”
if [ $# -lt 1 ]; then
echo “syntax: render.sh blenderscene startimage endimage nodes”
BIN=/usr/bin/blender # blender path
SCN=$1 # name of blender scene
expr \( $3 - $2 \) # no. of images to render
expr \( $DIF / $4 \) # no. of images per node
expr \( $4 - 1 \) # loop counter
for i in
seq 0 $LOP ; do
expr \( $i \* $RPN \) \+ \( $2 + 1 \)
expr \( $i \+ 1 \) \* $RPN \+ $2
$BIN -b $SCN -s $BEG -e $END -a > /dev/null 2> /dev/null &
echo " "
echo “Rendering” $DIF “images from” $1 “on” $4 “nodes.”
echo “Tasks forked, network rendering in progress.”
echo -n "Job started at: " ; date ‘+%d-%m-%y %H:%M:%S’
echo “Please wait while rendering…”
echo “Rendering successfully finished.”
echo -n "Job ended at: " ; date ‘+%d-%m-%y %H:%M:%S’
echo " "
Looking at the script carefully, it does not look like it is intended to split a single frame into separate nodes at all, but rather separates individual frames to each note to render, so if you have a 1000 frame animation and 10 nodes, each node would render fully its own allocated set of around 100 frames. So therefore I don’t think this script would be good for speeding up a long single frame yafray render.
Also, I am not sure whether it matters if each node has to have its own version of blender (e.g: should the latest blender be on all nodes?) or whether they “borrow” the executable from the central master and just lend the CPU power.
So far, after running live CD ClusterKnoppix, downloading and unzipping the laterse 2.42a blender onto a new /home/knoppix/Desktop/blender directory and then internally changing the /tmp dirs etc in the blender files and also the render.sh script to output tings to the Desktop directory, I still haven’t had success as getting separate nodes to take on the workload for blender, even though openmosix is working, and I can view workload graphs of all nodes from the master machine. Then again, I’ve mainly been trying bigf single frame renders and should perhaps use simple multiframe renders to test. Sadly, when I tried…
./render.sh basic-jpeg.blend 1 20 9
…to make a 20 frame animation of just the basic cube (basic-jpeg.blend was just that), all I got was a delay while the master node had workload of 100% There may be an issue running off the live CD as I have seen openmosix complain (terminal somewheres) about not having write permissions to something in /tmp/
Would love to get this thing sorted. Feel I am so close, but not getting there may as well be miles off.