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 here.
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 minor fixes.
...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 here.

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.

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 rsh.

Simply spoken it does the following: You give it a number of files to be rendered (i.e. f000000.pov .. f000123.pov, scene.pov, colors.inc) 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 launch RendView.

• 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 (-l-cont).
• 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.

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 rendered.

Principally, there are two ways of getting that done: Either you render one frame at a time on all computers simultaniously (using PVM- or MPI-POV) 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 rendering time.

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 MPI-POV. 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 night. 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 overhead).

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 it.
And finally, RendView has lots of additional features...

(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.)