Animation Project -- RendView
RendView is a utility to have films rendered using
POVRay (and maybe other raytracers)
and post-processed in a local distributed environment.
RendView is being developed by me (since 2001)
and distributed under the GNU GPL
(General Public License).
Note: You need a patch before using POVRay-3.6/3.6.1 together with
Status of POVRay-3.7 unknown.
- 2006/02/28: Version 0.7.1c (beta)
Bugfix for frame clock support. Added example in examples/.
- 2006/01/28: Version 0.7.1b (beta)
Minor changes to make rendview compile cleanly with recent versions
of gcc and use hlib-1.1.1.
- 2004/05/22: Version 0.7.1a (beta)
Minor bugfix release: Forgot to close /dev/urandom.
Compilation on cygwin should now work again;
now compiles cleanly with GCC-3.4 and hlib-1.0.0.
- 2004/03/25: Version 0.7.1 (beta)
Some minor features added: option -daemon
(useful to start it via ssh), logging facility to save output in
memory (only useful for not yet implemented remote admin port functionality),
incomplete admin port implementation (do not enable now).
Fixed bugs: Resuming partially rendered frames should now work
(again) with recent version of POVRay (POVRay-3.50c changed behaviour),
fixed problem with challenge response auth (rejections
of correct responses), fixed (seldom) stray characters in help hext,
fixed keepalive timeouts during up/downloading of very large files,
fixed two incorrectly failing (too strict) assertions and some other things.
- 2003/08/15: Version 0.7.0 (beta)
Some minor features added: RendView will now also render .ini
files: just use the .ini file as input frame pattern instead of the
.pov file and add the associated .pov file as
additional file (-l-r-files),
example here; furthermore,
POVRay frame clock support has been changed; read more
Fixed bugs: Stopping POVRay-3.5 now works (again?); added new
render desc parameter stopsig which can be
SIGTSTP (default) or SIGSTOP,
details; finite() and
isinf()/isnan() are no longer required which improves portability.
- 2003/07/15: Version 0.6.9 (beta)
Again some bugfixes: Prevent unfinished frames from
dropping out as "finished" when not processed at all (huh? :); transfer the
primary render/filter input/output file names when using LDR (instead
of using fixed f-%d-%d...); LDR client should now only delete
downloaded input files; when using the frame clock, the render
input file is no longer downloaded repeatedly for no reason; some more
...and new features: It should now be possible to run LDR using a
shared directory like NFS, see
here for details, and
some sort of task fit strategy is finally implemented, details
- 2003/04/07: Version 0.6.8 (beta)
Several enhancements and bugfixes: Check modification time of additional
files [added stat(2) cache for efficiency; hope it does not
play tricks on us...], read LDR password from file, automatic compensation
for different system times, fixed incorrect paths when using
-l-r-dir or -l-f-dir [still not well tested], fixed wrong
description of -L-timestamp-thresh, prevent downloading
recently modified files more than once.
- 2003/04/01: Version 0.6.7a (beta)
Some bugs were fixed; RendView on 64bit Alpha Linux on should work now.
- 2003/03/26: Initial beta release: Version 0.6.7 (beta)
After more than 2 years of development, RendView is finally about to
get released to the public.
Brief overview of RendView
The primary intent of RendViev is to be an easy-to-set up
render farm manager: Say you have access to a couple of Linux workstations
which are idle during the night and you want to use them for your
rendering - without installation of external services such as MPI,
without requiring a firewall or opening insecure services such as
Simply spoken it does the following: You give it a number of files to
be rendered (i.e. f000000.pov .. f000123.pov,
and then call RendView to have that done, either locally or in a LAN.
RendView will then call the renderer (currently, only POVRay is supported)
and (if told so) also a filter on the rendered frame.
Or, your animation uses the POVRay clock value and you want to animate
sceleA.pov in 72 frames with clock 1..3 and
sceneB.pov with clock 0..15 in 120 frames.
Of course, that's not all. Here is a list of features; please check the
docu for more complete information and how to
Job control: ability to launch more than one render/filter job at a time
(i.e. if you have a dual processor SMP box you may want to use 2 processes
at a time). (-ld-njobs=)
LDR, Local Distributed Rendering: RendView implements an LDR client and
LDR server (in the same binary "rendview").
RendView as LDR server can distribute rendering and filtering jobs to any
number of LDR clients in the local network. It does time stamp and size
checks to prevent unecessary file downloads and implemnts automatic
correction for server/client system clock differences.
Continuing operation: RendView can only (re-)render/filter frames which
got modified, just like make(1) decides whether to (re-)compile a file
Resume operation: for renderers which support that (POVRay), frames which
were rendered partly can be resumed (-l-rcont).
Continuing and resume also work with LDR; required files are downloaded
automatically to the client, (un)finished output uploaded to the server.
Lots of (colored) useful
status and info output on the terminal.
Lots of tuning options which can be passed on the command line or via
the environment vars RENDVIEWARGS/ LDRCLIENTARGS/ LDRSERVERARGS.
Per-frame blocks: you can specify what shall be done on a per-frame basis
using frame number ranges (e.g. 10-19: use filter A, 5-12: render with
radiosity, 20-30: use filter B)
Little overhead. RendView is single-threaded and does no busy-waiting
at any time.
More features: execution, tidle and job timeouts, nice values, re-connect
lost clients, stop/cont, LDR authentication, load control,
POVRay frame clock support, POVRay
spurious success detection,
client/server time correction.
Why not use PVM- or MPI-POV?
The initial problem which lead to the development of RendView was the
following: You have a large number of POV files
(frame0000.pov.. frame0720.pov) generated automatically
by a self-developed animation system and you want to have all these frames
Principally, there are two ways of getting that done: Either you render
one frame at a time on all computers simultaniously (using
or you render one frame one each box.
Initially, PVM-Pov and MPI-POV were given a try (i.e. rendering one frame
at a time on several computers in parallel). However, it showed that this
introduced a significant overhead. In fact, using PVM-POV, it was
estimated that probably twice as many frames could have been
rendered on an Alpha cluster when rendering one frame on one processor
instead of using PVM because of parsing overhead
(which accumulates when using PVM as every PVM client/slave parses the
input file). Of course, the exact ratio depends on parsing versus
OTOH, MPI-POV tended to introduce artifacts from the previous frame
into the currently rendered frame. The problem only occured when
launching it as quickly as possible (what you would always do...).
This is probably already fixed.
If you have a dedicated MPI cluster, then you may be fine with
But only few people are lucky and have that hardware. Imagine
you "just" have access to a set of workstations which are idle during the
These boxes are most certainly attached to the internet and you cannot
expect people to set up insecure rsh (as used by MPI IIRC) or
a firewall just so that you can do your rendering.
Replacing rsh by ssh is possible but again introduces
overhead (encryption, decryption, transport overhead and authentication
As long as there are more frames to render than available processors,
it is most efficient to render one frame on one processor, e.g. using
vanilla POVRay and launching one POV-Ray process on each processor (on
all computers in the render farm). That's what RendView does.
Furthermore, RendView is easy to set up: just start the LDR client on
the client machines. No need for a firewall, insecure services or things
like that. The LDR client uses a challenge response auth (using SHA hash,
AFAIK not vulnerable to replay attacks; of course this prevents anyone
from sniffing the password on the net)
to authenticate the LDR server to prevent unknown people from using
And finally, RendView has lots of additional
(Note, however, that you can probably also use RendView to launch PVM-POV or
MPI-POV for each frame in case you really find that useful.)