|
|
RendView is a utility to have films rendered using POVRay
and post-processed in a local distributed UNIX/Linux environment. Features
include rendering/filtering a sequence of frames (f000.pov,f001.pov...)
or a list of scene files and POVRay clock values, tuning on per-frame
basis, and resuming partly-rendered images, all either completely
locally or distributed in a local IP network.
New features: (0.6.9 -> 0.7.0)
- 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)
- POVRay frame clock support has been changed; read more on home page
Fixed bugs:
- Stopping POVRay-3.5 now works (again?);
- added new render desc parameter stopsig which can be
SIGTSTP (default) or SIGSTOP
- finite() and isinf()/isnan() are no longer required which
improves portability.
As always, check the homepage for more information.
Please report any bugs directly to me (email: see homepage;
see also "rendview --author").
Homepage:
http://www.cip.physik.uni-muenchen.de/~wwieser/ani/rendview/
Demo/Examples:
http://www.cip.physik.uni-muenchen.de/~wwieser/ani/rendview/docu/examples.html
Have fun...
Wolfgang
Post a reply to this message
|
|
|
|
However your description does not tell enough what is behind. Let me add
this from your WEB-Site, as it helped me to understand what is is about:
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...
a.. 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=)
b.. 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.
c.. 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).
d.. Resume operation: for renderers which support that (POVRay), frames
which were rendered partly can be resumed (-l-rcont).
e.. Continuing and resume also work with LDR; required files are
downloaded automatically to the client, (un)finished output uploaded to the
server.
f.. Lots of (colored) useful status and info output on the terminal.
g.. Lots of tuning options which can be passed on the command line or via
the environment vars RENDVIEWARGS/ LDRCLIENTARGS/ LDRSERVERARGS.
h.. 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)
i.. Little overhead. RendView is single-threaded and does no busy-waiting
at any time.
j.. 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.
--Theo
-----------------------------------------------------------------------
Distributed Network-Rendering or Local SMP-Rendering. With SMPOV and
POV-Ray 3.5. * Download free at: http://www.it-berater.org/smpov.htm
Post a reply to this message
|
|