| 1 |
.\" RCSid "$Id: arch2rad.1,v 1.2 2003/12/09 15:59:06 greg Exp $" |
| 2 |
.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) |
