Report of the research project

:
MODELING LANGUAGE
FOR BUILDINGS AND BUILDING PRODUCTS,
NODEIT
Part of the :
Building Node II research project.
Carried out by:
OBOM researchgroup,
Chair of Integration of Constructions,
Faculty of Architecture,
Delft University of Technology.
Prof. Ir. J. Brouwer.
Ir. J. Kapteijns.
Ing. J. Bleeker.
Author:
J.P. den Hartog: Student Assistant - Researcher at
OBOM.
Copyright © 1995 - 1997 by OBOM researchgroup,
TU Delft.
ISBN: 90-5269-243-2
2
ABSTRACT.
The NodelT project is a part of the Building Node
research project carried out by the OBOM
researchgroup. The research 's aim is to improve the
use of prefabricated building products, and to
improve the joints between products. The NodelT
project was set up to develop computer software
that supports architects in selecting building
products for their design. It offers product
manufacturers a preview of the environment their
products could be applied in. This report is to
indicate the project's progression since the last
report: NodelT report 2 published by OBOM )1 .
3
4
CONTENTS
Page
Introduction.
7
1 .
The OBOM Protocol.
9
11 .
Introduction to the protocol.
9
1.2.
Four levels of detail.
9
1.3.
Geometrie information.
10
1.4.
Specification of performance.
11
1.4.1.
Traversing of specifications.
12
1.4.2.
Specifications of products.
13
1.5.
Context in a design.
13
2.
The 'Selection Engine Technology'
15
2. 1.
Introduction to the SET.
15
2.2.
Dimension compare.
15
2.2. 1.
Traversing objects in dimension compare.
16
2.3.
Specification compare.
16
2.4.
Knowledge based selection and context
compare.
17
3.
Modelling Buildings and Products.
18
3.1.
Introduction to modelling.
18
3.2 .
Designing a building using the protocol.
18
3.3.
Modelling a product using the protocol
20
3.3.1 . Introduction.
20
3.3. 2.
Differences in aggregation.
21
3.3.3.
Tree traversal.
22
4.
Conclusions.
23
Appendix A: NodelT Help Topics. 25
Appendix B: Used performance specification
attributes. 37
References. 42
5
6
INTRODUCTION.
NodelT is a project from the OBOM researchgroup.
It's aim is to build a prototype utility which helps an
architect in using prefabricated building products in
his design. Today many architects like the idea of
building with products. The two mayor conditions for
using prefabricated products are,
1). up-to-date information on all available products.
2). direct feedback on what problems need to be
solved once a product is chosen.
ad 1) . A designer wants graphical information of
what a certain combination of products will look like,
especially the joints. Furthermore alphanumeric
information is requested on what a product can
perform in terms of heat-insulation, noise-reduction,
load-bearing etc. From an expert-system dealing
with products, it is expected to visualise the
product, represent the performance of products and
represents edges of products.
ad 2). As far as the design feedback, an expert
system will provide in a visualisation of the
composition so far, representation of the
performance levels of the design and representation
of the joints between products.
Another useful feature of an expert system would
be the ability to search for a product in a product
database. By making explicit to the program what
kind of performance one wants for a piece of a
building and also specifying where one wants this , a
range of products that could fit the need of the
building are offered. A closer matching routine
calculates more precise how much the requirements
for the part of the building and a selected product
match.
The OBOM researchgroup developed a prototype
for such an expert-system called 'NodeiT'. Using
the OBOM protocol the system models and
7
8
materialises a design. The building to be designed
is set up as a collection ol boxes. These box es are
abstraction ol chambers, walls, windows, doors and
sheets ol a material. The trick is to start with a set
ol 'ROOM'-objects and work the way down the
detailed level. On the 'LAYER' level all objects
represent sheets or proliles. Objects on the
'LAYER', ' SECTOR' and also on the 'GROUP' level
can be replaced by building products. It wil! be
obvious that replacement ol a GROUP-object
requires a much higher level a prelabrication ol the
product and is much more difficult to calculate than
replacement of a LAYER-object.
NodelT uses an external 'AutoCAD' or 'VRML
viewer ' for visualisation. The design is exported into
an drawing or vrml-world. This provides the
designer with visual leed back on the design.
Picture 1: Room Level
Picture 2: Group Level
Picture 3: Sector Level
Picture 4: Layer Level
1. THE OBOM PROTOCOL.
1. 1. Introduction to the protocol.
The OBOM protocol is a way to describe
buildings. Not as a collection of walls, windows ,
doors with dimensions al ready fixed by the drawing,
but as a set of statements of what to put where.
Designing with the protocol , one specifies what
load-bearing performance a wall should have rather
than dimensioning the wall the instant it enters the
design.
The protocol has been developed during the
Building Node 1 research and has been made more
explicit in the NodelT project. At this point the
protocol is applied to two different fields: the design
of buildings to be, and the building material
industry. The protocol is divided into two types of
information. The first type is the geometrical
information. In it the dimensions, position,
occurrence and status of the product are stated.
The second type is the coll ection of (material)-
properties. The protocol has the same descriptors
for bot h building and building products. Because of
this dual use of the protocol, the information on
both buildings and building products is stored in the
same format. It 's relatively easy to compare a part
of a building with a prefabricated building products.
In other words, the search engine is able to find
bui lding products which are a precise fit for a part of
the building.
1.2. Four Levels
With the OBOM protocol the design of a
building and the description of a product is split up
into four levels. These are 'ROOM' - 'GROUP' -
'SECTOR' - 'LAYER' (picture 1-4). The 'ROOM'-
level being the most abstract, the ' LAYER'-level
bei ng the most detailed. The designer starts with
cr eat ing a set of ROOM's. These rooms are
orthogonal boxes and can represent an actual room
i f ~ the building. The proporti ons the boxes are free
9
Rl
il R1G4=O il
I I I
I I I
I I I
I I I
I I I
I I I
I I I
:-4-1 R1Gl R1G2 : ~
I I I
I I I
I I I
I I I
I I I
I R1G3 I I
LJ r---- -'-i- -- --t-j
L _____ L ___ __ ~
Picture 5: Room to Group
conversion
W - : d ~
I I I I
~ ____ J ~ ~
I I
I I
I I
Picture 6: Group to Sector
convers;on
Picture 7: Sector to Layer
conversion
Picture 8: CCS and LAS
10
for the designer to manipulate.
Once the dimensions are correct , the rooms are
successively translated into multiple GROUP's. A
group represents a wallor a part of a wall. The
position and dimensions of the groups corresponds
with the faces of the parent-room. Each of the six
faces of the box representing the room may be
turned into a wall or floor. Only the width of the wall
or floor must be inserted by the designer. The
position of the new groups can be aligned to
assume the inside, centre or the outside of the
boundary (picture 5) .
The group on its turn will be converted into multiple
SECTOR's. Sectors represent open or closed parts
of a wall or floor. The open sectors can represent a
window, door, pipe conduct, stair opening or any
hole in a wall (picture 6) .
The open and closed sectors can be divided into
sheets. These sheets are called LAYER's. The layer
is the most detailed descriptor of the protocol. A
layer can represent a sheet of bricks, concrete,
wood etc. They can also be thought of as radiators,
cabinets etc. (picture 7) .
The four different levels result in the following
descriptors. A box described as a room can act as
an empty space or a filled space. The boxes on the
group-Ievel can act as wall or floor. The sector-level
distinguishes open and closed parts. The open
parts being windows, doors etc. The closed parts
are parapets, walls etc. The layer-Ievel also has
open and closed parts. The open parts are seen as
the cavity between two layers of material.
1.3. Geometrie Information.
In order to locate each object in the building
and visualise it accordingly, the objects position and
dimensions are stored in the building-database.
The position consists of an 'insertion point' and a
'Iocal axis system' (LAS picture 8) . The insertion
point indicates the origin of the Las. The Las is
used to place an object in a Cartesian Co-ordinate
Picture 9: Specifications
System (CCS). The dimensions consist of an x, y
and z value . The values form a boundary box or
envelope. Wh en visualising the abstract building
this box is drawn in AutoCAD. It will be clear that a
selected product must fit in this box in order to be a
valid replacement of this object.
Products are often offered in a range of dimensions.
This range usually start at a minimum length and
stepwise increases to the maximum length. This
information (min . - step - max.) is stored in the
product-database and can be given for any of the
three axis (x,y,x) . With this option, multiple products
are represented by one entry in the database.
When a product, for example, a prefabricated
facade has a window, the sill-height of the window
wil I of ten vary from e.g. 900, 1000, 1100 to 1200
mmo One product out of a range of dimensions has
again four different occurrences. I norder to keep
the product-database as small as possible, this has
led to a range in the insertion point of an object.
Child objects can have a range of insertion points
and dimensions. This method provides the
possibility of placing a child object on different
positions within the parent object.
1.4. Specification of performance.
Each object on one of the four levels of
detail has attributes describing the object requested
performance. This performance of an building-
object is requested by the designer. A part of the
building must meet certain standards, either
dictated by law, physics, the designer or the
principal. This performance is attached to the
objects in the form of attributes which are cal led
'performance specifications' (picture 9). The
specifications are divided into five parts. These
parts offer valuable information on all parts in
building. Not only are the specifications used for
selecting products, they can also be used by third
party developers to provide their noise-, heat- and
daylight-calculus utilities with data. The five
11
12
different types of specifications are the result of the
Building Node 1 research, as there were ,
Specifications of :
1). 'BEARING' performance (e.g . the maximum
pressure of a material).
2) . ' DIVIDING' performance (e.g. insulation value) .
3). 'CONNECTING' performance (e.g . object
conneets at 'SECTOR' level) .
4). ' FINISHING' performance (e.g. Ral code 1040) .
5) . 'SUPPLYING' performance (e.g. contains pipes,
ducts).
With these specifications it's possible to determine
just which product should be applied where. A full
list of the specifications can be found in appendix
B.
1.4. 1. Traversing of specifications.
The specifications bound to a object on
room-level have astrong relation with the
specification of the group-Ievel objects that are
created from that room-level object. The relation
depends on e.g . the thickness and material of the
group-object. Also, when a room's dimension is
modified in a later stage, the insulation-values for
the walls will also change. This makes absolute
values hard to use. Furthermore, calculating the
insulation value for a window is only possible when
all windows in the room are defined and won't be
changed. These modifications work consistent if a
formula is constructed for each specification on
each part of the building. Then is possible to
change part of the design without affecting the rest
of the building. The parameters used in this formul a
must be weil chosen . The first constraint is that only
information from the building-database or
specifications with absolute values (e.g. Young' s
I_ .. ---t-.. - + - . - . L , , ~
I I I
Picture 10: produets in context
modulus) may be used for the parameters in the
formula. the second constraint is that formulas may
not significantly change if the geometry or
specifications of the parent-object are changed. The
way in which the specifications travel from level to
level is fairly complicated and the formulas used
must be executed with every action. This requires
further research.
1.4.2. Specificatians af Praducts.
Products can of ten be purchased in many
different instances. To model several instances of a
products in one object, the protocol should provide
a range or domain in dimensions and specs. The
correlation between values from different domains
should also be modelled. So when the dimension of
an product changes, so will it's heat-insulation
value. Providing this range in the specifications in
the protocol would be, in this early stage of
development , premature. Much research has to be
done of how the different instances re late to their
performance.
The solution used for NodelT 2 program is to model
every instance of a product as a separate object
(with fixed dimensions en specs) . In this way for
every product there is a database equivalent. The
database's Structured Ouery Language (SOL) is
used for selecting only those products with
dimensions and specs between a given range.
1.5. Context in a design.
Under the context of an object the protocol
defines the environment in which (or the conditions
under which) an object or product is applied. The
context of an object is modelled by two Boolean
attributes. Objects can be used to create an
exterior-interior (IE) separation or an interior-
interior (11) separation. This is represented by the IE
/ II attribute. Objects can also be used to define
space (space enclosure, SE) or only occupy it
(space occupier, SOl . This property is set by the SE
/ SO attribute. The position is the third attribute
13
14
specilying an object 's context. The position
(horizontal, vertical or diagonal) is read Irom the
object's geometrie model inlormation. For the
purpose ol connecting product's, a model ol the
edge is stored in the product database. This
abstract edge is used to check il produets lit
amongst their neighbour products. For more
inlormation on this subject, reler to relerenee 2
(picture 10).
Product
Database
1-
2 -
Picture 11: Data Flow
Bu;ldi ng
Dat abase
R-
G-
\<>------- ~ ~ I
r - X ~
,10
~ r*'-------
Picture 12: Dimensions Compared
2. SELECT/ON ENG/NE TECHNOLOGY (SET).
2. 1. /ntroduction to the SET.
The 'Selection Engine' (SET) is used to search the
product - database for building products that meet
certain criteria. These criteria consist of a vast
amount of information. In order to search the
product database in a consistent order, the SET is
divided into three comparison routines (picture 11) .
The ' Dimension Compare' and the ' Specification
Compare' are already implemented in the SET. The
'Context Compare' is the subject of the graduation
research of the author. Proposals on this research
can be found in reference 2.
2.2. Dimension Compare.
The object in the building database has
three fixed dimensions. A product from the product
database has three dimension-ranges with a step
value. During a dimension compare, the dimensions
of the object in the building are compared to those
of the selected product (picture 12). The X-, Y- and
Z- dimension-values of the object have to be within
the dimension-range of the product and occupy a
step value.
For certain products (e.g . concrete, paint , plaster) ,
the exact occurrence is determined during the
application in the building. The OBOM protocol calls
these products ' material ' (M-type) products. The
dimensions of these kinds of products are free in all
three directions and are only limited by the laws of
physics. Wh en applying a M-type product , chances
of a positive 'dimension match' are high.
Some products are manufactured while one or two
directions in the dimensions can still be changed on
site. These products are called ' versatiie' (V-type)
products. The directions in dimension which cannot
be changed , are usually offered in a range of
values . The thi rd type of product is the 'component'
(O-type) product. These products are fixed in all
three dimensions but can be manufactured in a
range of different dimensions.
15
Picture 13: Specifications
Compared.
16
2.2.1. Traversing Objects in Dimension Compare.
Some objects have one or more objects on a
lower level attached to them (e.g. a wall with two
windows). This is an example ol a 'parent-child'-
relation. When looking lor a product to take the
parent 's place, the product-database is searched lor
a product having two child-objects which lit the
description. The dimensions and position ol each ol
the windows are compared in the same way as
described earlier. The same rule applies when the
child-object becomes a pare nt-object in its turn and
has one or more child-objects atlached to them. The
tree ol objects is traversed Irom the top object and
each object is compared to its product. It will be
clear that this method demands a great deal ol
calculation time and may even result in a
computation explode.
2.3. Specification Compare.
From both the object in the building and
object in the product-database the data on the live
specilication subj ects are given. At this point, the
specilications ol each 'ROOM'-object in the
building-database have to be manually input. The
specilications ol a product are supplied by the
manulacturer and are present in the product-
database. When a product is compared to a object
in the building database, each specilication
atlribute ol the object is compared to the
corresponding attribute Irom the selected product
(picture 13) . When a value lor a specilication
atlribute is given lor both product and building
object , the ratio between the values is compared to
an allowance. The values in product and building
may, in this way, differ a lew percents without
leading to the rejection ol the product. This
allowance can be separately given lor each ol the
specilication attributes.
2.4. Knowledge Based Selection and Context
Compare.
This part ol the project is currently under
development. For a detailed report on the proposals
on this subject , reler to relerence 2.
17
18
3. MODELLING BUILDING AND PRODUCTS.
3.1. Introduction to Modelling.
The OBOM protocol is developed to provide
a language for modelling buildings and products.
The purpose of this model is twofold in the
philosophy of the OBOM. First of all, models
simplify the information when the application of
products is governed by a CAAD system.
Computers require weil defined chunks of data set
up according to a predefined format. The OBOM
protocol provides a language for modelling
buildings. The second purpose of a model is to keep
the designer's at!ention to important tasks . The
mayor part of the complex geometry and
performance information may be ignored by the
designer and is handled by the computer. When
more detailed information is requested by the user,
the system zooms in on the selected section and
shows one product or joint.
3.2. Designing a Building using the Protocol.
The design of a building start with the
definition of a object on room-level. This object
represents a kitchen, living room etc. (picture 1).
When the object is created, it's performance on all
at!ributes is assumed to be zero. The designer may
add desired light-levels, temperature, colour etc.
These specifications are then connected to the
object and can be changed later on. Objects on the
room-level can't be rotated around an axis, so only
the insertion point of the object is required next to
the dimensions.
The object is th en converted into smaller objects on
the group-Ievel (picture 2). The child objects inherit
two dimensions and much specifications from the
parent object. The unknown third dimension is
requested from the user. The position of the new
groups-objects can be aligned to assume the inside,
centre or the outside of the boundary. Wh en the
objects on group-Ievel are defined, each of these
objects can again be further detailed.
Objects on the sector-level are used to define
different zones within a group-object. These sectors
have a specific use in the floors and walls (picture
3). The sectors can be open, in which case they act
as a zone for interaction with either the outside
(window, door) or another room-object (door,
passage) . Open sectors can span an entire floor or
wall. Sectors can also be closed, to define a zone
with a different behaviour from the rest of the wall.
For instance, a piece of high-pressure material
between two floor high holes may represent a
column. For the definition of the sector-object an
insertion-point (x,z) and two dimensions (width,
height) are required. Further a type of performance
can be given (act like a: door, window, air, etc.).
The final conversion is dividing the objects on
sector-level into multiple objects on the 'Iayer'-Ievel.
These layers have different functions (picture 4).
The functions can be just about everything, but
NodelT has a few predefined ones (act like: brick,
insulation, steel, glass, etc.) . The facade of a
building is usually build up out of several layers with
separate functions . The designer can stack up to six
layers in a given sector. Each of these layers can
have its own set of performances like: water-
repellence, load-bearing. The total width of the sum
of the layers may exceed the width of the parent-
sector. The system can also keep the two values
equal. The width of the layers will be scaled to fit
the width of the sector.
Once the building is modelled , the user can start
refining the model. Objects can be deleted, added
separately or moved . Specification attributes may
be edited to closer represent a specific material of
function .
19
Picture 14: General CAD·model of
a product.
Picture 15: NodelT model on level:
Group
Picture 16: NodelT model on level:
Sector
20
3.3. Modelling Products using the PROTOCOL.
3.3. 1. Introduction.
One of the intentions of the Suilding Node
research project, is to offer manufactures of
building products a tooi for modelling their products
in a general format. This format may be used by
several future CAAD systems. Remember that the
OSOM protocol is not a 3D file-format like ' STEP' or
'IGES' . It is a tooi for selecting the right product for
the right place.
The physical appearance is not the mayor criteria
for choosing products. More important is the way in
which products perform to certain demands. The
OSOM-protocol provides a language for modelling
the performance of product. The OSOM research-
group has developed the tooi ' ProductSase' . This
tooi is used for modelling building products which
are then entered in the product database. The
language is for 95 percent the same as the
language for modelling buildings.
When modelling products, the first thing to be
determined is on what level the product starts to
replace the objects in the building (see also section
1.1). For example, a prefabricated facade start at
the 'group' -Ievel , a prefab. window starts at the
'sector'-Ievel. The product as a whole is then
surrounded by a 'boundary-box' (picture 14 & 15).
This box is the parent object on the starting level.
The three dimensions can have a minimal, maximal
and step -value. For a product without a range in
dimensions, the min. and max. are kept the equal.
Next step is to recognise elements in a product
which occupy the level below the parent-object (e.g.
windows in a facade) . The different elements are
surrounded by additional boxes (picture 16 & 17).
Those boxes have minimal , maximal and step -
values for dimension and position. This process is
repeated until all objects on the lowest (Iayer)-Ievel
are modelled. Every object in a product has
Picture 17: NodelT model on level:
Layer
specifications. These performance-specifications
are, for example the insulation value, fire resistant
performance, transparency etc. The specifications
for the object-classes currently implemented in
'NodelT' are listed in appendix B.
3.3. 2. Differences in Aggregation.
The product database uses the same object-
class for all three types of aggregation (paragraph
2.2). In order to model the dimensions of aM-type
product, the step value in all three directions is
chosen smal I (e.g. 1 mm). The minimum and
maximum dimension values are those which limit
the use ol the product. (it very hard to cast concrete
in a mould smaller 1 OOmm. Concrete walls over 60
m. long should be made up of two segments.)
Products ol the V-type have one or two directions
which may be sawed or cut . These directions have
a small step value when modelling the product.
When modelling O-type (0= object) products, step
valu es are usually zero or something like 300 mmo It
possible to model a range ol products in one entry
but thi s is only recommended lor simple products.
More complex products should be modelled one at
a time.
Building products are manulactured on many levels
ol prelabrication. The OBOM-protocol provides also
four levels of description lor products. Products can
be developed to act as a complete room (mobile
homes , Irame houses , toilet units). Wh en a room-
obj ect exists within the abstract building , having the
same specilications as the prelabricated product
room, the product could lullil a part ol the building.
The product will have group-, sector- and layer-
objects which will be appli ed in the design , thus
re placing the design in furth er det ail ol that room. A
prefabricated facade component has wind ows and
diffment layers of concrete and insulation when
apnlied in a building.
21
22
3.3.3. Tree Traversal.
The levels of the abstract descri ption of the
OBOM Protocol are used in the search for building
products. The user may apply a room- level bui lding
product in the design without ever havi ng seen the
exact physical appearance of the product (i .e. the
thickness of the wall s, position of the door). These
may not matter at the stage of the design process
the designer is going through.
This is usually not the case with prefabricated
facades. The position of t he windows has mayor
importance here. The user will model a group-object
in the abstract building to have sector-objects. If a
product is to match to an abstract model of t hi s part
of the facade, it has to have windows which can
take the same position as the windows in the
abstract model.
4. CONCLUSIONS.
The prototype program proved that replacing
parts of an abstract building by building products is
a promising development. The OBOM protocol can
be implemented in a expert system and used ir.
bot h design and development.
The four levels of detail provide a powerful way to
abstract any building. Most parts of a building fit
easily into some predefined description. However,
there are parts with an ambiguous or double use
th at cannot be described that easy. The envelope
can circumscribe any object and lends itself
perfectly for automation .
The performance specifications used in this project
are not complet e yet. Rather than working with
specific values , the researchers advise the use
procedures or functions for calculating a value for a
specification attribute at the moment it is requested .
23
24
APPENDIX A: NODEIT HELP TOPICS.
Documentation on NodelT 2.0.
A brief explanation of the forms and menu's.
By J.P. den Hartog. Student-Assistant / Researcher
at OBOM.
Release date:
Copyright © 1995 - 1997 by OBOM researchgroup ,
TU Delft.
25
26
CONTENTS.
I ntroduction.
Form 1: Add an Object to Building .
Form 2: Convert a Room into multiple Groups.
Form 3: Convert a Group into multiple Sectors.
Form 4: Convert a Sector into multiple Layers.
Form 5: Match an abstract object and a product.
Form 6: Export Building .
Common buttons on the forms.
27
28
INTRODUCTION.
NodelT is a program developed during the NodelT-project done at the OBOM
researchgroup. The research 's aim is to offer a utility helping and stimulating
architects in using prefabricated building products in their designs. By telling the
program what kind of product you want and where you want it, it offers a range
of products th at could fit your needs. A closer matching routine calculates more
precise how much your specification of a part of the building and a selected
product match. The building is set up as a collection of boxes. These boxes are
an abstraction of rooms , walls , windows , doors and sheets of a material. One
start with a set of ' ROOM' -objects and works down to the level of LAYER. On the
' LAYER' level all objects represent sheets or profiles. Objects on the ' LAYER' ,
' SECTOR' and also on the 'GROUP' level can be replaced by (prefabricated)
building products. It wil I be obvious that replacement of a GROUP-object
requires a much higher level a prefabrication of the product and is much more
difficult to calculate than replacement of a LAYER-object.
NodelT uses ' AutoCAD' or ' VRML' as an visualization module, the building and
the products are exported into an drawing. The objects are drawn as solid boxes
on their position and with their dimensions. These boxes can be moved and
scaled to modify the design made in NodelT.
• • • • • • • • •
• • • • • • • • •
•••••••••
OBOM
Open Bouwen Ontwikkelings Model
Figure 1.
29
FORM 1: ADD AN OBJECT TO BUILDING.
This is the form to start with. Use this form to define a new room in the abstract
building. If an object is added to the building with th is form, it will be defined on
the ' ROOM' level (future versions of NodelT will also support manually definition
of groups, sectors and layers). First the user has to pick an object to which the
new ROOM-object will be attached. The position and dimensions of the new
room are requested through six textboxes. The requested values are the
insertion point (X- , Y- and Z-value) and the dimensions (X- , Y- and Z-values) .
The pictures on the right side of the form show a preview of what the new room
will look like. Before clicking the CONVERT button, the specifications of the
room can be given. Behind the SPECS .. button is a form for the editing of
several specifications. The user can state strength, temperature, light etc. here.
After finishing the specifications, click the OK button. This data will also be
saved in the database. Clicking the CONVERT button will now calculate the data
of the new room and write this to the database on disk.
Figure2& 3.
30
FORM 2: CONVERT A ROOM INTO MULTIPLE GROUPS.
This form converts a given ROOM-object into four walls and two floors on the
GROUP-Ievel. In a ROOM-object the walls have only two dimensions, this
because they are represented by faces which have no thickness. The thickness
that is added to these faces is cal led the 'MATERlAL BAND' of each group and
is requested through six textboxes. The material band for each wall and floor
can be put in separately. The two other dimensions (Iength and height) are
copied from the ROOM-object. If the material band of a wall is zero, no
corresponding GROUP-object is made. Plane-codes yz1, YZ2, XZ1 and XZ2 are
used for the four walls, xy1 and xy2 are the roof and the floor. The user has the
possibility to align the walls and floors to the outside, center or inside of the
edges of the ROOM-object, much like the align functions in a word processor.
When all parameters are given, the CONVERT button can be pressed. The form
will add the new G ROU P-objects to the database. The results can be seen by
exporting the building to AutoCAD or VRML.
Figure 4.
31
FORM 3: CONVERT A GROUP INTO MUL TlPLE SECTORS.
With this form the user can create holes (Sectors) in the walls and floors
(Groups) made with the previous form. To select the group to work with, first
select the ROOM-object the group is attached to. Next select one of the
GROUP-objects attached to the selected room. In this GROUP-object the new
doors and windows will be defined. After selecting the group-object, the frant of
the object is projected in the preview picture on the right-hand side of the form.
The user is now able to place openings in the GROUP-object with the contrals
on the form. The position and dimensions of a new open-SECTOR-object can be
edited through the textboxes. The number of new objects is controlled through
the 'ADD SECTOR' and 'DELETE SECTOR' buttons. For each new object a
profile can be given. A profile specifies how the object will act in the real world .
When all windows, doors, etc. are in place, pressing the CONVERT bulton will
calculate the new objects on the SECTOR level and add these to the database.
The selected group-object is translated to an sector-object with identical position
and dimensions. The new open sector-object represent area's with different and
specific specification (in this solid object).
Figure 5.
32
FORM 4: CONVERT A SECTOR INTO MULTIPLE LAYERS.
This form defining LAYER-objects in the SECTOR. The user selects a SECTOR-
object to work with . This is done by selecting a ROOM-object, a GROUP-object
and finaily a SECTOR-object. The top view of the chosen SECTOR-object is
projected in the preview picture.
The user can then define up to six LAYER-objects. For each object a dimension
can be specified. The profile specifies how the object will act in the real world . A
special specification is the empty space. This is used to represent cavities
between layers. The preview picture shows the new objects as hatched boxes.
The form supports relative and absolute conversion. The relative division scales
the sum of the objects widths to the maximum of the SECTOR-object's width (=
100%) . Working with relative conversion, the sum of widths of the LAYER-
objects cannot be greater than the width of the converted sector. The absolute
conversion doesn't scale the width-values , the LAYER-objects are as wide as
the value of the textbox in millimeters with a maximum width of three times the
SECTOR-object's width.
Figure 6.
33
FORM 5: MATCH AN ABSTRACT OBJECT AND A PRODUCT.
This form offers the user the possibility to take an object on any level (ROOM,
GROUP etc.) and search the product-database to see if a products exists that
can take the object's place. After an object is chosen, the form lists the products
that could give a positive match with that object. The user selects one of the
products and presses the MATCH button. This will bring out a message
informing the user how much the object and product match. The user must
decide whether or not to apply the product in the design. The match is
performed on the different parts of the information. First the dimensions of the
object and product are compared. The context of object and product will then be
matched. This part is not implemented yet. Finally the specifications are
processed. These specification con sist of five parts. There are bearing, dividing,
connecting, finishing and supplying specifications. A match percentage is given
for each of the sub-specifications.
If a product is applied to an object, the visualization of the building will not show
the 'box' of the object but (if possible) an CAD-drawing of the product. In the
trial version of NODEIT the author has made a product-database of a few
(fictional) products. This can be used to try out the offer-demand principle.
Figure 7 & 8.
34
Sandwich Paneel 2
Sandwich-spouw Element
Trimat-sandwichwand
FORM 6: EXPORT BUILDING.
This form visualizes the abstract building in AutoCAD 12, AutoCAD 13 or in a
Virtual Reality World . The user can export the object on each level separately
or all together. The objects are drawn as empty boxes, the objects with
products applied are show as detailed 3D-blocks (only in AutoCAD. The
exported drawing can also be used to select objects from the visualization. If
the designer wants to use the PICK FROM CAD button instead of the
comboboxes (which the author recommends) , exporting the building frequently
will help seeing where each object is. Needed for visualizing are the target and
the levels.
Figure 9. 10 & 11.
35
COMMON BUTTONS ON THE FORMS.
BUTTON:
I ~ I C K FR OM CAO.I
This button brings AutoCAD to the front, and asks the user to select an object to
work with in the form. The program will then send the name of the selected
object to the form where the ëpick from CADf-button was pressed. This button
replaces selection by means of the awkward Room:, Group: and Sector:
Comboboxes used to select an object. To be able to use this button, the user
must first export the building to AutoCAD.
BUTTON: I.s.PECS ...
This button should bring up the list of specifications belonging to the object in
question. This only works with rooms for now. While much research is still
needed for this part of the project, the function is disabled for the rest of this
beta version.
BUTTON:
I.c.
LOSE
.
This button closes the active form without converting or changing any
information.
BUTTON: ICONYERT.
This button converts the selected object with use of the parameters on
the form to one or multiple objects on the level bel ow.
36
APPENDIX B:
USED PERFORMANCE SPECIFICATION
ATTRIBUTES.
37
38
"!Y
0M
unction Performance Unit
.Bearing
Bear yes/no
Stabil yes/no
Stift yes/no
Weight kN

FireResistant minutes
LiqhtLevel Lux
NoiseLevel dB
Temperatu re °Celsius
3.Connectinq
ConnectsTo R/G/S/L
4.Finishinq
Color code
5.Suoolvinq
ContainsPioesAt R/n
GROUP
Function Performance Unit
1.Bearing
Bear yes/no
Stabil yes/no
Stift yes/no
MaxPressure N / mm2
SpecificG ravity kN / m3
Weight kN
2.Dividing
FireResistant minutes
Win Percentage
%
Noise I nsulation dB
UvalueAverage m2' K / W
f3.Connecting
ConnectsTo R/G/S/L
ConnectBehaviour DomlRes
f:l.Finishing
Color code
Texture fine-course

ContainsPipesAt G/n
39
SECTOR
runctlOn Performance Unit
1.Beanng
I;jear yeslno
:stabil yes/no
Stiff yes/no
MaxPressure NI mm2
SpecificGravity kN I m3
Weight kN
2.Dividing
Fi reResistant minutes
LightThrough %
Noiselnsulation dB
Uvalue m2' KI W
DampDiffusionCoeff. m2/s
3.Connecting
ConnectsTo R/G/S/L
ConnectBehaviour Dom/Res
4.Finishing
Color code
Texture fine-course
5.Supplying
Contai nsPipesAt Sin
40
LAYER
Function Performance Unit
1.Bearing
Bear yes/ no
Stabil yes/ no
Stiff yes/ no
MaxPressure N / mm2
SpecificGravity kN / m3
Weight kN
Youngs' modulus N / mm2

Fi reResistant minutes
FireAble class
LightThru %
Noise I nsulation dB
HeatExpansion % / K
Uvalue m2' K / W
SpecificHeat J / (kg' Kl
HeatConductionCoef. J / (m's'Kl
Waterintake volume %
DamoDiffusionCoef. m2 / s

ConnectsTo R/G/ S/ L
ConnectBehavi our DomlRes
4.Finishina
Color code
Texture fine-course
Reflection %
Absorotion %
ScratchResistance Hv
5.Suoolvina
ContainsPioesAt Lln
41
42
REFERENCES.
1. Hartog, J.P. den, ResearchReport 1 Bouwknoop
II NodelT project, OBOM, Delft UT, march 1996.
2. Hartog, J.P. den, Graduation ResearchProposai :
Product next to Product, Delft UT, october 1996.
3. Kapteijns, J., e.a., ResearchReport BouwKnoop
I, OBOM, Delft UT, 1992.
4. Microsoft Corporation , Access Manual; Building
Applications, 1994.
5. AUTODESK Inc., AutoLISP Programmers
Reference, 1992.
43
44

Sign up to vote on this title
UsefulNot useful