[Bf-committers] The (un)official render daemon discussion

[Timothy Baldridge]

Well, I haven't heard anything else from people on this topic, so I
thought I'd put up my ideas and see if I can get some feedback. Here
are some things I've thought of:

1) tiling based rendering. It should be possible to each each bucket
for a different node. It will be up to the master node to compile the
final image.
2) resulting images should be past to the render node in raw format
(32 bit floats). If we don't get this, we could get major compression
artifacts from dual compression (compression on a bucket level, and
again on the final image).
3) perhaps a new panel should be added to Blender to show the state of
a master node.
4) Topology of the system:
blender gui -> master node -> render node(s)

The master node would be responsible for managing jobs, transfering
data, and stitching files. There would be no shared drive between the
nodes, all data will be transferred over TCP sockets. Jobs would be
submitted via the blender gui. The master node will store these jobs
in a temporary folder. From here the data will be transfered to the
render nodes, allong with some rendering overrides (e.g. render frame
1, bucket 3, etc.). The resulting image is transfered back to the
master node. The master node stitches the data together, compresses
the files and sends them back to the blender gui.

The idea would be that all three parts of this pipeline are contained
in the same blender executable. The programs are invoked differently
(via command line switches, or perhaps by selecting a option in the
menu window).

Anyway, this is not designed to be a project proposal, just some
random (and disconnected) thoughts to get the ball rolling. Any
thoughts from anyone?

Timothy

-- 
Two wrights don't make a rong, they make an airplane. Or bicycles.