[Bf-committers] For the record: the Blender Render Deamon!

Ton Roosendaal ton at blender.org
Tue Nov 11 14:11:21 CET 2008

Hi all,

I keep wondering why no good, useful and simple render farms exist... 
apparently such systems are never coded by people who actually use it 
in a (local) studio setup. ;)

Just for the record, the ancient 90ies NeoGeo render deamon system is 
still worth documenting. We used it for 100s of projects, and it worked 
pretty flawless.

The system was designed to run locally, on every system in a studio 
network. At that time we used SGI's, and its design - most likely - 
will only port well in a Linux/Unix environment now. It also worked on 
a very nice background mode, allowing renders to continue while you 
were working without really noticing it.

These were the components:

1) renderd
The deamon itself, running in a terminal in background, registering its 
system info and handling messages. Running this was first thing to do 
on your system to add it in the network.
2) Render
The front-end, using fdesign "xforms", which can also run via X11 
remotely. It had buttons to set priority, add/remove .blend files, 
showing status of .blend renders, memory/swap status, status of all 
systems, etc.
3) fs
The "file select", which was a small standalone program (working like 
blender's!) to browse files.

And it worked like this:

- we had NFS running, with one shared path accessible via all 
workstations. (In our case /usr/people/deamon/ was shared). An ENV 
variable was used for it.
- when you add a .blend file (with Render) it read the file, found the 
REND chunk, which has all scenes in it that needed to be rendered, 
including start/end frames. That's what the 'render deamon' button in 
Blender was for.
- Render then splits the above info in chunks, default in 10-file 
renders, and writes every chunk as a commandline instruction ("info 
files") in the NFS deamon folder. Those commandlines could be anything 
btw, also for other programs as blender.
- The renderd deamons have internal (idle) loops checking for such 
"info files". The files had status encoded in it, and could be locked 
and changed when available for execution. For as long there are 
available "info files" it keeps running them. On succesful completion 
the files were removed.
- The renderd deamons also used sockets/pipes to accept or send 
messages. This allowed the Render front-end to manage them, to get 
status or detect whether a render command failed (crashed).

That's about it. Code can be found in the 'neogeo chest':

Would be interesting for someone to check on a similar system for 
inclusion in Blender? Are sockets and pipes supported in Windows now?


Ton Roosendaal  Blender Foundation   ton at blender.org    www.blender.org
Blender Institute BV  Entrepotdok 57A  1018AD Amsterdam The Netherlands

More information about the Bf-committers mailing list