Basic operation
As you already know, there are currently two task sources:
The local task source using files on your local hard drive and the
LDR task source effectively implementing the LDR client and
all the network communications needed for LDR on the client side.
For a running RendView process, the task source generates tasks
which are fed into the taskmanager
to get them processed. Finally, the taskmanager gives the tasks back
to the task source with success/failure info attached.
The local task source
The local task source is one of the most important parts. If you ever
intend to have a frame rendered or filtered, you have to tell the local
task source (LDR server or normal RendView) about that. The local task
source saves several parameters about the frames to be rendered/filtered
such as the file size, additional arguments to be passed to the
render/filter process etc. These parameters may vary between different
frames. This is the reason why I introduces per-frame blocks
(see below).
Okay, before looking at the per-frame blocks and at the parameters,
first some words about what the local task source does:
Normally, the local task source checks for the existance of the frame
input file (e.g. POV file for rendering (or rendering and filtering)
or some image file when only filtering). If the file does not exist,
an error occurs.
If you specify -l-cont, you switch on continuing.
This means that RendView additionally checks the time stamp: If
the input file is newer than the output file, the frame is re-rendered
(and also re-filtered if requested), otherwise it is skipped.
Also, the modification time of additional files is checked and files
are re-processed in case one of the additional files got modified (unless
you switch that off using -no-l-add-check-mtime).
(Note: If input and output files have equal time stamps, input is
considered to be modified.)
If you specify -l-rcont together with
-l-cont, you tell RendView to switch on resume
operation.
(Note that -l-rcont without -l-cont has
no effect.) Resume operation is only implemented for rendering and
means that when RendView kills a render job (because of user request
using SIGTERM or two SIGINT or because of a timeout)
and the render job leaves an unfinished frame, this frame is kept
and renamed appending the suffix -unfinished. When you
launch RendView again it will check if an unfinished frame
exists, check the timestamp and then will tell the renderer to
resume the unfinished frame (or completely re-render it if the timestamp
demands that). Once the file is completely rendered, the
-unfinished suffix is removed. (In fact it is removed
before resuming rendering.)
In case a job is not completely successful and you do not
pass -l-rcont, the output file is deleted.
The local task source also deletes an existing output file if
it comes to the conclusion that the frame has to be re-rendered/filtered.
This means that you can safely symlink render/filter output files
because the symlink will be removed before the task is fed into the
task manager.
PLEASE NOTE one problem with POVRay: If you run more than one
POVRay process on your box and you are using POVRay's clock value
with the same input file (say, sceneA.pov), then you can run
into trouble with -rcont. This is due to POVRay using
a temporary file when resuming which gets named sceneA.tpn in
this case. Hence, both unfinished frames (say frameA-00017.png
and frameA-00018.png) are temporarily written into
sceneA.tpn which simply produces garbage or even worse:
confuses that POVRay process which was started lateron.
But note that this problem does neither appear if you are using
separate frame files (e.g. frameA-00000.pov,
frameA-00001.pov, etc.) nor if you are only using one
POVRay process at a time (i.e. each LDR client runs with
-ld-njobs=1).
Per-frame blocks
A lot of parameters can be specified on a per-frame basis, i.e. you can
set them differently for different frames. I was looking for a nice
way of doing that and came up with a simple but powerful method:
frame ranges. It simply means that you can set the parameters
for a range of frames by specifying the start frame number and the
number of frames (that follow). (This is useful, because when making
animations it is just natural that ranges of frames appear which need
similar parameters.) There are a number of parameters which
can be specified on a per-frame basis using per-frame blocks (see further
down).
Per-frame blocks work in the following way: There is one per-frame block
called the master frame block. This block stretches over all
frames to be processed and only provides a set of default parameters
in case no other per-frame block covers that parameter for a particular
frame. You can set parameters
for the master frame block by simply using e.g. -l-rd=povray3.5
or -l-r-fc.
If you need different parameters for some frames, say for example the
frames 30...49, then you use a per-frame block beginning at
frame 30 and being 20 frames long, e.g.
-l-30:20-rd=povray3.1g or -l-30:20-r-fc
(or -no-l-30:20-r-fc).
Whenever you specify a previously unknown frame range using
-l-F0:N-whatever,
RendView interally allocates a new per-frame block which collects all
parameters specified for this frame range.
After argument processing is done, overlapping blocks are splitted and
parameters merged. This works in the following way:
Say, two frame blocks A and B overlap. Then they are split into no more
than 3 blocks, A, A+B, B, where A and B stay untouched while A+B
gets all the parameters specified for A and B. In case A and B have
different parameters (e.g. A uses renderer povray3.1 while B uses povray3.5),
an override error occurs.
Note that in a per-frame block you only have to specify
those parameters which differ from the master frame block. Because
after merging/splitting the per-frame blocks, all the not yet set
parameters get filled in from the master frame block. (This actually makes
parameter merging at frame split time useful.)
Note also that you can use
-l-r-30:20-r-files+=extra_file.png in case the per-frame
block 30:20 needs all additonal render files as specified
in the master frame block but additionally the file
extra_file.png. This also works for additional arguments
-l-r-args (and the same for the filter part).
Finally, note that RendView throws away unneeded per-frame blocks.
Per-frame blocks are not needed if they have length 0 or if
the master start and end frame (see -l-startframe,
-l-nframes) will do not overlap with the frame range
of the per-frame block. E.g. if you specify -l-nframes=0,
then all per-frame blocks will be thrown away (as no frames will be
processed at all).
Actually, RendView also deletes per-frame blocks which have the
same content as the master.
An example for per-frame blocks
Consider the following example: (Note that you can use the advanced
cmd line passing using -section-{...-} as described
in the database section.)
-l-rd=povray3.5 -l-size=320x240 -l-r-args="-J"
-l-30:20-{ -rd=povray3.1g -size=640x480 -fd=shrinkfilter
-f-args="-factor 2" -}
-l-40:15-r-args+="+A0.3"
Then, all frames will be rendered passing the additional argument "-J"
to the renderer; frames 30..49 will be rendered with povray3.1g at a
size of 640x480 and have the shrinkfilter applied which gets the
additional arguments -factor 2 passed (of course, you have
to supply the shrinkfilter and an appropriate filter desc e.g. in
the filters.par file).
Additionally, POVRay gets the anti-aliasing argument +A0.3 passed
for the frames 40..54 (additionally to -J).
All other frames get rendered with povray3.5 at a size of 320x240
and not filtered at all.
You can control these settings by having a look at the verbose output
right after starting RendView.
Note: Do not pass -l-nframes=0 here because
that will make RendView throw away all the per-frame blocks as they are
not needed! If you just want to see the output without having any frames
rendered, you can pass -opmode=ldrserver without specifying
any clients and then RendView will exit with an error right after
dumping the local task source's info.
The output will look something like that in the above example:
Local task source: jump: 1; nframes: [unlimited]; startframe: 0
Continuing: no
Master frame info (complete dump):
Renderer: povray3.5 (povray driver); output format: PNG (8 bpc)
Size: 320x240; cont operation: resume (-rcont)
Render dir: [cwd]
Render timeout: [none]
Clock value: [none]
Add args: -J
Add files: [none]
Filter: [not filtering]
Filter dir: [cwd]
Filter timeout: [none]
Add args: [none]
Add files: [none]
Frame patterns: render: "f%07d.pov" -> "f%07d.png"
filter: ... -> "f%07d-f.png"
Frame info difference for frames 30--39 (10 frames):
Renderer: povray3.1g (povray driver); output format: PNG (8 bpc)
Size: 640x480; cont operation: resume (-rcont)
Filter: shrinkfilter (generic driver)
Add args: -factor 2
Frame info difference for frames 40--49 (10 frames):
Renderer: povray3.1g (povray driver); output format: PNG (8 bpc)
Size: 640x480; cont operation: resume (-rcont)
Add args: -J +A0.3
Filter: shrinkfilter (generic driver)
Add args: -factor 2
Frame info difference for frames 50--54 (5 frames):
Add render args: -J +A0.3
(The complete call to RendView was:
rendview -rdfile=/path/to/my-renderers.par
-fdfile=/path/to/my-filters.par -l-rd=povray3.5 -l-size=320x240 -l-r-args="-J"
-l-30:20-{ -rd=povray3.1g -size=640x480 -fd=shrinkfilter -f-args="-factor 2" -}
-l-40:15-r-args+="+A0.3")
You see how the frame splitting and parameter merging worked as well
as how to use the defaults from the master per-frame block.
For a complete list of supported parameters, see below.
Parameters understood by the local task source
The local task source understands quite a lot of parameters.
Here are the parameters which are global and not part of a per-frame
block:
- -l-fjump=NUM (also: -l-j)
-
Only process every NUMth frame, use negative values to process
last frames first. [FIXME: MORE INFO]
Default: +1
- -l-nframes=NUM (also: -l-n)
-
Specify the number of frames to be rendered. If not specified, this is
autodetected: In case -l-fjump is positive, RendView
simply processes frames until three frame input files in sequence do
not exist. If -l-fjump is negative, the task source
checks the input file existence and stops at the first non-existing
frame file; the previous file is then considered the last file.
You may supply a value of 0 if you just want to get all the verbose
output dumping startup info. The LDR server will connect to at least
one client and then disconnect immediately.
- -l-startframe=NUM (also: -l-f0)
-
Start with frame numbered NUM instead of frame 0.
- -l-cont
-
Switch on continuing. This means that frames are only rendered/filtered
if needed based on modification timestamp (source/input versus
destination/output file). The additional files are all treated
as "source files" and therefore also checked when deciding whether
to re-render/filter a frame (unless disabled, see
-l-add-check-mtime below).
See also the info above.
Default: disabled.
- -l-add-check-mtime (also: -l-acmt)
-
If disabled (-no-l-add-check-mtime), RendView will
not check the modification time of additional files when
deciding whether to re-render/filter a frame.
Meaningless if -l-cont is not set.
Default: enabled
- -l-response-delay=MSEC
-
This is something like -schedule-delay and tells the
local task source to not answer any request faster than MSEC
milliseconds. This is mainly useful in debugging.
Default: 0, of course.
The following parameters can be specified on a per-frame basis, i.e.
using per-frame blocks. As mentioned above, there exists a master
per-frame block whose parameters can be set using e.g. -l-rd
or -l-size. The parameters of a per-frame block
which shall only apply to several frames (as opposed to the master) is
specified using e.g. -l-3:8-rd or
-l-3:8-size which means that this per-frame block begins
at frame 3 and is 8 frames long.
- -l-size=WWWxHHH (also: -l-s)
-
Size of the rendered frame (and thus normally also of the filtered frame
but that is not necessary).
Default: -l-size=320x240
- -l-oformat=SPEC
-
Render output image format. Use -list-imgfmt to get a
list of known image formats. You may only specify formats which are
known to the used renderer and render driver.
Default is PNG (8 bits per color channel).
- -l-renderer, -l-filter=DESC_NAME (also: -l-rd, -l-fd)
-
Specify the render/filter desc to use. You may use the special value
none to switch off rendering/filtering of the frames in
question.
Default: none
- -l-rcont
-
Enable render resume operation (if the renderer supports it like POVRay
does). This means that unfinished frames can be resumed. See above
for more info.
Note: This option requires -l-cont in order to work.
You can use -no-l-cont to explicitly switch it off.
Default: enabled if the renderer supports it.
- -l-r-args, -l-f-args=ARGS
-
Space-separated list of additional command line args to be
passed to the render/filter process.
Use quotes (") if you need to pass args with spaces or protect the spaces
with a backslash. If you want to include quotes or backslashes, you
need to protect those using a backslash, too. Also note that the shell
tends to interprete such characters, so best put all the option
in single quotes (which get removed by the shell).
- -l-r-files, -l-f-files=FILES
-
Space-separated list of additional files needed for the rendering or
filtering. This is not needed for plain RendView operation but probably
for LDR because these additional files probably have to be transferred
to the client.
Path is relative to RendView's CWD (current working directory).
Please read the notes about the flat directory structure
(above) as well as the current limitation (no file may appear in
both -l-r-files as well as -l-f-files).
- -l-r-timeout, -l-f-timeout=SEC
-
Specify a render/filter timeout, i.e. the time limit for the render
and filter process to finish. You can pass a similar timeout using
the task driver interface (e.g. -ld-r-timeout) and
the shorter of the two timeouts will take effect.
Use a value of -1 to disable.
Default: no timeout (disabled)
- -l-r-frameclock (also: -l-r-fc)
-
Switch on/off (using -l-r-fc/-no-l-r-fc)
use of the frame clock value as supported by POVRay (POVRay's native
animation support using POVRay options +SFFRAME and
+EFFRAME to select the frame to render).
NOTE: How it is meant to work:
If you do not use the frame clock, disable this option (default).
You may pass any +Kxy options to POVRay (as additional
args or in an .ini file) without effect because RendView
automatically appends +KFI0 +KFF0 at the end of the command
line to make sure that the frame clock is disabled.
If you do use the frame clock, enable this option. Make sure to
pass correct values for +KFI, +KFF, KI, KF either using
additional args (-l-r-args) or by using an
.ini file (see -l-r-ifpattern below). RendView
will then simply pass the frame number of the frame being rendered
using +SFFRAME +EFFRAME so that
POVRay will automatically calculate the correct clock value from the
SF/EF option and the K-options provided by the user.
RendView will automatically pass +KFI0 as first cmd line arg
because RendView defaults to begin animations at frame 0 (you can
override that using .ini file settings or additional args for
POVRay.
See also -l-r-ifpattern below.
Default: disabled.
Example on the quickstart page.
The frame clock support works the way as described above sinve
version 0.7.0. The options -l-r-fcstart and
-l-r-fcstep (-l-fc0, -l-fcdt) as provided
by earlier versions were dropped in favour of this more flexible
and easier to use solution.
- -l-r-dir=DIR
-
This tells RendView in ocal operation to change into this
directory before calling the renderer.
Therefore, -l-r-ifpattern and -l-r-ofpattern
(see below) are considered relative to DIR.
Default: current directory.
- -l-f-dir=DIR
-
RendView will change into this directory before executing a filter
program. Hence, -l-f-ofpattern (see below) is considered
relative to -l-f-dir.
Default: current directory.
- -l-r-ifpattern, -l-r-ofpattern, -l-f-ofpattern=PAT
-
Render frame input, render frame output and filter frame output
patterns, respectively. Note that the render frame output pattern is
automatically the filter frame input pattern and hence only one
option is provided.
PAT is a frame pattern, i.e. essentially a file name
with a %d-spec to be replaced by the frame number.
The path is relative to the job's working dir (i.e.
relative to -l-r-dir for -l-r-ifpattern and
-l-r-ofpattern as well as to -l-f-dir for
-l-f-ofpattern).
The -l-r-ifpattern does not have to contain a
%d-spec (e.g. if you are animating using the frame clock);
the other two options must include a %d-spec.
The %d-spec follows standard printf(3) rules, you
may use:
%d to get decimal formatting
%x to have the frame number formatted hexadecimal
%X for hex with capital letters
%03d (for example) to get 000,001,002,003, etc.
(i.e. 3 digits with leading zero)
Note: The render input frame pattern needs an extension (like
.pov); the output patterns get one added automatically
depending on the output image format (-l-oformat, see
above).
Example: -l-f-ofpattern=frame-%03d-filtered
Default: -l-r-ifpattern=f%07d.pov
The render output pattern defaults to the render input pattern with the
extension removed and replaced by the image format's extension (as well
as an added frame number %d-spec in case the input pattern
lacks such a apec).
The filter output pattern defaults to the render output pattern with
a -f added before the file name extension (meaning "filtered").
POVRay note: Using POVRay, you may also pass an .ini file
as frame pattern (with %d-spec or without when using the frame
clock). If the input file name ends in ".ini", the POVRay driver
passes it to POVRay without the +I prefix and POVRay will read
it as ini file. Make sure to add a +IFILE in the
.ini to tell POVRay about the input file and pass
the FILE as additional file using -l-r-files.
Example on the quickstart page.
The LDR client
Finally, some more words about the LDR client. As mentioned before,
LDR is a client server system with the rules swapped in some way:
The LDR client runs on all computers which shall do the actual
rendering/filtering and listen on some port. The LDR server gets
launched by you if you have work to be done, and connects to all
the clients in order to supply the tasks, required files and get
success/failure info and processed frames back. When all tasks are
done, client and server disconnect and the client waits again (after
"recovery") for a server connection in order to begin a new
work cycle. (The work cycle count is transferred to the server
upon connect and can be read in verbose output together with the
current load of the client box.)
Only one server can connect to a client at any time. The
data link between client and server is exactly one TCP/IP
connection.
All data, tasks, requests and responses go over this single connection
which is driven in full duplex mode (i.e. the client can download
a file and then receive a new task while simultaniously uploading a
different file). This sort of "pipelining" made the LDR client and
server harder to implement.
There is no way for the LDR client to disconnect from the server
while it is working because both the client and the server must
be able to send data (commands, info) to each other at any time
during work.
Of course, there are various timeouts, especially on the server side
as well as on the client side (see taskmanager
and below) which make sure that dead clients / servers are detected.
The server can also try to re-connect to lost clients.
This requires some sort of authentication on the client side.
Otherwise, anybody could use an LDR server and connect to your clients
letting them to his work. The auth works as follows: You may specify a
password when starting the LDR client. Only servers which know the
password are allowed to connect to the client. (Hence, you also have
to specify the password when starting the server.)
As no encryption is used for the LDR connection (unnecessary
overhead), a challenge-response authentication applying the
SHA (hash) algorithm: The client reads some challenge data from
/dev/urandom (or, if /dev/urandom is not available,
produces the challenge data using a time-seeded standard PRNG which
may be insecure!) and sends it to server. The server computes the
SHA hash value of the challenge and the password and sends it back as
response. The client compares the response with the expected response
and rejects the server if they do not match.
Furthermore there is an address-based authentication:
The client will only allow servers which connect from one of the allowed
networks (IP addresses; parameter -L-servernet).
The client has to download all the files required by the
actual rendering/filtering. Hence, you must tell the (local) task source
on the server side about all required files. Of course, the main frame
input file is needed but you may specify any number of
additional files (using -l-r-files and
-l-f-files). The client will normally only download the
additional files once and even keep them between several
work cycles. However, it will download files again if they change their
time stamp (i.e. if the modification time on the server is newer than
the modification time of the copy on the client side) or file size
so that it keeps up to date while at the same time
saving network bandwidth. You can control that using
-L-r-delin and similar options (below).
Note that this does not require that the time on all computers
is synchronisized: RendView is doing automatic client/server time
correction by calculating the maximum time difference upon connect
(watch verbose output) and applies the difference to timestamp
tests (unless disabled via -no-L-time-correction).
Note that resume operation also works with LDR, which means that
incompletely rendered frames are down- and uploaded if you specify
render resume (-l-cont -l-rcont).
Please note that the LDR client uses a flat directory structure
which means that all files are put into the same directory. This also
means that you have to design your frame input files (frame00.pov,
scene.pov) in a way that they cope with this situation. (Due to
POVRay's include path this is normally no problem.) The reason for this
is that I consider it too dangerous to let the server specify
directories as well as file names. If people desperately need that feature,
I may consider implementing it.
Please also note a current limitation: An additional render file
(additional file used for rendering, e.g. heightfield_data.png)
cannot be an additional filter file and vice versa. If you really need
the same additional file for rendering and filtering, use a symlink.
Unfortunately, they will then be transferred twice.
Running the LDR client in shared directories (like NFS)
RendView's LDR client, by default, will transfer all required files using
the internal data transfer as implemented in LDR. RendView uses time stamp
and file size checks to determine if a file has to be downloaded.
However, when using several LDR clients on different computers on an NFS
shared volume, this is not what you want because RendView will then
(by default) attempt to overwrite the files with themselves leading to
trouble (this is because exactly matching time stamps on client and
server trigger downloading the file once by default).
So, when using shared directories (even when running an LDR client on the
same box as the LDR server and from the same directory) requires passing
some extra option: -L-transfer=all- (and don't forget
the dash at the end!)
As LDR uses a flat directory structure (for security reasons), this
requires the shared directory to provide just that flat dir structure as
expected by the LDR client (i.e. put all files into the same
(shared) directory and start the LDR client from within this directory).
Of course, you can use a heterogenous setup with 15 clients sharing an
NFS volume with the server and further 10 clients using LDR to transfer
all files (-L-transfer=all+ [default] for those).
Note: I am unsure if race conditions can make your life uneasy
when using NFS.
Parameters understood by the LDR task source
- -L-port=NUM
-
Specifies the port the LDR client listens at.
Default: 3104
- -L-password=PASS
-
Set the client password. PASS can either be a the actual
password string or one of the following special values:
none: use no password (insecure); same as if you do
not specify one
prompt: asks you to enter a password upon start using
getpass(3)
file:PATH: read password from file PATH
No more than 128 bytes will be read; falls back to prompt
if an error occurs or the file is empty.
Please also read the note about passwords in the
taskmanager chapter.
- -L-servernet=SNET
-
This specifies a list of IPv4 addresses (client addresses or network
addresses). If specified, only servers which match one of the addresses
are allowed to connect. SNET is a list of space-separated
server nets. A server net spec is either simply an address or host
name (e.g. localhost or 127.0.0.1) or an
address or host name with a network bit spec
(e.g. localhost/8, 192.168.0.1/24).
Normally, a network address has all the less significant bits set to
0 (e.g. the last 8 ones when using "/24"). If that is not the case,
a warning is written and the corresponding network address is used.
Hence, it is possible to write myhost/24 if you want to
allow all clients in the locat 8 bit subnet in which myhost
is.
If you do not specify a server net, any source address is accepted
(default).
- -L-wdir=DIR
-
This option tells the LDR client to create the directory DIR
and change into it upon startup.
All the temporary files will be placed in that directory and the
renderer/filter will be launched with it as cwd.
If you do not specify DIR, then RendView will create one
itself with the name /tmp/ldrclient-pid
(with pid being the PID of the LDR client process).
RendView will automatically delete the directory when exiting.
By default, this feature is swiched off and the current directory is used.
- -L-kamult=NUM
-
The server sends ping control commands to the client in some time
interval (see -Ld-keepalive in
taskmanager docu).
The time interval is transferred from the server to the client upon
connect, so the client knows that it has to expect a ping every
-Ld-keepalive seconds. Consequently, the client
will consider the server as dead when no ping arrives within
-Ld-keepalive multiplied with NUM divided
by&nsbp;10. E.g. if the keepalive time is 30 seconds and
NUM is 25, then the client will expect pings every
30*25/10=75 seconds.
Using values below 10 does not make sense.
Use -1 to disable this feature which is not recommended because the
client will then not be able to detect when the server goes dead.
The default is 25.
- -L-atimeout=MSEC
-
This is the client-side analogon to -Ld-ctimeout and
specifies the maximum time for the complete authentication to pass
(i.e. from initial connection until auth is done).
Use a value of -1 to disable (not recommended).
The default is 10 seconds.
- -r-delin, -r-delout, -r-deladd, -f-delin, -f-delout, -f-deladd=SPEC
-
Specify when the (temporary) render input, render output and additional
files needed for rendering, as well as all that for filtering, which were
downloaded, should be deleted. These files are downloaded from the LDR
server and held on the hard disk by the LDR client in order to execute
tasks. Obviously, these files are only needed temporarily and should be
removed after some time. These options give you control over that.
Possible values for SPEC are:
frame: delete when the frame was processed
cycle: delete at work cycle end (i.e. disconnect from
server)
exit: delete when exiting
never: never delete
Any abbreviation of SPEC is allowed.
Note: All the files are only deleted when they are no longer used
(independent of what you specify).
If you specify that an additional render file should be deleted on
frame basis and the client currently has more than one
frame which uses this file, then it is not deleted before all these
frames were completely processed.
Hence, the additional file will not be deleted and downloaded again
for each frame. Note also that the latter would introduce trouble when
more than one process is lauched: If RendView deleted and re-downloaded
the file, one process may want to read it at the same time and thus
fail.
Furthermore, only downloaded files are ever deleted.
The defaults are:
-r-delin, -r-delout: frame
-r-deladd: exit
And the same for the files needed for filter tasks. This means, by default
additional files are kept across work cycles which normally does not
pose a problem because they are automatically downloaded again when
the modification time on the server side is newer than on the client
side or file size changed.
NOTE however, that this means that additional files accumulate on the
client side. Hence, if you remove an additional file on the server side,
it will still be present on the client side and can be accessed.
- -L-re-download
-
If enabled, download files again if the time stamp test says so even
if the modification time stamp reported by the server did not change
in the meantime. Disabling this prevents RendView from loading down
more than once a file which was just modified.
Default: disabled, of course! (-no-L-re-download)
- -L-always-download-input (also: -L-adli)
-
If enabled, always download primary render/filter input file. Normally,
RendView does timestamp and size checks on these files, too, so if they
are already present, they are not overwritten.
The main reason for this option is that when using the frame clock, the
same primary render input file may be used for several frames and hence,
it makes sense to apply timestamp checks.
Note that when resuming, unfinished render output files are
always transferred, irrespective of this option.
Note that on an NFS volume you have to use -L-transfer
(instead of this option; see below) to walk around possible problems with
file versus system time over NFS.
Default: disabled (-no-L-adli)
- -L-time-correction
-
The LDR client only downloads files again which are already present when
their file size changes or if the modification time on the client is
older than on the server. This, however requires synchronisized system
times or some means to compensate the difference.
RendView automatically calculates the (worst case) time difference
between client and server upon connect and applies this time
difference for modification time checks (unless you disable it using
-no-L-time-correction).
If really needed, you can switch that off and fall
back to -L-timestamp-thresh (see below).
Default: enabled
- -L-timestamp-thresh=MSEC
-
By default, RendView automatically compensates the difference between
client and server time (see -L-time-correction).
This parameter can be used to (additionally) hand-tune the timestamp check.
Positive values optimize the test ("less files get transterred") because
the timestamp thresh gets added to the local file modification time before
it is compared to the modification time of the file on the server side.
It's probably better to relay on automatic time correction. You may
need this in special cases (maybe with NFS).
The default value is 1 msec if -L-time-correction is
enabled, otherwise 3001, i.e. 3 seconds.
- -L-transfer=SPEC
-
You can use this to specify which files should be transferred to the LDR
client (more precisely: this specifies which files the client will download
from the server). The default is all required files and you should be
careful when changing that.
You should use -L-transfer=all- when sharing the working
directory between the server and this client using e.g. NFS so that no
files get transferred. See also the note above.
SPEC is a concatenated list of tags, each with a postfix
"+" or "-", e.g. a+rs-rd-fd-
The allowed tags are:
rs, rd, ra:
render source, dest and additional files, respectively
fd, fa:
filter dest and additional files, respectively
d: all destination files
a: all additional files
all: all files
The SPEC is parsed left-to-right and tags more to the right
override those earlier in the spec string.
The default is -L-transfer=all+