A Performance-inspired Building Representation for Computational Design
Georg Suter, Ardeshir Mahdavi, Ramesh Krishnamurti
CAAD Futures ’99 (pg. 117-132)
This paper contends that current CAD applications do not support “convenient manipulation and
semantic building information.” Essentially, the aim of this project is to support CAD based
design development that can simulate the integrity of the physical building on the fly. Specifically,
it (the proposed representation system) aims to do four things: “capture the informational
requirements of detailed, physics-based building simulation; maintain geometric integrity;
support efficient spatial queries; and provide scalable operations for design development.” The
representation system proposed in this paper is then described via its requirements and the
descriptions.
Representation Requirements:
1. Simulation Completeness- In order for an analysis to be accurately rendered, the system
must have complete access to the “space-based” attributes of an element such as location,
dimension, construction and material. With knowledge of all these attributes, analysis of
energy, lighting, acoustics and air flow.
2. Integrity- This makes sure that the CAD model mimics that physics of a built project: gaps
between objects, and overlapping elements are caught and brought to the attention of the
designer.
3. Efficient spatial queries- This seems to be an accessibility issue. Information from lighting
and acoustic simulations can be complex. This paper suggests that queries could be
performed on a rich, shared model.
4. Design development- CAD models are often difficult to manipulate. Quick modification can
be error prone because related building elements are not necessarily related to each other in
the hierarchy of model data structure. This paper aims to make modification, like scale, for
simulation purposes a one-step process.
Representation Description:
1. Partitioning- In this design method, the user starts with a generic building on a generic site.
This sets up what is termed as an “initial configuration.” The initial configuration sets the
relationships of elements so that integrity can be maintained through the design process.
Design is performed by applying partitioning rules to volumes, surfaces and lines “which are
the basic geometrical types supported by the representation. This means that a line cannot
exist without a surface and so forth.
2. Partitioning Terminology- Partitioning is performed by “volume partitioning.” A designer
chooses two surfaces of a volume that do not have a shared edge. The surfaces become the
“primary bounding elements” while the others become the “secondary bounding elements.”
Partition attributes are stored at the parent level of the volume and are categorized as
orthogonal or non-orthogonal.
3. Orthogonal partitioning- Requires that all primary bounding elements and partitions be
parallel. “Orthogonal partitioning is specified by three rules… The first rule allows for
creation of child entities at a new level in the hierarchy tree. (2) Once a new hierarchy level
has been created, existing entities may be modified, partitions may adjust their position to
accommodate the change. (3) New partitions are parallel to the primary bounding surfaces
and sibling partitions. Again, related sibling partitions are adjusted to make room for new
partitions and their corresponding sub-entities.”
4. Non-orthogonal partitioning- Is similar, but is less restrictive than orthogonal partitioning.
Non-orthogonal builds off of an orthogonal partition already performed. The difference is that
the designer is now given two dimensions to manipulate instead of one. Otherwise, all
hierarchies are maintained.
5. Refinement of partitions- Partitioning of surfaces and lines can be performed to create more
complex and applicable design elements like gabled roofs, bay windows, etc. When
refinements are performed, the system analyzes whether the refinement has left any gaps to
the overall volumes. If so, the gaps are automatically filled in the representation. If not,
nothing is done. Volumes can not be directly refined, but only changed via the refinement of
its bounding surfaces.
6. Integrity conditions for refinement- Checks for overlapping volumes and surfaces are
checked by the system, and performed locally between adjacencies only.
7. Containment hierarchies- This is the object hierarchy that logically breaks elements down
from large to small, volumes to lines.
8. Constraints- Dimension Constraints: are considered for repetitive tasks and are assigned to
the elements only. Constraint Manipulation: dimensional constraints are considered either
free or fixed. Initially, all dimensions are free by default. Free dimensions are subject to
manipulation or constraint satisfaction. Therefore, a designer may be able to fix a few key
dimensions and then let constraint satisfaction set the free dimensions as alternatives are run
through. Constraint Satisfaction: is performed in two stages. The first detects conflicts that
must be resolved before the second step, the simulation performance is run.
9. Labels- Can be used to breakup building elements into groups for more efficient checking of
requirement, such as codes. This involves label inheritance from parent objects.
10. Integration with simulation- This has something to do with a filtering out process of
alternatives on a series of levels.
Implementation of a Representation Prototype
The paper presents an in-progress system of this representation method. It is written in Java and
presents the user with various levels of abstraction of a design. Through a series of collapsible
views, partitions can be manipulated by the user to change the design via mouse dragging
actions.
Problems acknowledged in the paper is: a limitation to box-like volumes, rectangular surfaces
and simple line segments. Triangulated and curvy elements are not presently allowed in this
interface. While many buildings can be digested into discreet parts, some cannot. Such
buildings do not work well in this methodology. There is a lack of constructing separate, discreet
hierarchies of elements.
Conclusion
This paper concludes that computational support, such as constraints, must be included in both
the design manipulation and simulation environments. It contends that this is a marked difference
from typical CAD research efforts that merely linking design and simulation environments is the
paramount issue. While this project also seeks to integrate these two applications via the product
of design (the computer model), additionally, it tries to bring some of the factors that affect the
outcome of a simulation (gaps between objects, incomplete volumes) into the design
environment.
This paper addresses some significant problems inherent in CAD. The difference between
perceived representation by the user and modelled reality is a common but often ignored problem
in CAD applications. While things may appear a certain way, they may be something different:
small gaps can exist between objects, or volumes may actually be planes. This is a level of
imprecision that should not be tolerated.
Their method of partitioning of design is intriguing, but limiting. It solves the problem of object
hierarchy and property maintenance, which is essential to designing with constraints and
simulation. Most importantly, it does so automatically, which is good and bad. Good in that the
design process is not interrupted by object property maintenance, bad in that the user may not be
aware of the complexity of the objects presented to them. Partitioning supposes a set method of
design that assumes all buildings to have a set of features and properties. This is a valid
methodology, but not the only route. Beyond not supporting a variety of forms, which paper
admits as a flaw, it also does not support a variety of design processes.