ViewVC Help
View File | Revision Log | Show Annotations | Download File | Root Listing
root/radiance/ray/doc/man/man1/rtcontrib.1
(Generate patch)

Comparing ray/doc/man/man1/rtcontrib.1 (file contents):
Revision 1.1 by greg, Thu May 26 06:55:22 2005 UTC vs.
Revision 1.2 by greg, Thu May 26 18:53:04 2005 UTC

# Line 15 | Line 15 | rtcontrib - compute contributions in a RADIANCE scene
15   ][
16   .B "\-b binv"
17   ]
18 + .B "\-m mod .."
19   [
20   .B $EVAR
21   ]
# Line 24 | Line 25 | rtcontrib - compute contributions in a RADIANCE scene
25   [
26   rtrace options
27   ]
27 .B "\-m mod .."
28   .B octree
29   .SH DESCRIPTION
30   .I Rtcontrib
# Line 32 | Line 32 | computes ray contributions (i.e., color coefficients)
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
# Line 61 | Line 64 | The most recent
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
# Line 108 | Line 109 | with a newline at the end of each ray record.
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.
# Line 142 | Line 148 | A command argument beginning with a dollar sign ('$')
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"

Diff Legend

Removed lines
+ Added lines
< Changed lines
> Changed lines