| 1 |
greg |
1.3 |
.\" RCSid "$Id: arch2rad.1,v 1.2 2003/12/09 15:59:06 greg Exp $"
|
| 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 |
greg |
1.3 |
arch2rad \-n building.txt > building.qual
|
| 156 |
greg |
1.1 |
.PP
|
| 157 |
|
|
To translate building.txt into a RADIANCE file using the mapping
|
| 158 |
|
|
building.map:
|
| 159 |
|
|
.IP "" .2i
|
| 160 |
greg |
1.3 |
arch2rad \-m building.map building.txt > building.rad
|
| 161 |
greg |
1.1 |
.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)
|