[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':
http://download.blender.org/source/chest/neogeo/frank/
Would be interesting for someone to check on a similar system for
inclusion in Blender? Are sockets and pipes supported in Windows now?
-Ton-
------------------------------------------------------------------------
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