| 1 |
A general scheme has been defined for writing translators from CAD
|
| 2 |
files to Radiance. This scheme should be used by anyone who writes a
|
| 3 |
new translator, since it is both useful and general.
|
| 4 |
|
| 5 |
One of the biggest problems encountered when importing CAD descriptions
|
| 6 |
to a lighting simulation (or any good rendering program) is assigning
|
| 7 |
materials to the surface geometry. Even if the creator of the model
|
| 8 |
has been careful to make 3d surfaces instead of points and lines, most
|
| 9 |
people don't even think about what a surface is made of until they're
|
| 10 |
all done. At that point, of course, it's too late. Even if the user
|
| 11 |
does give a little thought to materials, most CAD systems only permit
|
| 12 |
the assignment of a color index to each surface, which is a start but
|
| 13 |
far short of the information needed to make a good simulation.
|
| 14 |
|
| 15 |
There are only a few CAD systems that "do the right thing" and allow the
|
| 16 |
user to assign material identifiers to objects and individual surfaces.
|
| 17 |
Such a program, GDS for example, makes writing a translator almost
|
| 18 |
trivial, since the material identifiers can refer back to a library of
|
| 19 |
materials maintained by the user, or even imported from the CAD system.
|
| 20 |
|
| 21 |
Most CAD programs, like AutoCAD or Architrion, don't really use the
|
| 22 |
notion of materials in their models at all. Instead, they
|
| 23 |
differentiate surfaces by layer, color, block name, and so forth, none
|
| 24 |
of which clearly makes sense to use as a material identifier. Even if
|
| 25 |
the user creates a model with an intent to perform lighting
|
| 26 |
simulations, he or she has no way to assign materials directly to the
|
| 27 |
objects in the model.
|
| 28 |
|
| 29 |
The only general solution is to use every available piece of information
|
| 30 |
from the CAD model to assign materials. We can do this by using a set
|
| 31 |
of mapping rules, created somehow by the user. (We are working on
|
| 32 |
a HyperCard interface for selecting materials that should be very nice
|
| 33 |
if we ever finish it.) The mapping rules are an ordered list of
|
| 34 |
materials and the conditions a surface must satisfy in order to have
|
| 35 |
that material.
|
| 36 |
|
| 37 |
For example, if we wanted all surfaces in the Block "thingy" with the
|
| 38 |
Color 152 to use the material "wood", and all other surfaces to use the
|
| 39 |
material "default", we would create the following mapping file:
|
| 40 |
|
| 41 |
default ;
|
| 42 |
wood (Block "thingy") (Color 152) ;
|
| 43 |
|
| 44 |
All surfaces would satisfy the first set of conditions (which is empty),
|
| 45 |
but only the surfaces in Block "thingy" with Color 152 would satisfy the
|
| 46 |
second set of conditions.
|
| 47 |
|
| 48 |
Each rule can have up to one condition per qualifier, and different
|
| 49 |
translators will use different qualifiers. A qualifier is simply an
|
| 50 |
attribute that can be used to distinguish surfaces, such as Color,
|
| 51 |
Layer, Reference ID, etc. A condition is either a single value for a
|
| 52 |
specific attribute, or an integer range of values. (Integer ranges are
|
| 53 |
specified in brackets and separated by a colon, eg. [-15:27], and are
|
| 54 |
always inclusive.) A semicolon is used to indicate the end of a rule,
|
| 55 |
which can extend over several lines if necessary.
|
| 56 |
|
| 57 |
The semantics of the rule are such that "and" is the implied conjunction
|
| 58 |
between conditions. Thus, it makes no sense to have more than one
|
| 59 |
condition in a rule for a given qualifier. If the user wants the same
|
| 60 |
material to be used for surfaces that satisfy different conditions,
|
| 61 |
they simply add more rules. For example, if the user also wanted
|
| 62 |
surfaces in Block "yohey" with Colors between 50 and 100 to use "wood",
|
| 63 |
they would add the following rule to the end of the example above:
|
| 64 |
|
| 65 |
wood (Color [50:100]) (Block "yohey") ;
|
| 66 |
|
| 67 |
Note that the order of conditions in a rule is irrelevant. However,
|
| 68 |
the order of rules is very important, since the last rule satisfied
|
| 69 |
determines which material a surface is assigned.
|
| 70 |
|
| 71 |
By convention, the identifier "void" is used to delete unwanted
|
| 72 |
surfaces. It is used in a rule as any other material, but it has the
|
| 73 |
effect of excluding all matching surfaces from the translator output.
|
| 74 |
For example, the following mapping would delete all surfaces in the
|
| 75 |
Layer 2 except those with the color "beige", to which it would assign
|
| 76 |
the material "beige_cloth", and all other surfaces would be "tacky":
|
| 77 |
|
| 78 |
tacky ;
|
| 79 |
void (Layer 2) ;
|
| 80 |
beige_cloth (Layer 2) (Color "beige") ;
|
| 81 |
|
| 82 |
Hopefully, the meaning of the mapping rules is now clear, so we can
|
| 83 |
discuss ways to help the user create the mapping for a given model.
|
| 84 |
|
| 85 |
A translator should provide at least two basic options. The first
|
| 86 |
option, "-n", simply reads the CAD input file and creates a list of
|
| 87 |
qualifiers and values that can be used to differentiate surfaces in the
|
| 88 |
model. The output of the program with "-n" should be something like:
|
| 89 |
|
| 90 |
filename "Example Input File"
|
| 91 |
filetype "Architrion"
|
| 92 |
qualifier Color begin
|
| 93 |
35
|
| 94 |
[100:110]
|
| 95 |
200
|
| 96 |
end
|
| 97 |
qualifier RefId begin
|
| 98 |
1103
|
| 99 |
[5306:5307]
|
| 100 |
"BIG Things"
|
| 101 |
"little Things"
|
| 102 |
end
|
| 103 |
EOF
|
| 104 |
|
| 105 |
This information can be used either by the user or by a program such as
|
| 106 |
HyperCard to create the rules for assigning materials to surfaces in
|
| 107 |
the file. (The "EOF" is literally there, since HyperCard has trouble
|
| 108 |
detecting the end of file.)
|
| 109 |
|
| 110 |
The second option, "-m mapfile" is used to specify the mapping file to
|
| 111 |
be used by the translator. If no mapfile is provided by the user, the
|
| 112 |
translator should have a standard mapping to assign material names
|
| 113 |
based on some set of default paramters. (For example, arch2rad uses
|
| 114 |
color alone to assign materials "c0" through "c255".) To accompany the
|
| 115 |
default mapping, there should be a default materials file with
|
| 116 |
corresponding definitions. These files should be placed in the
|
| 117 |
Radiance library directory under "lib" (ie. "/usr/local/lib/ray/lib").
|
| 118 |
|
| 119 |
To just look at an Architrion building, a user might issue the following
|
| 120 |
commands:
|
| 121 |
|
| 122 |
oconv '\!gensky 6 15 12' /usr/local/lib/ray/lib/arch.mat \
|
| 123 |
'\!arch2rad model.txt' > model.oct
|
| 124 |
rvu -av 3 3 3 -vp -20 -20 5 -vd 1 1 0 model.oct
|
| 125 |
|
| 126 |
Note that by giving oconv commands instead of input files, no temporary
|
| 127 |
files (other than the octree) are necessary. In a more complete
|
| 128 |
example, the user might first create a qualifier list, then run the
|
| 129 |
HyperCard stack for assigning materials, then convert the model
|
| 130 |
with his own materials file, thus:
|
| 131 |
|
| 132 |
arch2rad -n model.txt > model.qual
|
| 133 |
HyperCard MatPick.stack # creates model.map from model.qual
|
| 134 |
arch2rad -m model.map model.txt > model.rad
|
| 135 |
oconv source.rad materials.rad model.rad > model.oct
|
| 136 |
rvu -vf model.vp model.oct
|
| 137 |
|
| 138 |
To write a new translator, include the "trans.h" file in ray/src/cv and
|
| 139 |
link with trans.o and the standard Radiance library. You will need to
|
| 140 |
define your own list of valid qualifiers and use the following routines
|
| 141 |
from trans.c:
|
| 142 |
|
| 143 |
fgetid(ID *idp; char *dls; FILE *fp)
|
| 144 |
/*
|
| 145 |
* Read an id (either a string or an integer) from fp
|
| 146 |
* up to a character in dls. The delimiter will be discarded.
|
| 147 |
* Return EOF at end of file, 0 otherwise. You should free
|
| 148 |
* the id with the macro doneid(idp).
|
| 149 |
*/
|
| 150 |
|
| 151 |
int
|
| 152 |
findid(IDLIST *ilp; ID *idp; int insert)
|
| 153 |
/*
|
| 154 |
* Find (or insert) idp in the list ilp. Uses binary search
|
| 155 |
* to find (or if insert is true, insert) an id in a sorted id
|
| 156 |
* list. Returns index into ilp->id, or -1 if not found and no
|
| 157 |
* insert.
|
| 158 |
*/
|
| 159 |
|
| 160 |
int
|
| 161 |
idcmp(ID *id1, *id2)
|
| 162 |
/*
|
| 163 |
* Compares two identifiers. Numbers compare less than strings.
|
| 164 |
*/
|
| 165 |
|
| 166 |
write_quals(QLIST *qlp; IDLIST idl[]; FILE *fp)
|
| 167 |
/*
|
| 168 |
* Write out qualifiers in array of id lists idl[] to fp.
|
| 169 |
* The qualifier list qlp is used to determine how many and
|
| 170 |
* what to call the qualifiers.
|
| 171 |
*/
|
| 172 |
|
| 173 |
RULEHD *
|
| 174 |
getmapping(char *file; QLIST *qlp)
|
| 175 |
/*
|
| 176 |
* Read mapping rules from "file" and create a list of rules
|
| 177 |
* in reverse order. Prints various syntax errors using eputs()
|
| 178 |
* and calls quit() if there's a serious problem with the input.
|
| 179 |
*/
|
| 180 |
|
| 181 |
matchid(ID *idp; IDMATCH *idm)
|
| 182 |
/*
|
| 183 |
* Checks to see if idp matches the id or range in idm.
|
| 184 |
*/
|
| 185 |
|
| 186 |
Good luck! I will be happy to answer questions ([email protected]).
|
