1 |
.\" RCSid "$Id: rpiece.1,v 1.3 2007/09/04 17:36:41 greg Exp $" |
2 |
.TH RPIECE 1 10/1/98 RADIANCE |
3 |
.SH NAME |
4 |
rpiece - render pieces of a RADIANCE picture |
5 |
.SH SYNOPSIS |
6 |
.B rpiece |
7 |
[ |
8 |
.B \-v |
9 |
][ |
10 |
.B "\-x xres" |
11 |
][ |
12 |
.B "\-y yres" |
13 |
][ |
14 |
.B "\-X xdiv" |
15 |
][ |
16 |
.B "\-Y ydiv" |
17 |
][ |
18 |
.B "\-F|R syncfile" |
19 |
][ |
20 |
.B "\-T timelim" |
21 |
] |
22 |
[ |
23 |
.B $EVAR |
24 |
] |
25 |
[ |
26 |
.B @file |
27 |
] |
28 |
[ |
29 |
rpict options |
30 |
] |
31 |
.B "\-o picture" |
32 |
.B octree |
33 |
.SH DESCRIPTION |
34 |
.I Rpiece |
35 |
renders a RADIANCE picture a piece at a time, calling |
36 |
.I rpict(1) |
37 |
to do the actual work. |
38 |
This is useful for running multiple |
39 |
.I rpict |
40 |
processes on cooperating machines to render a single picture, |
41 |
which is a shared file specified with the |
42 |
.I \-o |
43 |
option. |
44 |
The overall picture dimensions will be |
45 |
.I xres |
46 |
by |
47 |
.I yres |
48 |
(or smaller, depending on the |
49 |
.I \-pa |
50 |
option and other view options), and the picture will be rendered in |
51 |
.I xdiv |
52 |
by |
53 |
.I ydiv |
54 |
pieces. |
55 |
.PP |
56 |
There are two basic methods for telling |
57 |
.I rpiece |
58 |
which piece(s) of a picture to render. |
59 |
The explicit method is to write on the standard input the |
60 |
.I X |
61 |
and |
62 |
.I Y |
63 |
position of the desired piece(s), where |
64 |
.I X |
65 |
runs from zero to |
66 |
.I xdiv\-\1 |
67 |
and |
68 |
.I Y |
69 |
runs from zero to |
70 |
.I ydiv\-\1. |
71 |
(The lower left piece of a picture corresponds to (0,0) in this |
72 |
system.)\0 |
73 |
Alternatively, the implicit specification method uses a |
74 |
synchronization file to |
75 |
determine which piece is to be rendered next. |
76 |
Specified with the |
77 |
.I \-F |
78 |
option, |
79 |
.I syncfile |
80 |
initially contains the values for |
81 |
.I xdiv |
82 |
and |
83 |
.I ydiv, |
84 |
so the |
85 |
.I \-X |
86 |
and |
87 |
.I \-Y |
88 |
options are unnecessary. |
89 |
(However, they are used if |
90 |
.I syncfile |
91 |
does not exist.)\0 |
92 |
The first |
93 |
.I rpiece |
94 |
process puts a lock on |
95 |
.I syncfile |
96 |
and modifies its contents before |
97 |
starting work on the first piece of the image. |
98 |
It writes the |
99 |
.I X |
100 |
and |
101 |
.I Y |
102 |
position of the piece it will work on, so the next |
103 |
.I rpiece |
104 |
process to modify |
105 |
.I syncfile |
106 |
will start on the next piece. |
107 |
(When it finishes with its piece, it appends the index to the end of |
108 |
.I syncfile.) |
109 |
This procedure continues until all the pieces are done, at which point all |
110 |
of the |
111 |
.I rpiece |
112 |
processes will terminate. |
113 |
.PP |
114 |
The |
115 |
.I \-R |
116 |
option may be used instead of |
117 |
.I \-F |
118 |
if some of the pieces were not properly finished by previous (killed) |
119 |
runs of |
120 |
.I rpiece. |
121 |
This option should be used by at most one |
122 |
.I rpiece |
123 |
process, which must be started first and with |
124 |
.I "no other rpiece processes running" |
125 |
or else it will rerender the same pieces other processes have begun. |
126 |
Once the recover process is started, you may start other |
127 |
.I rpiece |
128 |
processes using the |
129 |
.I \-F |
130 |
option to run simultaneously. |
131 |
If some processes die during execution, leaving one or more half-finished |
132 |
pieces in the picture even though the other processes think the |
133 |
work is done, you may run a single |
134 |
.I rpiece |
135 |
with the |
136 |
.I \-R |
137 |
option by itself to repair the holes. |
138 |
.PP |
139 |
The |
140 |
.I \-v |
141 |
flag switches on verbose mode, where |
142 |
.I rpiece |
143 |
reports to the standard output after each piece begins and |
144 |
after each piece is finished. |
145 |
.PP |
146 |
Options may be given on the command line and/or read from the |
147 |
environment and/or read from a file. |
148 |
A command argument beginning with a dollar sign ('$') is immediately |
149 |
replaced by the contents of the given environment variable. |
150 |
A command argument beginning with an at sign ('@') is immediately |
151 |
replaced by the contents of the given file. |
152 |
.SH EXAMPLE |
153 |
First |
154 |
.I rpiece |
155 |
process is started on the machine "goober": |
156 |
.IP "" .2i |
157 |
goober% echo 1 8 > syncfile |
158 |
.br |
159 |
goober% echo \-F syncfile \-x 1024 \-y 1024 \-vf view \-o picture octree > args |
160 |
.br |
161 |
goober% rpiece @args & |
162 |
.PP |
163 |
Second |
164 |
.I rpiece |
165 |
processes is started on the machine "sucker": |
166 |
.IP "" .2i |
167 |
sucker% rpiece @args & |
168 |
.SH NOTES |
169 |
Due to NFS file buffering, the network lock manager is employed to |
170 |
guarantee consistency in the output file even though non-overlapping |
171 |
writes are used. |
172 |
This would tend to slow the process down if |
173 |
.I rpiece |
174 |
were to wait for this I/O to complete before starting on the next |
175 |
piece, so |
176 |
.I rpiece |
177 |
forks separate processes to hang around waiting for I/O completion. |
178 |
The number of processes thus designated is set by the MAXFORK macro |
179 |
in the program (compiled in the src/util directory). |
180 |
If the fork call is slow on a system, it may actually be better to |
181 |
set MAXFORK to zero. |
182 |
In other cases, the network lock manager may be so slow that this |
183 |
value should be increased to get the best utilization. |
184 |
.PP |
185 |
The output picture is not run-length encoded, and can be quite |
186 |
large. |
187 |
The approximate size (in kilobytes) can be computed by the simple |
188 |
formula: |
189 |
.IP "" .2i |
190 |
filesize = xres*yres/256 |
191 |
.PP |
192 |
Make sure that there is enough space on the filesystem to hold the |
193 |
entire picture before beginning. |
194 |
Once the picture is finished, the |
195 |
.I ra_rgbe(1) |
196 |
program with the \-r option may be used to convert to a run\-length |
197 |
encoded picture for more efficient storage, although |
198 |
.I pfilt(1) |
199 |
or any of the other Radiance picture filters will do the same |
200 |
thing. |
201 |
.PP |
202 |
The ALRM signal may be used to gracefully terminate an |
203 |
.I rpiece |
204 |
process after it finishes the current piece. |
205 |
This permits other currently running or subsequently started |
206 |
.I rpiece |
207 |
process(es) to continue rendering the picture without loss. |
208 |
The |
209 |
.I \-T |
210 |
option will send the ALRM signal to |
211 |
.I rpiece |
212 |
after the specified number of (decimal) hours. |
213 |
This is the best way to force a time limit on the computation, |
214 |
since information will not be lost, though the process may continue |
215 |
for some time afterwards to finish its current piece. |
216 |
.SH BUGS |
217 |
This program may not work on some systems whose NFS lock manager is |
218 |
unreliable. |
219 |
In particular, some System V derivative UNIX systems often have |
220 |
problems with the network lock manager. |
221 |
If the output is scrambled or rpict aborts with some ambient file |
222 |
related problem, you should just remove the ambient file and go |
223 |
back to normal rendering. |
224 |
.SH AUTHOR |
225 |
Greg Ward |
226 |
.SH "SEE ALSO" |
227 |
getinfo(1), pfilt(1), ra_rgbe(1), rpict(1), rtpict(1), ximage(1) |