RendView -- Bugs and Missing Features
Non-Bug: POVRay-3.6 issue
Note that UNIX POCRay-3.6/3.6.1 is flawed in that it does not return non-zero
exit codes in failure. You need
this patch for POVRay
before using RendView with POVRay-3.6/3.6.1.
It is currently unknown if newer versions of POVRay work as expected or not!
Bugs in RendView
Unfortunately, there are bugs in RendView.
I say that because it is very unlikely that a piece of software with
that size (>1Mb source code) has no bug. In fact, I find bugs frequently
when confronting RendView with special situations.
But, do not understand me wrong: I have been rendering hundreds
of frames in network, killed clients while operating, doing stop and
cont etc. without a single problem, so this is not a piece of
However, RendView contains several highly non-trivial event-driven
state machines which are somewhat prone to illegal states and race
(Remember: "Threads are for people who don't like state machines.")
What makes things complicated is the fact that errors can happen just
about everywhere and they all want to get dealt with gracefully. Needless
to say that I simply cannot test them all.
What are bugs?
Bugs include (in order of decreasing severity):
Segmentation fault / SIGSEGV.
This is the most critical one.
Tracking down and fixing such a bug is of highest priority.
Also severe; it means that a bug was caught in one
of the many bug traps placed all over the source code. They look like
rendview: dif_ldr.cpp:1234: int foo(): Assertion `bar' failed.
Sometimes, these failures are just due to too strict assertions but they
are all bugs which need to get properly fixed by me.
The message above describes a bug in RendView.
Please submit a full bug report.
RendView uses more and more RAM (very unlileky) or fails
to clean up all allocated memory in which case, it will tell you so:
If the last line of RendView output is not something like
rendview: Alloc: 0 bytes in 0 chunks; Peak: 16040 by,211 chks; (253/0/253)
rendview: *** Alloc: 12 bytes in 1 chunks; Peak: 16040 by,211 chks; (253/0/252) ***
then you found a mem leak.
rendview: YOU PROBABLY FOUND A MEMORY LEAK IN rendview.
rendview: PLEASE FIND OUT HOW TO REPRODUCE IT AND REPORT THIS BUG TO THE AUTHOR
RendView does not what it should do: Hangs during operation, takes too
long breaks, spins idly around (busy-looping), ...
(Watch out for "OOPS: TaskManager scheduler strangely busy.")
Missing warnings, typos in output, ...
When you have found a bug...
...then do not say "Ah, it crashed two times, it's just a
piece of junk", flame the author and rm -rf it.
Instead, remember that writing such a program is not easy,
very time-consuming and that I do it in my free time.
Therefore, report the bug so that it can be fixed.
Reporting a bug
Say you have found a bug in a recent version of RendView.
First, figure out how to reproduce it. Fixing a bug
which cannot be reproduced if very hard if not impossible.
For bug reporting, please send a complete bug report (platform, version,
comand line args and RENDVIEWARGS/ LDRCLIENTARGS/ LDRSERVERARGS environment
variables as well as the output (best with -verbose=+all)
together with description on how to reproduce it directly to the
Provide everything which is needed to reproduce the bug.
Known bugs and missing features:
This is a list of missing features and known bugs.
I know of no severe bugs so these are all
non-critical bugs or missing features:
Some protection against frames getting stuck in todo list (LDR)
The issue is the following: Say, you want to render 100 frames using POVRay
and then filter them using the filter "foobar" using LDR (i.e. in a LAN).
In this case you must make sure that both the renderer and the filter
are available on at least one client. (You can have 10 clients for rendering
and one for rendering and filtering with foobar.) However, if no client
can filter using foobar, after some time, a couple of tasks will be in
the todo queue and prevent any more tasks from getting executed.
The bug is subtle because of LDR re-connect, etc.
Workaround: Take care not to provoke such a situation.
Additional files with %d spec
Allow frame number spec (%d) for additional files as well.
Non-flat directory structure for LDR
Only if people (or me) really need it in the future.
(email me in this case.)
rdir/fdir and frame pattern for LDR client
Allow user to specify frame patterns (file name patterns) and different
render/filter directories when using LDR. Currently, only the local task
source (plain RendView, LDR server) allows that.
Workaround: Who needs that anyway?
Delay output file deletion
Do not delete output files before actually re-rendering/filtering
them. (Currently they are deleted by the task source when creating
the task. Effect: in case you interrupt RendView, some more files than
necessary were deleted.)
Will be fixed soon.
Currently no plan to fix that because deleting dest files just before
assigning frames to clients will only save few frames as most
of them are queued on the client side -- and deleting them just before upload
would introduce unneeded bug prone complexity
(see -L-transfer and shared directory, failed frames,
Additional render/filter file
Allow a file to be both, additional render and filter at the
Per-frame statistics / log file
For batch operation in a render farm, it may be interesting to get
a log file which has an entry for every frame processed. Currently,
you can use the verbose output and store it in a file.
Config file support
Support for a config file which tells RendView about everything it has
to do. The config file could be treated like the known
Makefile (i.e. RendView reads it in automatically, just set
a special option in RENDVIEWARGS env var).
Information network port
...which you can telnet to and get info about done frames and
terminate RendView. (Actually, not telnet but using challenge-response
auth and proprietary protocol.) [currently being implemented]
Ability to dump output of render and filter programs to one file
per frame. The file could be deleted when the job terminates
Also, ability to do the same for the filter and have it read files
instead of stdin/out.
Workaround: Use shell script as renderer/filter. Please note the
about shell scripts
in the docu.
Support for filters which do not take input from stdin and write
output to stdout.
Workaround: Use shell script as filter. Please note the
about shell scripts
in the docu.