1 |
greg |
1.2 |
.\" RCSid "$Id$" |
2 |
greg |
1.1 |
.TH ARCH2RAD 1 11/15/93 RADIANCE |
3 |
|
|
.SH NAME |
4 |
|
|
arch2rad - convert Architrion text file to RADIANCE description |
5 |
|
|
.SH SYNOPSIS |
6 |
|
|
.B arch2rad |
7 |
|
|
[ |
8 |
|
|
.B \-n |
9 |
|
|
][ |
10 |
|
|
.B "\-m mapfile" |
11 |
|
|
] |
12 |
|
|
[ |
13 |
|
|
.B input |
14 |
|
|
] |
15 |
|
|
.SH DESCRIPTION |
16 |
|
|
.I Arch2rad |
17 |
|
|
converts an Architrion text file to a RADIANCE scene description. |
18 |
|
|
The material names for the surfaces will assigned based on the |
19 |
|
|
default mapping or the mapping rules file given in the |
20 |
|
|
.I \-m |
21 |
|
|
option. |
22 |
|
|
A mapping file contains a list of materials followed by the conditions |
23 |
|
|
a surface must satisfy in order to have that material. |
24 |
|
|
.PP |
25 |
|
|
For example, if we wanted all surfaces for blocks with RefId "thingy" and |
26 |
|
|
Color 152 to use the material "wood", and all other surfaces to use the |
27 |
|
|
material "default", we would create the following mapping file: |
28 |
|
|
.nf |
29 |
|
|
|
30 |
|
|
default ; |
31 |
|
|
wood (RefId "thingy") (Color 152) ; |
32 |
|
|
|
33 |
|
|
.fi |
34 |
|
|
All surfaces would satisfy the first set of conditions (which is empty), |
35 |
|
|
but only the surfaces in blocks with RefId "thingy" |
36 |
|
|
and Color 152 would satisfy the |
37 |
|
|
second set of conditions. |
38 |
|
|
.PP |
39 |
|
|
Each rule can have up to one condition per qualifier, and different |
40 |
|
|
translators use different qualifiers. |
41 |
|
|
In |
42 |
|
|
.I arch2rad, |
43 |
|
|
the valid qualifiers are |
44 |
|
|
.I "Layer, Color, Face" |
45 |
|
|
and |
46 |
|
|
.I RefId. |
47 |
|
|
A condition is either a single value for a |
48 |
|
|
specific attribute, or an integer range of values. |
49 |
|
|
(Integer ranges are |
50 |
|
|
specified in brackets and separated by a colon, eg. [\-15:27], and are |
51 |
|
|
always inclusive.) A semicolon is used to indicate the end of a rule, |
52 |
|
|
which can extend over several lines if necessary. |
53 |
|
|
.PP |
54 |
|
|
The semantics of the rule are such that "and" is the implied conjunction |
55 |
|
|
between conditions. |
56 |
|
|
Thus, it makes no sense to have more than one |
57 |
|
|
condition in a rule for a given qualifier. |
58 |
|
|
If the user wants the same |
59 |
|
|
material to be used for surfaces that satisfy different conditions, |
60 |
|
|
they simply add more rules. |
61 |
|
|
For example, if the user also wanted |
62 |
|
|
surfaces in blocks with |
63 |
|
|
RefId "yohey" with Colors between 50 and 100 to use "wood", |
64 |
|
|
they would add the following rule to the end of the example above: |
65 |
|
|
.nf |
66 |
|
|
|
67 |
|
|
wood (Color [50:100]) (RefId "yohey") ; |
68 |
|
|
|
69 |
|
|
.fi |
70 |
|
|
Note that the order of conditions in a rule is irrelevant. |
71 |
|
|
However, |
72 |
|
|
the order of rules is very important, since the last rule satisfied |
73 |
|
|
determines which material a surface is assigned. |
74 |
|
|
.PP |
75 |
|
|
By convention, the identifier "void" is used to delete unwanted |
76 |
|
|
surfaces. |
77 |
|
|
A surfaces is also deleted if it fails to match any rule. |
78 |
|
|
Void is used in a rule as any other material, but it has the |
79 |
|
|
effect of excluding all matching surfaces from the translator output. |
80 |
|
|
For example, the following mapping would delete all surfaces in the |
81 |
|
|
Layer 2 except those with the color "beige", to which it would assign |
82 |
|
|
the material "beige_cloth", and all other surfaces would be "tacky": |
83 |
|
|
.nf |
84 |
|
|
|
85 |
|
|
tacky ; |
86 |
|
|
void (Layer 2) ; |
87 |
|
|
beige_cloth (Layer 2) (Color "beige") ; |
88 |
|
|
|
89 |
|
|
.fi |
90 |
|
|
.PP |
91 |
|
|
If neither the |
92 |
|
|
.I \-m |
93 |
|
|
nor the |
94 |
|
|
.I \-n |
95 |
|
|
options are not used, |
96 |
|
|
.I arch2rad |
97 |
|
|
uses the default mapping file "/usr/local/lib/ray/lib/arch.map". |
98 |
|
|
This file simply assigns materials based on color, using the |
99 |
|
|
identifiers "c0" through "c255". |
100 |
|
|
Appropriate materials for these identifiers are contained |
101 |
|
|
in "/usr/local/lib/ray/lib/arch.mat". |
102 |
|
|
.PP |
103 |
|
|
The |
104 |
|
|
.I \-n |
105 |
|
|
option may be used to produce a list of qualifiers from which to construct |
106 |
|
|
a mapping for the given Architrion file. |
107 |
|
|
If the |
108 |
|
|
.I \-m |
109 |
|
|
option is used also, only those blocks matched in the mapping file |
110 |
|
|
will be added to the qualifier list. |
111 |
|
|
.SH DETAILS |
112 |
|
|
Architrion blocks are divided into about 6 polygons. |
113 |
|
|
The reference, opposite and end faces must all be quadrilaterals (ie. |
114 |
|
|
four-sided polygons), |
115 |
|
|
though one or more faces may disappear in certain degenerate cases. |
116 |
|
|
The bottom face will usually be a quadrilateral, though it may be |
117 |
|
|
written out as two triangles if the face is non-planar or one triangle |
118 |
|
|
if there is a degenerate side. |
119 |
|
|
The top face is treated the same as the bottom face. |
120 |
|
|
.PP |
121 |
|
|
Openings are currently handled using the antimatter material type. |
122 |
|
|
An antimatter material called "opening" is defined that "clips" all |
123 |
|
|
faces for the current block, and patches the edges of the hole with |
124 |
|
|
the material defined for the face "sill". |
125 |
|
|
If no rule is given specifically for the sill face, then the most |
126 |
|
|
specific material (ie. the material in the latest rule) |
127 |
|
|
for this block is used. |
128 |
|
|
An antimatter opening will not function properly if there is another |
129 |
|
|
surface intersecting it, or rendering is attempted from within the |
130 |
|
|
opening. |
131 |
|
|
Overlapping openings or openings with shared boundaries will also fail. |
132 |
|
|
There is currently no support of Architrion "frame" libraries. |
133 |
|
|
.PP |
134 |
|
|
Naming of the output faces is based on layer number, reference id |
135 |
|
|
and output block number (sequential from 1 to the total number of |
136 |
|
|
output blocks). |
137 |
|
|
If there is no reference id name, the layer name is used (if available) |
138 |
|
|
instead of the layer number. |
139 |
|
|
If there is a reference id number but no name, that is added as |
140 |
|
|
well. |
141 |
|
|
Names are truncated to the first 12 characters, so the ends of long |
142 |
|
|
names may be lost. |
143 |
|
|
Also, spaces in names are replaced by underscores ('_'). |
144 |
|
|
Finally, the face id is added to the end of the block name for each |
145 |
|
|
output polygon. |
146 |
|
|
An example identifier for a polygon is: |
147 |
|
|
.PP |
148 |
|
|
l3.window_overh.3155.ref |
149 |
|
|
.PP |
150 |
|
|
This would be the reference face of output block number 3155, |
151 |
|
|
reference id name "window overhangs" in layer number 3. |
152 |
|
|
.SH EXAMPLE |
153 |
|
|
To create a qualifier list for building.txt: |
154 |
|
|
.IP "" .2i |
155 |
|
|
arch2rad -n building.txt > building.qual |
156 |
|
|
.PP |
157 |
|
|
To translate building.txt into a RADIANCE file using the mapping |
158 |
|
|
building.map: |
159 |
|
|
.IP "" .2i |
160 |
|
|
arch2rad -m building.map building.txt > building.rad |
161 |
|
|
.PP |
162 |
|
|
To create an octree directly from an Architrion file using the default |
163 |
|
|
mapping and materials: |
164 |
|
|
.IP "" .2i |
165 |
|
|
oconv source.rad /usr/local/lib/ray/lib/arch.mat '\\!arch2rad building.txt' > building.oct |
166 |
|
|
.SH FILES |
167 |
|
|
/usr/local/lib/ray/lib/arch.map |
168 |
|
|
/usr/local/lib/ray/lib/arch.mat |
169 |
|
|
.SH AUTHOR |
170 |
|
|
Greg Ward |
171 |
|
|
.SH "SEE ALSO" |
172 |
|
|
ies2rad(1), oconv(1), thf2rad(1), xform(1) |