"HYPERWALLS" OR AN APPLICATION OF A NON DETERMINISTIC RULE BASED SYSTEM IN INTERACTIVE ARCHITECTURAL MODELING
by Vasileios Gougoulidis
M. Arch.
The Ohio State University
| This paper presents the architectural modeling as a process of augmenting spatial information; a chain of actions that leads from a sketched idea to the elaborated model. A symbolic constraint solver tool is connected to traditional C.A.D. techniques, as well as to a data representation scheme efficient for architectural elements. The orchestration of the available and added tools allows the designer to “edit ideas” fast, keeping in mind that different design profiles require adaptive tools to support the varying methodologies. Until the moment that automated design will be both possible and desirable, machines can really shorten the time needed to visualize design ideas in the sense of a handy but non-decisive “calculator”. The discussion is built around illustrated examples from the implemented constraint based modeler. |
Although fascinating ideas about how a design system should be formatted appeared as early as in seventies [1], the critical barrier that prohibited the envisions of design automation from becoming reality has been the "ill defined" nature of the design decision making process [2]. By focusing on the machine perception rather than the decision making factor, it is still possible to establish the designer-machine interaction at a higher level without seizing any of the decision making privileges from the designer.
This paper discusses through examples an architectural modeling system, which integrates traditional geometric modeling techniques, inherent architectural representations [3], and rule based geometric reasoning [4], to provide the designer with such an interactive environment. The hypothesis tested in this study has been that symbolic computation techniques can be effectively applied in an architectural modeling system to reduce the bulk of editing operations needed to control complex geometric structures. Most of the material that supports the discussion in this paper is related to the experience gained through the implementation of a prototypical constraint based architectural modeler. The examples demonstrate that working closer to the design idea level rather than deterministically instructing the modeling system to perform actions significantly reduces the overhead involved in the designer-computer interaction. This is accomplished by using a reasoning mechanism capable of capturing the user's intention and compiling it into sequences of well defined modeling system actions.
This mechanism cooperates with graphical interfaces and relies on efficient representation schemes of architectural elements to increase efficiency in the modeling process. The prototypical system used for the examples has four conceptual layers of work. At the very inner system level a LISP interpreter has been implemented [5] which was chosen as the medium to represent and manipulate in symbolic form the modeling structures, the inference mechanism, the rules controlling the system's behavior and the constraints database. At a second level a solid modeler has been built that relies internally on the LISP forms to store boundary representations of solids, along with viewing information and non-geometric attributes. Controlling the modeler is the output of a reasoning machine[6] that takes as input a set of rules and a set of constraints in symbolic form. Finally the constraint editing of this mechanism has been interfaced to the designer using the visual semantics of drafting dimensioning.
First the major components that comprise the architectural modeler are individually presented and then an example of integrated usage of the above components is given.
One important component of the three dimensional sketching process, as described here, is the virtual space cursor. This locator driver was developed to support three dimensional input and editing of joints inside a two dimensional viewport (i.e. window). This is accomplished by inverting the standard viewing model’s [7] mapping, under certain assumptions, and attaching the result to the mouse tracking mechanism, allowing virtual 3D interaction. The joints are defined as sets of 2D or 3D vectors and most of the time they are the result of some action with the locator device. Joints are the elements used to define shapes, and they carry at least geometric information. Shapes compose sketches and they are collections of curves. In our case these curves are the axial curves of walls and they are not necessarily linear. A skeletal model built after a few clicks is shown in figure 1.
Figure 1. Three dimensional joints
Using the axial curves and other information saved at the joints, like local offsets, we can derive offset curves, or more precisely speaking:
Figure 2. Offset curves
Extruding the offset curves generates ruled surfaces which are the walls. A quite extreme case of such an approach is shown in figure 3, and demonstrates variation of all the available parameters, even of the height as input from the virtual space cursor. A solid wall which is derived from a cubic degree curve in the floor plan, starts as tall and thin, and ends up as low and wide. The solid is constructed based on the skeletal information of the 3D joints as shown in figure 1.
Figure 3. Example wall
As already mentioned a sketch is a set of joints and a set of curves connecting the joints. The joints, among other information, carry the primary geometric description of the model. Axial curves that connect the joints and offset curves used to derive the wall boundaries can be placed as soon as the location (and orientation) of the joints is established. The geometry of the joints is calculated by the constraint solver, which is a vital part of the model’s construction line because it makes possible to edit graphic relationships and parameters of the sketched idea a posteriori[8]. The sketched idea can be modified by altering the geometric constraints imposed on the joints. In the case that the sketched shape carries additional attributes, everything including curve intersections and offsets is going to be re- evaluated up to the final model. Geometric constraints have a visual representation for the user interface and an internal syntactic representation used by the constraint solver. The table in figure 4 shows an entry for every used constraint along with its visual representation and internal syntax. Internally constraints are represented as lists of expressions as shown under the “Syntax” column of the table. The first item of the list is a label identifying the type of the constraint, followed by a sublist of the indices to the joints involved, and if applicable by a LISP form, that evaluates to a quantity relevant to the constraint. In the process of constraint solving these lists of expressions are considered to be constant facts, even though they may contain LISP variables.
Figure 4. The constraints, their visual representation, and their internal syntax
There are three levels of constraints classified by the type of information they carry:
It is the constraint solver that is responsible to build the structure out of the information mass available, to check for consistency, and to identify redundant data. To do so, the constraint solver uses some structured patterns: the rules. Rules comprise of two parts: a condition and a consequence. The condition contains a pattern of goals. The only syntactic difference between a goal and a constraint is that the goal may contain matching variables, while the constraint contains only constants. A rule may contain variables in its consequence part too, but the same variables always have consistent values within the scope of a rule. Rules are applied in the order they were defined, therefore if some rules should be tested earlier than others then they should be defined first. Following is a sample of implemented rules. The part on the left of the arrow is the condition of the rule, while the part on the right is the consequence. The rules appear in a simplified form which does not include the values involved in the geometric calculations of each substitution. Capitalized letters represent the matching variables.
The constraint solver uses rules, like the above, to structure the unordered constraint data and to instantiate the joints geometry. Matching is the basic mechanism to detect if a pattern of goals which appears in a rule’s condition has corresponding facts in the constraint database. In such case the rule applies to the database, which means that the matched constraints are substituted by the consequences of the applied rule. Matching can be thought as a slot filling process as shown in figure 5. The condition part of a rule is represented as a pattern of hollow shapes of different type and different shade. Constraints are represented as solids of different type and shade. The shape type represents the constraint type, like point, dimension, and angle, while the shade represents the particular constraint’s arguments. To fill a slot both the shape and shade should match. To test the pattern of a rule’s condition against the constraints database, in a first stage rows of candidates are formed for each slot based purely on the constraint type, then all permutations are checked to find the one with a consistent combination of variable arguments. If a match was detected a substitution follows with the consequences of the applied rule and matching starts again from the first rule. Substitution implicitly builds the mathematical function that is going to evaluate a joint’s geometry after solving has successfully finished. If there was no match then the next rule is tested (if anyone left).
Figure 5. Matching constraints against a rule
Following is the first example case of generating and editing a constrained parameterized model. The model, that has been kept minimal for the clarity of presentation, introduces the benefits of using constrained, parameterized skeletal shapes, to control void representations [9] of architectural structures.
Figure 6. Generating a sketch
In the first place the user has to define a shape (figure 6) using a sketching tool, which in our particular example is a rectangle. This sketch sets a starting topology, and an initial geometry. The topology is roughly the knowledge we originally have when we start our design project, while the geometry is what we try to instantiate and it may change in the process many times.
Figure 7. Constraining, and setting offset and height attributes
As a next step we want to constrain the rough design idea to adhere to certain specifications (figure 7 left), in our case dimensional decisions about the design project. We may even decide to attach attributes to the rough sketch at any point of the process, i.e. before or after we constrain the sketch (figure 7 right). The initial values set in the constraint fields are automatically assigned pre-calculated values from the sketch’s geometry. This approach reduces the overhead needed to set constraint values for parts of the project that are of less significance. In our example these are the longer sides of the rectangle. Whenever we assign a dimensional constraint the system offers two options: either we set the constraint to a fixed value (i.e. distance = 200), or we set the constraint to an expression which may include LISP variables (i.e. distance = 2 x side, where side is an LISP variable). In the former case after resolving the constraints we end up with a single shape, provided that there is a solution. In the latter case, which is of more interest, after resolving the constraints we end up with a family of constraintwise similar, parameterized shapes.
Figure 8. Solving the example sketch and reevaluating it
The last two figures (figures 8 left, 8 right ) are two different evaluations of the same shape as in figure 7. The shape has been constrained to have the main diagonal equal to the value of the LISP variable “diagonal”, one of the smaller sides equal to the E-Lisp variable “side”, and its opposite side equal to “two times side”. The first evaluation is for “diagonal” equal to 200 and the second is for “diagonal” equal to 300. A variable can be used to control more than one constraint. In the presented example this is the case with the two opposite sides that equal to “side” and “2 x side.” A complicated project which has many dimensional constraints can be controlled sometimes by a few dimensional parameters that appear in multiple constraints, standalone or as components of expressions.
Figure 9. Drawing a polyline and evaluating for certain constraints
In the second example (figure 9) we have a single polyline of eight segments sketched with no particular structure. Then we add height, wall thickness, and the following constraints:
It should be repeated at this point that the order the user attaches attributes and constraints to the initial skeletal shape does not matter. As soon as the constraints are resolved there is a dramatic change to the original almost randomly put polyline. The result is an extruded solid from the carefully dimensioned and placed solution to a line puzzle. As it can be seen on the right-hand side of figure 9, all the structure that the initial polyline was carrying has been reevaluated including the intersections of the offset curves that generate the wall surfaces, and the final solid. The user can continue altering the shape from this point either deleting and adding constraints to form a different structure or just editing the parameters to modify structural dimensions. In all cases the full model is evaluated immediately, a result of the efficiency of the internal floor plan representation. The above examples demonstrated that constraints, parameterized shapes, and efficient representations can contribute to facilitate the process of transforming a design idea into a traditional solid model. The ability offered to alter the object at any level of the process (i.e. the sketch, the constraints, the parameters, or the produced solid) increases the overall flexibility of the interaction with the user.
In conclusion the use of symbolic expressions for resolving geometric constraints applied to architectural modeling was investigated. A prototypical design program has been implemented, based on a LISP interpreter, where the effectiveness and efficiency of symbolic computation in constrained modeling has been tested. The results have shown that constraint modeling in architectural context can be of significant importance in at least two non exclusive design situations: when specification driven design is required, or when a few parameters which are repeatedly used control a large amount of geometric data. Additionally the uniformity offered by symbolic data representation at the implementation level, combined with the interactive graphic interface provided to edit these structures, has been proven to be extremely effective.
BIOGRAPHICAL SKETCH OF THE AUTHOR
| Degrees |
| 9/91-6/94 M. Arch., The Ohio State University (Specialization in Computer
Aided Design)
9/82-10/89 Dipl. Arch., Aristotle University of Thesaloniki, Greece (5 year Professional Degree in Architecture) |
| Research |
| 9/93-6/94 "2D Void Modeling with Symbolic Constraints" (Master's
Thesis, The Ohio State University)
5/90-9/90 Automation Tools for User Interfaces of Scientific Applications 1/90-11/90 Optimization of Classroom Design (Funding Ministry of Education, Greece) 9/88-10/89 "Description, Manipulation and Representation of the Three-Dimensional Space with the Use of Computers." (Thesis Leading to Professional Degree in Architecture) |
| Professional Experience |
6/94-3/00  ,
Columbus, OH (Software Development) |
