15 |
|
][ |
16 |
|
.B "\-b binv" |
17 |
|
] |
18 |
+ |
.B "\-m mod .." |
19 |
|
[ |
20 |
|
.B $EVAR |
21 |
|
] |
25 |
|
[ |
26 |
|
rtrace options |
27 |
|
] |
27 |
– |
.B "\-m mod .." |
28 |
|
.B octree |
29 |
|
.SH DESCRIPTION |
30 |
|
.I Rtcontrib |
32 |
|
for objects whose modifiers are named in one or more |
33 |
|
.I \-m |
34 |
|
settings. |
35 |
< |
These modifiers are usually materials associated with specific |
36 |
< |
light sources, though they could correspond to intermediate objects as well. |
37 |
< |
The resulting contributions may then be used in linear combination to |
35 |
> |
These modifiers are usually materials associated with |
36 |
> |
light sources or sky domes, and must directly modify some geometric |
37 |
> |
primitives to be considered in the output. |
38 |
> |
The computed contributions can then be used in linear combination to |
39 |
|
reproduce any desired variation, e.g., simulating lighting controls or |
40 |
|
changing sky conditions via daylight coefficients. |
41 |
|
More generally, |
42 |
|
.I rtcontrib |
43 |
< |
can compute general input-output relationships in optical |
43 |
> |
may be used to compute input-output relationships in optical |
44 |
|
systems, such as light pipes and shading devices. |
45 |
|
.PP |
46 |
< |
.I Rtrace(1) |
47 |
< |
is called to calculate the contributions for each input ray, |
46 |
> |
.I Rtcontrib |
47 |
> |
calls |
48 |
> |
.I rtrace(1) |
49 |
> |
to calculate the contributions for each input ray, |
50 |
|
and the output tallies are sent to one or more files according to the |
51 |
|
.I \-o |
52 |
|
specification. |
53 |
< |
If the output file specification contains a "%s" format, this will be |
53 |
> |
If an output specification contains a "%s" format, this will be |
54 |
|
replaced by the modifier name. |
55 |
|
The |
56 |
|
.I \-b |
57 |
|
option may be used to further define |
58 |
< |
a "bin number" within each object if finer resolution is desired, and |
59 |
< |
will be applied to a "%d" format in the output file |
58 |
> |
a "bin number" within each object if finer resolution is needed, and |
59 |
> |
this will be applied to a "%d" format in the output file |
60 |
|
specification if present. |
61 |
|
(The actual bin number is computed at run time based on ray direction |
62 |
|
and surface intersection, as described below.)\0 |
64 |
|
.I \-b |
65 |
|
and |
66 |
|
.I \-o |
67 |
< |
options (to the left) of each |
67 |
> |
options to the left of each |
68 |
|
.I \-m |
69 |
< |
setting affect only that modifier, and the ordering |
70 |
< |
of other options is unimportant. |
69 |
> |
setting affect only that modifier. |
70 |
> |
(The ordering of other options is unimportant.)\0 |
71 |
|
.PP |
72 |
< |
Input and output format defaults to plain text, where each ray's |
73 |
< |
origin and direction (6 real values) must appear together per |
74 |
< |
line of input, and one line of output is produced per output file |
75 |
< |
file per ray. |
76 |
< |
Alternative input and output formats may be specified using the |
77 |
< |
.I \-f[io] |
78 |
< |
option, which is explained in the |
79 |
< |
.I rtrace |
80 |
< |
man page along with the associated |
81 |
< |
.I \-x |
82 |
< |
and |
83 |
< |
.I \-y |
84 |
< |
resolution settings. |
85 |
< |
In particular, the 'c' output setting |
86 |
< |
together with positive dimensions for |
87 |
< |
.I \-x |
88 |
< |
and |
89 |
< |
.I \-y |
90 |
< |
will produce an uncompressed RADIANCE picture, |
88 |
< |
suitable for manipulation with |
89 |
< |
.I pcomb(1) |
90 |
< |
and related tools. |
72 |
> |
If a |
73 |
> |
.I \-b |
74 |
> |
expression is defined for a particular modifier, |
75 |
> |
the bin number will be evaluated at run time for each |
76 |
> |
ray contribution from |
77 |
> |
.I rtrace. |
78 |
> |
Specifically, each ray's world intersection point will be assigned to |
79 |
> |
the variables Px, Py, and Pz, and the normalized ray direction |
80 |
> |
will be assigned to Dx, Dy, and Dz. |
81 |
> |
These parameters may be combined with definitions given in |
82 |
> |
.I \-e |
83 |
> |
options and files read in |
84 |
> |
.I \-f |
85 |
> |
options, to compute the bin, which will be |
86 |
> |
rounded to the nearest whole number. |
87 |
> |
This mechanism allows the user to define precise regions or directions |
88 |
> |
they wish to accumulate, such as the Tregenza sky discretization, |
89 |
> |
which would be otherwise impossible to specify |
90 |
> |
as a set of RADIANCE primitives. |
91 |
|
.PP |
92 |
|
If no |
93 |
|
.I \-o |
94 |
|
specification is given, results are written on the standard output in order |
95 |
|
of modifier (as given on the command line) then bin number. |
96 |
< |
The same format is used for a simple file name specification |
97 |
< |
without any embedded "%s" or "%d" formats. |
96 |
> |
Concatenated data is also sent to a lone output file (i.e., an initial |
97 |
> |
.I \-o |
98 |
> |
specification without formatting strings). |
99 |
|
If a "%s" format appears but no "%d" in the |
100 |
|
.I \-o |
101 |
|
specification, then each modifier will have its own output file, with |
109 |
|
For binary output formats, there is no such delimiter to mark |
110 |
|
the end of each record. |
111 |
|
.PP |
112 |
< |
If a |
113 |
< |
.I \-b |
114 |
< |
expression is defined for a particular modifier, |
115 |
< |
the bin number will be evaluated at run time for each |
116 |
< |
ray contribution from |
117 |
< |
.I rtrace. |
118 |
< |
Specifically, each ray's world intersection point will be assigned to |
119 |
< |
the variables Px, Py, and Pz, and the normalized ray direction |
120 |
< |
will be assigned to Dx, Dy, and Dz. |
121 |
< |
These ray parameters may be combined with any definitions given in |
122 |
< |
.I \-e |
123 |
< |
options, or any files read in from |
124 |
< |
.I \-f |
125 |
< |
options, to compute the bin, which will be |
126 |
< |
rounded to the closest whole number. |
127 |
< |
This mechanism allows the user to define precise regions (or directions) |
128 |
< |
they wish to accumulate, such as the Tregenza sky grid, which would be |
129 |
< |
otherwise impossible to specify as a set of RADIANCE primitives. |
112 |
> |
Input and output format defaults to plain text, where each ray's |
113 |
> |
origin and direction (6 real values) are given on input, |
114 |
> |
and one line is produced per output file per ray. |
115 |
> |
Alternative data representations may be specified by the |
116 |
> |
.I \-f[io] |
117 |
> |
option, which is described in the |
118 |
> |
.I rtrace |
119 |
> |
man page along with the associated |
120 |
> |
.I \-x |
121 |
> |
and |
122 |
> |
.I \-y |
123 |
> |
resolution settings. |
124 |
> |
In particular, the color ('c') output data representation |
125 |
> |
together with positive dimensions for |
126 |
> |
.I \-x |
127 |
> |
and |
128 |
> |
.I \-y |
129 |
> |
will produce an uncompressed RADIANCE picture, |
130 |
> |
suitable for manipulation with |
131 |
> |
.I pcomb(1) |
132 |
> |
and related tools. |
133 |
|
.PP |
134 |
|
If the |
135 |
|
.I \-n |
136 |
|
option is specified with a value greater than 1, multiple |
137 |
< |
.I rtrace(1) |
137 |
> |
.I rtrace |
138 |
|
processes will be used to accelerate computation on a shared |
139 |
|
memory machine. |
140 |
|
Note that there is no benefit to using more processes |
141 |
< |
than there are local CPUs available to do the work. |
141 |
> |
than there are local CPUs available to do the work, and the |
142 |
> |
.I rtcontrib |
143 |
> |
process itself may use a considerable amount of CPU time. |
144 |
|
.PP |
145 |
|
Options may be given on the command line and/or read from the |
146 |
|
environment and/or read from a file. |
148 |
|
replaced by the contents of the given environment variable. |
149 |
|
A command argument beginning with an at sign ('@') is immediately |
150 |
|
replaced by the contents of the given file. |
151 |
< |
.SH EXAMPLE |
152 |
< |
First |
153 |
< |
.I rpiece |
148 |
< |
process is started on the machine "goober": |
151 |
> |
.SH EXAMPLES |
152 |
> |
To compute the proportional contributions from sources modified |
153 |
> |
by "light1" vs. "light2" on a set of illuminance values: |
154 |
|
.IP "" .2i |
155 |
< |
goober% echo 1 8 > syncfile |
151 |
< |
.br |
152 |
< |
goober% echo -F syncfile -x 1024 -y 1024 -vf view -o picture octree > args |
153 |
< |
.br |
154 |
< |
goober% rpiece @args & |
155 |
> |
rtcontrib -I+ @render.opt -o c_%s.dat -m light1 -m light2 scene.oct < test.dat |
156 |
|
.PP |
157 |
< |
Second |
158 |
< |
.I rpiece |
158 |
< |
processes is started on the machine "sucker": |
157 |
> |
To generate a pair of images corresponding to these two lights' |
158 |
> |
contributions: |
159 |
|
.IP "" .2i |
160 |
< |
sucker% rpiece @args & |
161 |
< |
.SH NOTES |
162 |
< |
Due to NFS file buffering, the network lock manager is employed to |
163 |
< |
guarantee consistency in the output file even though non-overlapping |
164 |
< |
writes are used. |
165 |
< |
This would tend to slow the process down if |
166 |
< |
.I rpiece |
167 |
< |
were to wait for this I/O to complete before starting on the next |
168 |
< |
piece, so |
169 |
< |
.I rpiece |
170 |
< |
forks separate processes to hang around waiting for I/O completion. |
171 |
< |
The number of processes thus designated is set by the MAXFORK macro |
172 |
< |
in the program (compiled in the src/util directory). |
173 |
< |
If the fork call is slow on a system, it may actually be better to |
174 |
< |
set MAXFORK to zero. |
175 |
< |
In other cases, the network lock manager may be so slow that this |
176 |
< |
value should be increased to get the best utilization. |
160 |
> |
vwrays -ff -x 1024 -y 1024 -vf best.vf | |
161 |
> |
rtcontrib -ffc `vwrays -d -x 1024 -y 1024 -vf best.vf` |
162 |
> |
@render.opt -o c_%s.pic -m light1 -m light2 scene.oct |
163 |
|
.PP |
164 |
< |
The output picture is not run-length encoded, and can be quite |
165 |
< |
large. |
180 |
< |
The approximate size (in kilobytes) can be computed by the simple |
181 |
< |
formula: |
164 |
> |
These images may then be recombined using the desired outputs |
165 |
> |
of light1 and light2: |
166 |
|
.IP "" .2i |
167 |
< |
filesize = xres*yres/256 |
167 |
> |
pcomb -c 100 90 75 c_light1.pic -c 50 55 57 c_light2.pic > combined.pic |
168 |
|
.PP |
169 |
< |
Make sure that there is enough space on the filesystem to hold the |
170 |
< |
entire picture before beginning. |
171 |
< |
Once the picture is finished, the |
172 |
< |
.I ra_rgbe(1) |
189 |
< |
program with the -r option may be used to convert to a run-length |
190 |
< |
encoded picture for more efficient storage, although |
191 |
< |
.I pfilt(1) |
192 |
< |
or any of the other Radiance picture filters will do the same |
193 |
< |
thing. |
194 |
< |
.PP |
195 |
< |
The ALRM signal may be used to gracefully terminate an |
196 |
< |
.I rpiece |
197 |
< |
process after it finishes the current piece. |
198 |
< |
This permits other currently running or subsequently started |
199 |
< |
.I rpiece |
200 |
< |
process(es) to continue rendering the picture without loss. |
201 |
< |
The |
202 |
< |
.I \-T |
203 |
< |
option will send the ALRM signal to |
204 |
< |
.I rpiece |
205 |
< |
after the specified number of (decimal) hours. |
206 |
< |
This is the best way to force a time limit on the computation, |
207 |
< |
since information will not be lost, though the process may continue |
208 |
< |
for some time afterwards to finish its current piece. |
209 |
< |
.SH BUGS |
210 |
< |
This program may not work on some systems whose NFS lock manager is |
211 |
< |
unreliable. |
212 |
< |
In particular, some System V derivative UNIX systems often have |
213 |
< |
problems with the network lock manager. |
214 |
< |
If the output is scrambled or rpict aborts with some ambient file |
215 |
< |
related problem, you should just remove the ambient file and go |
216 |
< |
back to normal rendering. |
169 |
> |
To compute an array of illuminance contributions according to a Tregenza sky: |
170 |
> |
.IP "" .2i |
171 |
> |
rtcontrib -b tbin -o sky.dat -m skyglow -b 0 -o ground.dat -m groundglow |
172 |
> |
@render.opt -f tregenza.cal scene.oct < test.dat |
173 |
|
.SH AUTHOR |
174 |
|
Greg Ward |
175 |
|
.SH "SEE ALSO" |