Swineworld.org Blender Scripts

Network Rendering in Blender

Development Notes

General

The server part is implemented as a RPCserver that runs within Blender. It provides functions for uploading a .blend file, rendering a single frame and downloading the resulting image to the client.

The server announces its availability by broadcasting the uri of its RPCserver anyone listeniny on port 8082/UDP (a scheme I gleaned from Oisin Mulvihills autoconnect package. Similar designs are used in protocols like DHCP etc.)

The client part basically maintains a pool of available servers and dispatches individual frames to these servers (and some it renders itself)

Server

The server consists of three threads (besides Blenders own control and rendering threads):

the RPCServer
the Broadcast Thread
the Interrupt Thread

The RPCServer runs blocking, i.e. it handles incoming requests one by one. It can be stopped in two ways: a client may invoke the stop() method or the user may press the escape key. (althougj that doesn't seem to work at the moment)

The Interrupt Thread is responsible for monitoring the escape key. If detected it arranges the RPCServer to stop.

The Broadcast Thread sends the uri of the RPCserver every 5 seconds to anyone who's interested by broadcasting it via UDP.

Client

The client consists of many threads:

a Listener thread, and
several Renderer threads

The Listener thread manages a pool of Server that it updates when it receives a broadcast from a server.

A Renderer thread is created when a server becomes available. (this might be the local machine itself although this is handled slightly different from frames rendered remotely)

Local networks

As mentioned in the section on security a server broadcasts its availability to anyone. Normally an edgerouter or firewall will prevent this broadcast to cross to an outside network (especially if the local addresses are local, i.e. RFC1918 addresses).

Nervertheless the server only accepts connections from what it considers to be local addresses. Since I cannot find a reliable and portable way to determine the netmask of a network interface, the following heuristic is used:

determine ip address via gethostbyname
if this is a RFC1918 address, use corresponding network definition (see below)
otherwise, assume it a C class network, regardless the ip address

This clearly is not standards compliant if you use CIDR based network definitions but i think it'll do for now. It also may fail if you use routable (i.e. non RFC) addresses from a B or A class network on your local network but you shouldn't do that anyway.

RFC 1918 networks

IP address	Allowed addresses
192.168.C.D	192.160.C.*
172.16-31.C.D	172.16-31..
10.B.C.D	10...*

NetworkRender API

There is also an epydoc generated API documentation available.

Swineworld.org/Blender