Unambiguity

617 Shape Grammars-Volume 2 - Computation and Performance - eCAADe 31 |

Unambiguity

Difficulties in communicating shape grammar rules to a digital interpreter

1_{SWAP Architects, Austria,} 2_{Georgia Institute of Technology, USA} 1_{http://plus.swap-zt.com,} 2_{http://www.coa.gatech.edu}

1_{tg@swap-zt.com,} 2_{athanassios.economou@coa.gatech.edu}

Abstract. The rule editor of a parametric shape grammar interpreter is presented. The problems that arise are discussed along with their solutions.

Keywords. Shape grammar; parametric shape grammar editor; implementation.

INTRODUCTION

Shape grammar implementations, in theory and praxis, have received increasing attention over the last years. Recent projects have been introduced by Yazar and Colakoglu (2007), Trescak et al. (2009), Yue et al. (2009), Keles et al. (2010; 2012), Jowers and Earl (2011) and Grasl (2012). Each project offers some solutions to the general problem, but few imple-ment or describe rule editing capabilities. A com-plete shape grammar interpreter should support emergence, parametric rules and rule editing via a graphical editor. Here the results of such an effort (Grasl and Economou, forthcoming) are described with a focus on the peculiarities of the parametric rule editor.

In order to implement a rule editor for a shape grammar interpreter several difficulties have to be overcome. Mark Tapia (1999) already introduced some ideas concerning the user interface, most of which still hold today. However, the editor described by Tapia did not support parametric rules.

Although ambiguity is sometimes seen as a strength of shape grammars (Stiny, 2006), it is not during rule definition that it should come into play. Here unambiguity is essential. This is perhaps the dilemma of trying to implement shape grammars

with binary devices. In the context of a rule editor ambiguity will result in little more than serendip-ity. Despite the successes of serendipity, here we will try to restrict it to a minimum. Rather it is dur-ing the match finddur-ing process, while decomposdur-ing a shape into its constituent parts, that ambiguity has its place.

As simple as many rules may seem to the human mind when drawn on paper and explained by an accompanying text, it is quite a different matter if a digital computer is the entity trying to understand. It is fantastic how many details the human mind can overlook unbothered, how many blanks are filled in on the fly in order to understand a rule.

Of course if one were to sit down and describe a rule in computer code some ambiguities might fall away, most likely though it will take several attempts until the desired result is achieved. In any case this is not the desired solution, rather the designer should be able to communicate with the computer in a more intuitive language, that of the drawn shape. This is difficult enough for a non-parametric, or rig-id, shape, but once parametric matching is allowed things become all the more complicated.

618 | eCAADe 31 - Computation and Performance - Volume 2 - Shape Grammars

EDITOR

Conventions

Like Tapia proposed, it has turned out that draw-ing the left hand side (LHS) and the right hand side (RHS) on top of each other, rather than on their re-spective sides of an arrow, is advantageous.

If for example rule 1 (Figure 1) cannot be de-scribed by absolute changes, like:

‘Move the square 2 units to the right and 2 units up’

but rather has to be captured in relative terms like: ‘Translate the square by the vector AC ⁄ 2’

it is clearer if they are overlaid. Clearly all the param-eters used for such a description have to be derived from the LHS, since the RHS does not exist at the time of rule application. In a sense the RHS has to be rigged onto the LHS and overlaying makes this clearer.

Colours are according to what is used for con-struction documents of a renovation project. The LHS is drawn in black, the colour of existing objects that are not altered. New objects, in our case the RHS, are drawn in red. Objects that are deleted are yellow. Figures in this paper follow a slightly differ-ent convdiffer-ention: Existing, unaltered lines are dark grey, new lines are black, deleted lines are not used, but could be light grey.

Rule interpretation

Although it was attempted to keep the interface as graphical as possible, it did turn out that making a few categorisations via drop-down lists simplifies the interpretation of the rule.

Not all rules can be handled in the same way. In this respect the schemas introduced by Stiny (2006) have proven to nicely organise the rules. Of course the general schema

a → b

has to be covered. In addition a distinction was made for rules that use transformations only a → t(a)

This distinction is a necessity, to deal with rules similar to rule 2 (Figure 2a). Rule 2 is ambiguous in

the sense that its verbal description could for exam-ple be:

‘Rotate a square by 45° and then scale the result by 1/√2’

or

‘Inscribe into the square ABCD a second square EFGH such that AE = EB, BF = FC, CG = GD, DH = HA’

For a normal rule it does matter which descrip-tion is selected. If however the rule is parametric, in the sense that it can be applied not only to squares, but also to rectangles and other quadrilaterals, the difference is meaningful. If the rules

‘Rotate a quadrilateral by 45° and then scale the re-sult by 1/√2 ’

or

‘Inscribe into the quadrilateral ABCD a second qu-adrilateral EFGH such that AE = EB, BF = FC, CG = GD,

DH = HA’

are applied to a rectangle the outcome will be very different (Figure 2b).

Additionally a distinction is made for rules that leave the LHS unaltered

a → a + b

Figure 1

Rule 1: Copy and translate a square along half its diagonal.

Figure 2

(a) The parametric rule 2 and (b) varying results depending on its interpretation.

619 Shape Grammars-Volume 2 - Computation and Performance - eCAADe 31 | and

a → a + t(a)

respectively. The first two schemas could also deal with these cases. It is more a matter of convenience to prevent having to redraw the LHS.

The mapping used for match finding is another category the designer has to select. Essentially the permissible transformations are defined. Rules are assigned one of four mappings: Identity, Isometry, Similarity and Topology (Table 1).

The first, ‘Identity’ is included for completeness sake. Scale, rotation and position must match ex-actly. This mapping is normally not used for shape grammars, but it is not unthinkable.

‘Isometry’ is a mapping where rotation and translation is allowed. Shapes must have the same lengths and angles.

‘Similarity’ allows for scaling in addition to rota-tion and translarota-tion. This is the default mode, as it is also the most common method of matching shape rules.

‘Topology’ requires only the structure, the neighbourliness, to match. It is the most flexible mapping and the basis for truly parametric rules.

CONSTRAINTS

Mapping constraints

Rules of all mappings except for ‘Topology’ are tri-angulated over the set of vertices; this is for internal use only and is not displayed to the designer. The

triangulation ties together disjoint shapes (see rule 3; Figure 3) and helps to avoid having to deal with angles and trigonometric functions. The triangles are then constrained according to the selected map-ping as shown in Table 2.

Symmetry constraints

Finding a match in all its symmetric variations is a task assigned to the shape grammar engine rather than the editor, and is described elsewhere (Grasl and Economou, forthcoming). Sometimes however too many variations of a match can be returned. This is the case if the rule itself exhibits some sym-metry and thus cancels out some of the prospective matches. Here the editor can help by detecting such symmetries of the rule and by adding appropriate constraints to the description. For this purpose an algorithm as described by Wolter et al. (1985) was implemented.

For example, rule 1 (Figure 1) shows a rule that has mirror symmetry through [AB]. Normally the en-gine would return each square in eight variations, the eight isometries of the square. In case of rule 1 however each left turning variation will have one right turning variation that will result in the same shape. Here a constraint on rotation is added by the editor

(AB × AC) ∙ z > 0

restricting the cross product of two vectors to a pos-itive number.

Manual constraints

In addition to these automatic constraints rules can also be constrained manually. The web based imple-mentation does not allow for constraints to be de-fined graphically, instead each vertex is marked with an alphanumeric value; these identifiers are then used to formulate constraints mathematically.

Table 1

Possible mappings and their meaning.

Figure 3

Rule 3 and its triangulation that is generated for some of the mappings.

Position Length Angle & Ratio Parallelism Cross ratio Neighbourliness

Identity • • • • • •

Isometry • • • • •

Similarity • • • •

620 | eCAADe 31 - Computation and Performance - Volume 2 - Shape Grammars Manual constraints are important to model

specific requirements that cannot be covered by a mapping alone. If for example a rule should be ap-plicable to rectangles of all proportions, then the topology mapping hast to be used in combination with geometric constraints restricting a quadrilat-eral to a rectangle.

CONCLUSION

Implementing a general parametric shape grammar interpreter is not an easy task. Once it is achieved the question arises of how to feed the interpreter with rules. Of course the rules could be formulated directly in the underlying representation used by the interpreter. In the case at hand this would mean describing the rules as graph grammar rules in the description language provided by the graph gram-mar engine. While this is indeed a flexible option, and possibly the best approach for some very specif-ic rules, in general it is desirable to be able to specify rules graphically.

The approach presented here builds on the un-derlying graph representation of shapes. Neverthe-less most of the findings should be application to other implementations as well.

Defining the required mapping is not essential, since the same effect can be achieved by manu-ally adding constraints. However, this is tedious and more often than not a mapping will suffice.

Manual constraints are of course an absolute ne-cessity for a parametric shape grammar interpreter. Visual constraint definition would be nice, but for-mula based constraints have proven to be a good and flexible solution. Visual constraints can be add-ed fairly easily if the add-editor is implementadd-ed in a CAD environment that supports such constraints.

Treating rules of the schemas a → b and a  → 

t(a) differently could perhaps be avoided if complex

rule definitions based on constructive geometry are

possible. Again things are simplified by offering this additional possibility.

REFERENCES

Grasl, T 2012, ‘Transformational Palladians’, Environment and

Planning B: Planning and Design, 39(1), pp. 83 – 95.

Grasl, T and Economou, A (forthcoming) ‘From topologies to shapes: Parametric shape grammars implemented by graphs’, Environment and Planning B: Planning and

Design.

Jowers, I and Earl, C 2011, ‘Implementation of curved shape grammars’, Environment and Planning B: Planning and

Design, 38(4), pp. 616 – 635.

Keles, H Y, Özkar, M and Tari, S 2010, ‘Embedding shapes without predefined parts’ Environment and Planning B:

Planning and Design, 37(4), pp. 664 – 681.

Keles, H Y, Özkar, M and Tari, S 2012, ‘Weighted shapes for embedding perceived wholes’ Environment and

Plan-ning B: PlanPlan-ning and Design, 39(2), pp. 360 – 375.

Stiny, G 2006 Shape: Talking about Seeing and Doing, MIT Press.

Tapia, M 1999, ‘A visual implementation of a shape gram-mar system’ Environment and Planning B: Planning and

Design, 26(1), pp. 59 – 73.

Trescak, T, Esteva, M and Rodriguez, I 2009, ‘General shape grammar interpreter for intelligent designs gener-ations’ in B Werner (ed) Proceedings of the Computer

Graphics, Imaging and Visualization 2009, pp. 235–240.

Wolter, J D, Woo, T C and Volz, R A 1985, ‘Optimal algorithms for symmetry detection in two and three dimensions’, The Visual Computer, 1(1), pp. 37 – 48.

Yazar, T and Colakoglu, B 2007, ‘QSHAPER’ in J B Kieferle and K Ehlers (eds) Predicting the Future: 25th eCAADe

Confer-ence, Frankfurt am Main, Germany, pp. 941-946.

Yue, K, Krishnamurti, R and Grobler, F 2009, ‘Compu-tation-friendly shape grammars: Detailed by a sub-framework over parametric 2D rectangular shapes’ in T Tidafi and T Dorta (eds) Joining Languages, Cultures

and Visions: CAADFutures 2009, pp. 757- 770.

Table 2

The constraints that are added automatically depend on the chosen mapping. Topology Similarity Isometry Identity No automatic constraints.

The proportions of the edges of the triangulation are constrained.

In addition to the proportions one length is constrained to an absolute value. The coordinates of all vertices are constrained.