There are no restrictions on architechture or operating systems of the collaborating machines, as long as they have the software which the script uses - specifically povray, cpio and some sort of image format conversion tool. I've had this running on 12 computers in parallel - 8 Linux PC's, 3 Alphas running Digital unix ans another Alpha running Linux - without any real problems.
Before I get down to telling you how to use it I might also point you
at my patch to 3.02 which allows you to use a repeat vector on bitmaps
which are being mapped onto spheres and donuts. So yuou can tile an image
across a sphere by adding repeat <x,y> into the image map
- it's simple - and very useful. Grab the patch Here
and see a quick example here.
Since the daemon and client are both shell scripts you may need to change the first line to point to your TCL interpreter, and in the client script you need to change the line that executes POVRay so that all the relevant local config info is included on the command line. The file net_povray.ini should alway remain though, since this contains all the configuration info which applies to a particular sequence.
So you need a few config files, all the scene files for your sequence and a net_povray.ini file which includes all the POVRay settings for the frames e.g.
myscene.cpio containing
net_povray.ini
scene.pov
scene.inc
bitmap.png
where net_povray.ini loks something like.....
Input_File_Name=scene.pov
+W400 +H300
+A
-J0
you also need a directory where you are going to store all the completed frames.
Run the net_daemon script on your favourite high port and specify all the details on the command line.
./net_daemon <start-frame> <end-frame> <port no.> <frames directory> <cpio file>
The server only renders integer frame no.s - if you want fractional clocks then that will come whenever I get round to improving this. Also when you specify the range of frames the daemon checks in the directory to see if files already exist in there - if so then they will not be rendered. This means you can restart a daemon halfway through and it will know what frames have already been calculated. It also means that you;d better be sure the directory is empty if you're doing a new sequence..... anyway....
the next trick is to run the client on all the machines whcih you are using and of course point it at the server daemon
./net_client <server> <port>
and if you've done everything right then the client will request initialisation, unpack the cpio file across the network and start rendering the frame it has been alloted by the server, once it's finished it converts it into jpeg (If you wnat any other format then it's trivial to hack both the server and the client into shape), contacts the server, streams the new file across and then gets a new frame nuber to render.
And that as they say is that....... The daemon exits when it gets all the frames, so some client scripts will just crash when they try to connect after that..... don't worry, there's no clean exit written into this - i.e. you have to deleted the files yourself anyway, I didn't think that letting the script delete files I couldn't be sure it had created was a good idea.
Also there is currently no security on this, anybody can connect and pretend to be a client, but beyond DoS'ing the rendering system there's not much else to do, the daemon only accepts frames with the correct pathname, and only writes files which it has been told to render. But I make no claims as to the security or otherwise of this system. I can't think of any way to use the daemon to break into a system, although the client could concievably write any file you put in the cpio archive - e.g. ~/.rhosts but you shouldn't be pointing your clients at untrusted servers anyway,at least not in this version. The daemon is secure enough for my purposes so I guess it should be OK for you.
Oh and one other obvious thing.... you need to run a client on every machine you're rendering on - including the one which is running the daemon.
Update: Version 0.02 is now available - this removes a couple
of problems which resulted in the data being damaged during transit.
Run the script using
./assemble_sequence <command_file> <output
directory>
The command file has a sequence of commands which are used to build up the list of jpeg images in the output directory,
frame <image.jpg> <count>
Copy a single image count times - useful for title images.
fade_frame <image.jpg> <count>
Rewinds the sequence count frames and cross fades to the selected image
copy <image_dir> <start> <finish>
Copy frames from <start> to <finish> into the target sequence
fade <image_dir> <start> <finish>
Rewind seuqnce and perform a cross fade to the new image sequence
There are a few other bits and pieces.... but you can read the source for those.
Download the scripts from http://szyzyg.arm.ac.uk/~spm/anim_scripts/
Scott Manley / spm@star.arm.ac.uk
Home Page - http://star.arm.ac.uk/~spm