00001.tif

PDF

Download

Open document

Transcript (if available)

Content AN OPERATIONAL APPROA CH FO R GEOM ETRIC CO NSTRA INT SATISFACTION by Bin Wang A D issertation Presented to the FACULTY OF TH E GRADUATE SCHOOL UNIVERSITY OF SOUTHERN CALIFORNIA In P artial Fulfillment of the Requirem ents for the Degree D O CTO R OF PHILOSOPHY (Com puter Science) December 1991 Copyright 1991 Bin Wang UMI Number: DP22840 All rights reserved INFORMATION TO ALL USERS The quality of this reproduction is dependent upon the quality of the copy submitted. In the unlikely event that the author did not send a complete manuscript and there are missing pages, these will be noted. Also, if material had to be removed, a note will indicate the deletion. Dissertation Publishing UMI DP22840 Published by ProQuest LLC (2014). Copyright in the Dissertation held by the Author. Microform Edition © ProQuest LLC. All rights reserved. This work is protected against unauthorized copying under Title 17, United States Code ProQuest LLC. 789 East Eisenhower Parkway P.O. Box 1346 Ann Arbor, Ml 4 8 1 0 6 -1 3 4 6 UNIVERSITY OF SOUTHERN CALIFORNIA f L j ) THE GRADUATE SCHOOL r " UNIVERSITY PARK '- 'P - 3 LOS ANGELES, CALIFORNIA 90007 5 ^ | J.7A This dissertation, w ritten by Bin Wang under the direction of h.}.?....... Dissertation Committee, and approved by all its members, has been presented to and accepted by The Graduate School, in partial fulfillm ent of re quirements for the degree of D O C TO R OF PH ILOSOPH Y ........................... Dean of Graduate Studies Date J?.P.be.f 2 5A 1 991 DISSERTATION COMMITTEE tairperson Q -£\ ! Acknowledgment My advisor, Professor Farhad Arbab, deserves my sincere gratitude for his I inspiration and patience with my research throughout the years. I would like to I thank the other members of my thesis com m ittee, Professor Aristides Requicha and Professor Alice Parker, for their perceptive comments. I am appreciative of Professor George Bekey and Professor Dennis McLeod who kindly joined my oral exam ination com m ittee. M any thanks to Professor Ming-Deh Huang for his direction on my early graduate study in this departm ent, and to Professor « | Requicha for allowing me to use his Program m able A utom ation Laboratory in I ' my thesis-w riting process. I I | I am indebted to a num ber of people who had been working on the Oar project. | It provided a desirable object-oriented platform on which I could do much of the im plem entation work. Special thanks to my wife, Jill. W ithout her support and encouragem ent, I would have never finished this work. 1 1 This research was supported in part by NSF grant DMC-8505334, by NSF grant CDR-8717332, and by a grant from the In stitu te for M anufacturing & A utom ation Research. iii Contents A ck n ow led gm en t ii L ist O f F igu res vii A b stra ct ix 1 In tro d u ctio n 1 1.1 Background of the research ........................................................................ 1 1.2 The operational approach ........................................................................ 7 1.3 AutoConstrain: a prototype s y s te m ....................................................... 11 1.4 Organization of the d is s e rta tio n .............................................................. 17 2 R ela ted R esearch 23 2.1 Variational geometry . . ........................................................................ 24 2.2 Graphical c o n s tra in ts ................................................................................... 26 2.3 Solid modeling based on c o n stra in ts....................................................... 28 2.3.1 O perational transform ations ..................................................... 29 2.3.2 Logic in fe re n c in g ............................................................................. 30 2.4 Constraint research in A I ........................................................................ . 32 2.4.1 Geometric reasoning in kinem atic a n a ly s is ............................... 32 2.4.2 Constraint satisfaction as search p ro b le m .................................. 33 2.4.3 Planning with c o n s tr a in ts ............................................................ 34 3 A n O p eration al C on strain t M o d el 35 3.1 A nalytic interpretation of c o n s tra in ts ................................................... 36 3.2 M anipulating geom etry by o p e ra tio n s ................................................... 37 3.3 Satisfying a constraint by o p e ra tio n ....................................................... 39 3.4 M aintaining a constraint by o p e r a tio n s ................................................ 41 3.4.1 Constraint preserving operations ........................................ 43 3.5 An operational constraint m o d e l.............................................................. 44 3.5.1 The knowledge base ...................................................................... 45 3.5.2 The satisfaction m e c h a n is m ........................................................ 48 iv 4 S a tisfa c tio n P la n n in g 4.1 A bstract view of satisfaction p la n n in g ................................................. 4.2 The outline of the planning a lg o rith m ................................................. 4.3 G raph representation of c o n s tra in ts .................................................... 4.4 Geometric r e a s o n in g ................................................................................ 4.4.1 Selecting proper objects to change ............................... 4.4.2 Selecting proper operations .................................................... 4.5 O peration p ro p a g a tio n ............................................................................ 4.5.1 Example 1: Enforcing operation to an o b je c t..................... 4.5.2 Example 2: Imposing a constraint to a constraint network 4.6 O peration propagation w ith b ack track in g .......................................... 4.6.1 An example of backtracking in p ro p ag atio n ........................ 4.6.2 Preprocess constraint n e tw o rk ................................................. 5 L o o p A n a ly sis 5.1 W hy loops o c c u r ....................................................................................... 5.2 A necessary condition for loops ........................................................... 5.3 W hen a loop is signaled ......................................................................... 5.4 Loop re s o lu tio n .......................................................................................... 5.4.1 Loop tra c in g ................................................................................... 5.4.2 Equation generation .................................................................. 5.4.3 Equation s o lv i n g ......................................................................... 5.4.4 O peration assem b ly ..................................................................... 5.4.5 Propagation back to the constraint n e t w o r k ..................... 5.5 Examples of loop r e s o lu tio n .................................................................. 5.5.1 An example of arranging c ir c le s ............................................. 5.5.2 An example of arranging a circle in a t r i a n g l e ................. 5.5.3 The example of mechanism a n a ly s is ...................................... 6 Im p le m e n ta tio n 6.1 O bject-oriented c o m p u tatio n .................................................................. 6.2 The program m ing environment: Oar ................................................. 6.2.1 Oar e n v iro n m e n t......................................................................... 6.2.2 Favorable features of Oar for im plem entation..................... 6.3 C onstraint rep resen tatio n......................................................................... 6.3.1 I n h e r ita n c e ................................................................................... 6.3.2 Representing constraints’ local know ledge............................ 6.3.3 Macro c o n stra in ts......................................................................... 6.4 Equation s o lv e r .......................................................................................... 6.5 Loop a n a ly z e r.............................................................................................. 6.6 User interface d e s i g n ................................................................................ 6.7 Lim itations of the im plem entation........................................................ 51 51 53 55 57 58 59 62 64 65 66 71 72 73 74 75 77 77 79 83 88 89 92 96 97 99 102 106 107 108 109 ! 113 114 116 116 118 120 121 j 122 124 1 R eferen ce L ist 126 A p p en d ix A Macro D efinitions.........................................................................................................128 A .l Type sy ste m .........................................................................................................128 A.2 Geometric o b je c ts ............................................................................................. 129 A .2.1 P ath specification................................................................................ 131 A.2.2 Compound o b j e c t s .............................................................................131 A.3 Constraint types ............................................................................................. 132 A .3.1 Prim itive c o n s tr a in ts ......................................................................... 133 A .3.2 Macro c o n stra in ts................................................................................ 133 A.4 O p eratio n s........................................................................................................... 136 A.4.1 Prim itive o p e r a tio n s ......................................................................... 136 A.4.2 Macro o p e ra tio n s ................................................................................ 136 A p p en d ix B A Case S t u d y ............................................................................................................... 140 B .l A design p r o b le m ............................................................................................. 140 B.2 Satisfaction p ro c e s s ..........................................................................................141 B.3 D iscu ssio n ...........................................................................................................148 j List Of Figures 1.1 Examples of geometric constraints.............................................................. 4 1.2 T he diagram of the satisfaction m echanism ............................................. 15 1.3 The design of a 3-blade fan using A utoC onstrain.................................. 16 1.4 A variation of the fan under the same constraints................................. 20 1.5 The fan and th e underlying constraint m arks....................................... 20 1.6 A mechanical part and the underlying constraint m arks................... 21 1.7 A variation of th e previous part w ith all holes tangent to its cir cum ference......................................................................................................... 21 1.8 A linkage m echanism and its underlying constraint network. . . . 22 1.9 A nim ation of the linkage mechanism under continuous movement. 22 3.1 Param eters of a slotted block....................................................................... 39 3.2 Different ways to satisfy a constraint......................................................... 40 3.3 M aintaining constraints................................................................................ 41 3.4 Constraint preserving operations............................................................... 43 3.5 The diagram of the satisfaction m echanism ............................................. 49 4.1 The abstraction of the satisfaction planner.............................................. 53 4.2 G raphical representation of constraint and operations......................... 55 4.3 A configuration with constraints interacting......................................... 56 4.4 Examples of application of Heuristic 1....................................................... 58 4.5 Examples of application of Heuristic II..................................................... 60 4.6 M aintain constraints in the context of other constraints................... 61 4.7 An exam ple th at requires operation propagation................................... 62 4.8 An abstract view of operation propagation.............................................. 62 4.9 Changing location of vertex p i ................................................................... 64 4.10 O peration propagation of Example 1....................................................... 64 4.11 Imposing a new constraint colinear.......................................................... 65 4.12 O peration propagation of Example 2....................................................... 66 4.13 An example of propagation failure............................................................ 67 4.14 O peration propagation th a t fails............................................................... 68 4.15 Steps of backtracking..................................................................................... 71 vii 4.16 Backtracking in propagation....................................................................... 72 | 5.1 A propagation loop exam ple....................................................................... 74 ' 5.2 O peration propagation in the constraint netw ork................................ 75 5.3 Loop resolution diagram ............................................................................... 79 5.4 An example for tracing constraints and operations in a loop. . . . 81 5.5 The d ata structure established during the propagation..................... 82 5.6 Examples of translating operations into equations.............................. 85 f 5.7 Fix an vertex of a triangle........................................................................... 86 5.8 Fixing a vertex of a triangle indirectly.................................................... 86 5.9 Choosing proper objects to fix................................................................... 87 5.10 The control flow for equation generation................................................ 88 5.11 Assemble operation from previous and current positions.................. 91 5.12 Assemble operation from previous and current positions.................. 92 5.13 The constraint network and the propagation process......................... 93 5.14 An example of a recursive loop handled in isolation........................... 94 5.15 The propagation process.............................................................................. 94 5.16 An example of a recursive loop which cannot be handled by isolation. 95 5.17 An example of a m ultiple loop which cannot be handled w ith iso- : lation...................... 95 5.18 T he example w ith a more com plicated initial configuration............ 96 , 5.19 The constraint network and the operation propagation 97 ' 5.20 Propagation to th e rest of the constraint netw ork............................... 99 5.21 An exam ple of loop resolution........................................................................100 5.22 The constraint network and the operation propagation........................ 100 5.23 Propagation to the rest of th e constraint netw ork.................................. 102 5.24 A linkage m echanism consisting of rigid segments and joints. . . . 102 j 5.25 O peration propagation in the constraint netw ork................................... 103 ! 5.26 Propagation to the rest of the constraint netw ork.................................. 105 i A .l A m acro operation th at trim s the corner formed by two lines. . . 148 ; B .l A design problem (1).....................................................................................151 B.2 A design problem (2).....................................................................................152 ' B.3 A design problem (3).....................................................................................152 ' B.4 A design problem (4).....................................................................................153 i B.5 A design problem (5).....................................................................................154 B.6 A design problem (6).....................................................................................156 B.7 A design problem (7).....................................................................................157 B.8 A design problem (8).....................................................................................158 vm Abstract This thesis presents an operational approach for geometric constraint sat isfaction, especially in the context of com puter-aided geometric design where satisfying geom etric constraints is a m ajor concern. In this approach, geomet ric constraints are defined in term s of operations which are used to satisfy and m aintain the constraints. Constraints imposed on a given geom etry are satis- I j fied increm entally by planning a sequence of operations, which, when executed, j will satisfy all the constraints simultaneously. The consistency of a constraint J I network is achieved by propagating operations through the network. Geometric 1 1 ! reasoning is used in the satisfaction planning stage to help generate robust and I i I efficient plans. A coherent m ethod to handle circular dependencies of constraints is developed and coupled w ith the satisfaction mechanism to localize constraints to be relaxed instead of the relaxation of the entire constraint network. The approach is based on the high-level semantics of geometric constraints and the geom etric im plications of operations, thereby avoiding the deficiencies caused by ! solving geometric constraints as a system of algebraic equations. Chapter 1 Introduction Recently, constraint-based problem solving has received m uch attention in a va riety of fields, including com puter-aided design and m anufacturing, artificial in telligence, graphical layout, kinem atic analysis, user interface design, simulation analysis, and general program m ing languages. This dissertation is concerned with constraint representation and satisfaction, especially in the field of computer- aided geom etric design. This chapter introduces the background of the research, defines the problem to be solved, and outlines the work presented in the rem ainder of the dissertation. | 1.1 Background of the research i j C onstraints represent relationships th at m ust hold among several objects. A va- | ! riety of problems can be best form ulated as a set of constraints which m ust be 1 satisfied. Problem solving, therefore, occurs by means of constraint satisfaction, through the process of actually satisfying the set of constraints. Geom etric prob lem solving, like com puter-aided geometric design, often involves m anipulating geometric forms (such as lines, curves, surfaces) to satisfy certain constraints (such as parallelism , tangency, colinearity, and other dimensional constraints). t I C onstraint-based design refers to the research and development area where ap- ; * I proaches and systems are developed to autom ate design processes through the use j t of constraint satisfaction techniques. This dissertation presents an operational approach for constraint satisfaction w ithin th e context of constraint-based design, based on the high-level semantics of constraints and the geom etric im plications of operations. Relevant to the present operational approach are the concepts of general constraint satisfaction problem, geometric constraints, constraint-based design, and the lim itations of existing approaches, which are discussed below. G e n e ra l C o n s tra in t S a tis fa c tio n P ro b le m . Most constraint problems I can be form ulated as a set of variables and a set of relations for which these I variables m ust satisfy. Constraint satisfaction is the process of com puting a set ! of assignments for these variables th at satisfies all the constraints. The forms 1 of assignments depend on the variable domain. For instance, assignments for | i num eric variables may be real num bers or integers; for solid geom etric objects, ; the assignments m ay be locations and orientations of the objects; and for assembly j 2 I planning, th e assignments may be a sequence of assembly operations. In general, constraint satisfaction problems can be form ulated as follows: • A set of variables V = {tq, V2 , ..., n„}, where Vi E D{ (D{ is th e dom ain of vf), * = 1 , 2 , • A set of constraints C = {cj, C 2 , ..., em}, where C { C D\ x D 2 x ... x Dn (et - is a relation of Tfi x Z) 2 x ... x -Dn)> * = 1 , 2 , • A solution to the constraint problem is a tuple of assignments v \ , n'2, ..., v'n for i?i, u2, ..., vn such th at (v \, w'2, ..., E C\ fl c2 f l ... D cm. For example, let the set of variables V — {x-i, a:2 , 0:3 , X 4 }, where Xi E I (I is I the set of positive integers, i = 1 , 2 , 3,4 ), and let constraint set C = { ci,c 2 ,cs}, J where ci, c2, c3 are defined as: c\ : x l + x2 = x3, c2 : x2 * x3 = 4, c3 : x2 + x3 < j I t xA. For this simple problem, one of th e solutions is (3,1,4, 3). U nfortunately, \ I an arbitrary constraint satisfaction problem is not always solvable. M any open j conjectures in Num ber Theory can be considered as integer constraint problems, ! for instance, F erm at’s last theorem (x n + yn — z n, x, y, z, are positive integers, 1 I n > 2). Some others are solvable, but are NP-Com plete. For example, the 1 1 problem of finding a tru th assignment for a collection of clauses {ci, c2, ..., cmj on ! a finite set U of variables can be reduced to 3-SAT. Building a general constraint I satisfaction mechanism is a hopeless task. However, restricted to some domains, m any constraint problems can be solved reasonably w ithin a polynom ial bound. bl si (a) (b) il c3. p 4 Cl (d) Figure 1.1: Examples of geometric constraints. G eo m etric C on strain ts. This dissertation is particularly concerned with th e representation and satisfaction of geometric constraints. Geom etric con- | ! I straints capture a wide range of relationships th at have a geom etric interpre tation. In geometric design, constraints often involve configurations composed of j geom etric entities such as points, lines, curves, planes, cylinders, conics, blocks, slots, and other geom etric forms. Examples of geom etric constraints are con straints th a t require one line to be parallel to another, one cylinder to be tangent i to a plane, two objects to be sym m etric w ith respect to an axis, two cylinders to be coaxial, and a paragraph to be laid out at the center of a rectangle. Geometric I I constraints can be used to represent both dimensional and functional relation- j ships of geom etric entities. Figure 1.1 illustrates several examples of geometric ! constraints. The meanings underlying them are provided below. j i • Figure 1.1(a) is a constraint th a t requires block b l to fit into slot s i. j • Figure 1.1(b) is a constraint th at requires angle a l to be equal to angle a2. • Figure 1.1(c) is a constraint th a t requires the centers of three circles c l, c2, c3 to be co-linear and a constraint th a t line 11 be tangent to both c l and c3. • Figure 1.1(d) involves a constraint th a t anchors point p i, a constraint th at the distance between p i and p3 be a constant (i.e., making ( p l,p 3 ) a rigid segm ent), a constraint th a t p2 can slide in between p i and p3, and a ! i constraint th a t joins two rigid segments (p 2 ,p 4 ) and (p 4 ,p 5 ) at point p4. C o n s tra in t-B a s e d D esig n . Geom etric constraints can be form ulated in m any domains where geom etry plays a role in com putation. T he present research is in the context of com puter-aided geometric design where satisfying geometric constraints is a m ajor concern. In m echanical design, for example, designers al ways bear in m ind a set of geometric constraints in the process of sketching a mechanical part. Conceptually, design is a refinement process, in which designers refine their designs by introducing constraints incrementally. Conventional CAD systems cannot autom atically satisfy and m aintain a set of constraints. Existing systems usually allow designers to create configurations th at satisfy certain con- | straints, for instance, a line tangent to an existing circle. However, it is up to ! designers to carry out the task of m aintaining the set of constraints which they j have imposed. This becomes difficult when designs get com plicated. It has been a challenging goal to build systems th a t autom ate this conceptual process. L im ita tio n s o f th e E x is tin g A p p ro a c h e s. Traditionally, geometric con straints have been interpretated analytically. A set of constraints is translated into a system of algebraic equations involving variables th at characterize the coordinate geom etry [6, 13, 12]. Falling into the dom ain of analytic geometry, ge om etric constraint satisfaction becomes the problem of finding an assignm ent for these variables th a t satisfies the constraints. This often requires solving a system of sim ultaneous equations, either num erically or symbolically. This paradigm , though appealing for its sim plicity of control, suffers from a num ber of problems. First, solving a system of equations num erically is not robust. In practical design systems, curved objects result in a system of non-linear equations, and to solve th e system of equations usually requires some iterative num erical m ethods. Exist ing num erical m ethods, such as the Newton-Raphson m ethod, cannot guarantee to find a solution even if one exists. Besides, iterative m ethods are inefficient because they depend on an initial vector to converge. However, there is no gener ally accepted way to choose a good initial vector. Therefore, these m ethods often behave unpredictably. In addition, solving equations often ends w ith a solution th a t is not intuitive w ith respect to th e original geometry. For example, adding j a new constraint, which should have only local effects on a design, m ay result in a solution which is totally different from the original design. 6 Recently, to avoid the problems of converting constraints into systems of equa tions, alternative approaches have been proposed and tested based on geometric interpretation of constraints [15, 16, 9]. The m ain idea behind such work is to use dom ain knowledge to guide equation solving at high levels so th a t equations can be solved in a decoupled fashion. However, these approaches are restricted to a specific dom ain or used in ad hoc ways (some of this work is reviewed in C hapter 2). T h e P r o b le m S ta te m e n t. This paper focuses on the geom etric constraint satisfaction problem as defined below. I Given a set of geometric objects (o i, 0 2 ,..., on} and a set of constraints {ci, C 2 , ..., cm}, find a configuration (a set of dimensional assignments) for Oi, 0 2 , on such that all c 1 ? C2 , . . . , c m are satisfied simultaneously. 1.2 The operational approach The analytical view of geometric constraints is more useful for its verification th an for its satisfaction of constraints. There are two drawbacks to relying on this analytic interpretation to satisfy a set of constraints: 1) geom etry is es- 1 sentially ignored in th e com putation, and 2) it is not obvious how constraints interact geom etrically because the interactions of constraints are represented im plicitly through sharing variables in algebraic equations. Thus, one is m otivated 7 1 I to develop a system atic approach th a t incorporates geom etric knowledge into J I I constraint satisfaction process. | O p e r a tio n a l S e m a n tic s o f C o n s tra in ts . The operational approach pre sented in this dissertation is m ainly based on the operational sem antics of con- ! straints as conceptualized below: j I I I • Geom etric constraint satisfaction can be used to m anipulate geom etry prop- ! erly to satisfy constraints imposed on the geometry. • Geom etry can be viewed as composition of geometric objects th a t are sub ject to m anipulations by a list of operations. O perations are well-defined j i functional procedures designated to m anipulate objects in a m eaningful j i way. ! i • A constraint can be associated w ith operations to satisfy and m aintain it, j each of which, when invoked, will satisfy or m aintain the constraint. • A set of constraints is satisfied increm entally. A new constraint is satisfied in the presence of other satisfied constraints through planning a sequence ! of operations. • The satisfaction planning is carried out by propagating operations through a constraint network. 8 • Circular dependencies of constraints are tracked in operation propagation processes to localize equation solving. • Geom etric reasoning is used in the propagation process to help generate a m ore efficient and robust sequence of operations. A set of geometric heuristics is employed in the reasoning mechanism. S a tisfa ctio n P la n n in g . C onstraint satisfaction can be considered as a plan ning problem. The goal is to satisfy a set of constraints and the satisfaction of each constraint in the set is treated as a conjunctive subgoal. The initial state of the problem is a set of unsatisfied constraints and th e final state is a set of satisfied ones. Satisfaction planning is a process of generating a sequence of op erations such th a t the execution of the sequence of operations will transform the initial state to the final state. An increm ental paradigm is adopted in satisfac tion planning. C onstraints are satisfied increm entally in the presence of other satisfied constraints. Increm ental satisfaction is suitable for applications where constraints become available increm entally, such as in a geometric design in which designs are refined by increm entally imposing new constraints. Increm ental ap proaches satisfy a constraint in the context of a constraint network through local m odifications, which reduce the com plexity of im m ediately dealing w ith a whole set of constraints and often results in a solution m ore intuitive w ith respect to 9 ------------------------------------------------------------------------------------------------------------------------------------------- the previous solution. The satisfaction planning process consists of three parts: operation propagation, geom etric reasoning, and circular dependency analysis. • O p e r a tio n p ro p a g a tio n . Increm ental satisfaction often involves resolv ing conflicts arising from satisfying a new constraint. Because in m any cases constraints are interdependent, this implies th a t th e satisfaction of a con straint m ay violate other satisfied ones. The planning algorithm achieves consistency of a constraint network by propagating operations through the constraint network. Satisfaction planning is initiated when operations are ) generated due to imposing a new constraint or simply altering a geometry. 1 I The result of the planning process is a partial ordering of operations, which i can be organized into a sequence of operations to be executed. i j i • G e o m e tric re a so n in g . T he propagation algorithm proceeds in a local t m anner. This property allows one to perform some local optim izations using ' geom etric heuristics. These heuristics are based on the locality of geometric I i constraints, which means th a t adding a new constraint into a constraint | network usually has only local effects on the network. T he objective is ! to minimize the local effect of an operation generated from a constraint j firing w ith respect to th e directly-related constraints, thereby reducing the am ount of changes required to m aintain the affected constraints. Inherent in th e constraint satisfaction m echanism, this objective is approached in 10 two ways: 1) when there are alternative objects to change, th e one th at has less effect on related constraints should be chosen; and 2) in regard to the selected object, an operation th a t has less effect on related constraints should be selected. • C irc u la r d e p e n d e n c y a n a ly sis. O peration propagation is essentially a local approach. It m ay fail to solve some problems th a t have circular | I I dependency among constraints. In such cases, operation propagation gets j i into a loop. Loop cases may involve either constraints th a t require global coordination or inconsistent constraints. Instead of relaxation of the whole constraint network by num erical m ethods, as other approaches often do, one can localize constraints involved in a loop, relax them , and then propagate th e solution in term s of operations back to the constraint network. A m ajor portion of this dissertation is devoted to detailed technical discussions of this approach, through various examples. j 1.3 AutoConstrain: a prototype system i i I An experim ental system , called AutoConstrain, is coded as a test-bed for the pro posed approach. The system allows for two-dimensional sketch drawings based on constraints. One can interactively create geom etric objects and specify con straints; the system will satisfy and m aintain the set of constraints autom atically. 11 I m p le m e n ta tio n M e th o d . An object-oriented paradigm is adopted in the ] I i im plem entation process. Constraints are m odularized into objects w ith their local knowledge — operations to satisfy and m aintain them selves — being imple m ented as their com puting m ethods. O peration propagation is naturally incor porated into the system ’s message passing mechanism. Some global coordination functions are achieved by having a blackboard architecture and several system objects serving as coordinators. The code is w ritten in O ar— an object-oriented program m ing environm ent w ith symbolic reasoning capabilities [1]. C o n s tra in t R e p r e s e n ta tio n . C onstraint types are treated as objects of ! Oar and are represented by object symbols and a set of predicates involving the object symbols. For a constraint type, two classes of predicates involving its object symbol are of im portance: 1. c o n s tr a in e d _ p a r t(cstr, i , obji) specifies th a t the ?th participant of con straint type cstr is obji (obji is an object symbol representing an object type). This class of predicates declaratively defines the structure of a con straint type. For example, the structure of constraint type tangent (con straining a line and circle to be tangent) can be defined by two predicates: j ! c o n s tr a in e d .p a r t{tangent, 1, line) and c o n s tra in e d _ p a rt(fa n g ,en£, 2, j ! circle). j 12 2. m e th o d (c s ir , m ethodjnam e, p a r a # , procjname) specifies th a t constraint cstr has a m ethod m ethodjnam e which is im plem ented as a procedure nam ed procjname w ith p a r a # param eters. This class of predicates defines the behavior of a constraint type in response to a message at run-tim e. For instance, tangent has a m ethod s a tis fy defined as: m e th o d (tangent, I s a tis fy , 3, p r o c s a tis fy ). At run-tim e, when tangent receives a message j to invoke its s a tis fy m ethod, it will invoke procedure p r o c s a tis fy which j will satisfy th e constraint by properly m anipulating the line and the circle. As will be discussed in the following chapters, a constraint type is defined in term s of operations used to satisfy or m aintain the constraint. In the Oar j environm ent, a constraint type can be specified by associating m ethods w ith an j object symbol. These m ethods can be im plem ented at two levels: the m ethod j level and the m ethod procedure level. At the m ethod level, alternative operations and their preconditions under the same m ethod nam e can be im plem ented by different procedures. For example, tangent may have three different ways to satisfy itself, and therefore, can be represented by three different m ethod clauses. Second, at the m ethod procedure level, the preconditions of some operations m ay require extensive com putation and sophisticated control structures. They ] i should be im plem ented inside th e m ethod procedure because com puting facilities and control constructs are more readily available in procedural languages. In general, th e abstract knowledge of a constraint should be represented explicitly 13 at th e m ethod level; while the specific and com putation-dom inant part should be i I im plem ented at th e m ethod procedure level. The general form at of a constraint’s 1 m ethod procedure is depicted below. procjnam e(pari, par2, ..., park) I char *pari, *par2, ..., *park; j I I I local — reasoning — and — computation; j operation — form ation; j i operation — propagation; J i i I i i In h erita n ce. In th e Oar environm ent, there is no distinction between a constraint type and an instance of the type. A constraint type is a prototype of an instance of the type. An instance of a constraint type can be declared by using isa predicate. For instance, X isa Y declares th a t X is an instance of Y , and X will inherit all predicates involving Y . This is ensured by a special isa inference rule of Oar. S a tisfa ctio n M ech a n ism . T he satisfaction m echanism is th e functional part of th e system. The infrastructure of th e m echanism is illustrated in Figure 3.5. The m echanism is prepared for two scenarios: 1) satisfying a new constraint c i in 14 O ps c i / o p K n o w le d g e E q u a t io n S o l v e r I n p u t s O u tp u t Figure 1.2: The diagram of the satisfaction mechanism. th e presence of a set of satisfied constraints Sn, and 2) m aintaining a set of con straints Sn upon an incoming operation op. In both cases, the m echanism gener ates a sequence of operations which will satisfy th e constraint or m aintain th e set of constraints when executed. The mechanism has four m ajor com ponents: sat isfaction planner, constraint knowledge base, loop analyzer, and equation solver. Their functions are explained below. • Satisfaction Planner is th e core of the mechanism. It is responsible for planning a sequence of operations upon inputs. It interacts w ith other three com ponents in the planning process. It is discussed in m ore detail in C hapter 4. • Knowledge Base stores the inform ation about constraints and th e associated operations which satisfy and m aintain them . It is accessed by Satisfaction Planner. 15 tirjp_rmt/auto/lxpazrx/bwang/esample2 Tools Utility Cons G ®j 0 □ a O o \ T Macrd pbjecj u < P < <y © o 1 Itfiult Figure 1.3: The design of a 3-blade fan using AutoConstrain. • Loop Analyzer handles special cases due to circular dependencies of con straints. It invokes Equation Solver when necessary. It is discussed in more detail in Chapter 5. • Equation Solver solves a system of equations. It is discussed in Chapter 6. F eatu res o f A u to C o n stra in . AutoConstrain has following features: 1) interactive creation and editing of objects with or without constraints, 2) auto matic satisfaction of constraints, 3) interactive editing of the constraint network j by graphical means, and 4) animation of the constrained configuration under continuous movement. S cen arios. Some scenarios of th e system are shown through several screen- dumped. pictures. Figure 1.3 shows th e design of a 3-blade fan where th e three blades are constrained to be sym m etrically placed around a circle. Each blade is a closed spline w ith the same point constrained at th e axis of the fan. This configuration is created by merging control points of the splines w ith the proper vertices of two co-centered regular polygons. W ith all the constraints, this config uration can be easily edited by moving a control point on one of the blades, and the system will change the other two autom atically. Figure 1.4 shows a variations of the fan under the same set of constraints. The constraint network underlying the design is illustrated in Figure 1.5. Figure 1.6 shows the design of a m echanical p art and its underlying constraint network. A variation of the p art is shown in Figure 1.7 where all the circles are moved to be tangent to the circum ference of the part. Figure 1.8 defines a linkage mechanism and the underlying constraint network. Figure 1.9 is an anim ation of the linkage m echanism under continuous movem ent. 1.4 Organization of the dissertation The rem ainder of th e dissertation is organized as follows. • C hapter 2 is a review of previous research pertinent to the present study and a comparison of past approaches w ith the present one. 17 • C hapter 3 is a presentation of an operational m odel for representing con straints in term s of operations. In th a t m odel, geom etry is treated as a set of geom etric objects subject to m anipulation by operations. Each con straint type is associated w ith proper operations to satisfy and m aintain them . A set of constraint types, defined in a specific application dom ain, constitutes a knowledge base which is used to solve problems expressed as com binations of constraint instances. • C hapter 4 is a discussion of the corresponding satisfaction m echanism th a t accesses th e constraint/operation knowledge base to solve problems. Con straint satisfaction is the process of generating a sequence of operations, and the execution of the sequence of operations will satisfy all the constraints underlying a given geometry. O peration propagation distributes operations through a constraint network and geom etric reasoning optim izes the local effects of constraint firings. i • C hapter 5 is a presentation of a coherent m ethod to resolve propagation loop encountered in satisfaction planning. The m ethod localizes constraints involved in a loop, relaxes them , and then propagates th e solution in term s i i of operations back to the constraint network. j 18 C hapter 6 includes a discussion of an object-oriented paradigm adopted I I f in the im plem entation of A utoConstrain. An object-oriented environm ent J Oar is introduced. I I C hapter 7 is a sum m ary of th e dissertation and includes recom m endations for future research. ! I t I ? f t I 1 1 f t 1 t f ( f I t t I t I nt t t < I T t 1 I t f f t 1 I I * t I I t Figure 1.4: A variation of the fan under the same constraints. a K Figure 1.5: The fan and the underlying constraint marks. 20 Figure 1.6: A mechanical part and the underlying constraint marks. Figure 1.7: A variation of the previous part with ail holes tangent to its circum ference. 21 rr- i i i i I \ i i i 1 t i r i I i i t I I < ' i i I - n r t I I i t i I I < i I I I I i i i I i t Figure 1.8: A linkage mechanism and its underlying constraint network. I I I . I i i I r I i i i ■ I I ' I i I ■ > ' ' I t » i I I t I I 1 r 1 ' I ' 1 i 1 & : * v , v . m * * » v . « t v & I f ivv. m m Figure 1.9: Animation of the linkage mechanism under continuous movement. 22 Chapter 2 Related Research Research on constraint-based systems m ay be traced to early sixties when Ivan Sutherland pioneered the use of constraints in Sketchpad — a com puter system for interactive drawings. Since then, there has been a growing interest in studying various aspects of constraints, particularly in th e field of artificial intelligence. U ntil recent years, intensive research has gone into both theoretical study and practical im plem entation of constraint system s, and it has covered a wide range of fields, including artificial intelligence, graphical layout, com puter-aided design j and m anufacturing, kinem atic analysis, assembly planning, user interface design, I sim ulation analysis, and general program m ing languages. This chapter is a review j of previous research pertinent to th e present study and a com parison of past i I approaches w ith the present one. 1 23 2.1 Variational geometry M echanical design is a dom ain in which geom etry plays a central role. T he use of constraints for com puter-aided design is directed at relieving th e burden of designers by having com puters satisfy and m aintain constraints imposed on a given geometry. Early theory regarding how to combine geom etry and dimensions to specify the shape of a m echanical p art was set forth by Hillyard and B raid [6]. They provided a m ethod to determ ine w hether a com ponent is under, over, or exactly defined by a given dimensioning scheme. Based on th e theory of Hillyard and Braid, Gossard and Lin developed a m ethod for two-dimensional sketch design [13, 12], later known as variational geometry. V ariational geom etry is a m ethod th a t represents a sketch design by a set of characteristic points. T he dimensions are treated as constraints lim iting th e perm issible locations of these character istic points. A given dimensioning scheme is described by a set of dim ensional constraints. Each constraint is represented by a nonlinear equation involving the coordinates of associated characteristic points. T he geom etry corresponding to a dim ensioning scheme is found through the sim ultaneous solution of the set of j equations. C ertain techniques are used to identify invalid dimensioning schemes and to im prove the efficiency of solving equations [14]. 24 Serrano and G ossard’s M CAE system is an extension of variational design. M CA E is a constraint-based environm ent for M echanical C om puter A ided Design [17]. C onstraint networks are represented as directed graphs, where nodes repre sent param eters and arcs represent constraint relationships. A b ip artite m atching algorithm is developed to generate param eter dependencies autom atically. Con straint networks are evaluated based on the param eter dependencies to detect over- and under-constrained system s and to identify and correct redundant or conflicting constraints. A variational approach essentially depends on num erical iterative m ethods to solve a system of non-linear equations. It often ends w ith a large am ount of I j com putations when th e num ber of equations and variables grows rapidly with the num ber of geom etric constraints. Num erical iterative m ethods require good starting points to converge and are often inefficient for non-linear equations. In j addition, the non-uniqueness of the resulting geom etry makes it hard to choose i the intended one. [ T he operational approach used in the present research can serve as a b ette r al ternative to variational geometry. F irst, geometry, and constraints to be im posed on it, are represented and satisfied at a higher level. In m ost cases, this avoids solving a whole system of equations and thus, is m ore robust and less expensive in com putation. Second, alternations to a geom etry are local and intuitive w ith 25 respect to th e previous configuration because constraints are satisfied increm en tally through local propagation. In addition, satisfaction plans generated for a I I geom etry can be reused for other geom etries w ith dim ensional variations. 2.2 Graphical constraints T he advent of com puter graphics opened another window for com putation which allowed th e drawing of graphical objects on com puter screens. A pplications, such as graphical layout and sim ulation, often require th a t drawings satisfy constraints which, in m any cases, are geometric, such as a constraint th a t requires a line i J perpendicular to another and a constraint th at a tex t string lies at th e center of j rectangle. C onstraint systems are expected to carry out th e task of autom atically I t satisfying constraints and m aintaining th e existing ones. T he early work of Ivan Sutherland pioneered th e use of interactive com puter graphics w ith constraints in his system Sketchpad [21]. Sketchpad was a general- purpose drawing system th a t allowed the definition of arbitrary graphical objects and constraints. A user interacted w ith the system using a light-pen to position parts of the drawings on th e display and a point to change them . A user speci fied th e constraints th a t the drawings m ust satisfy, and Sketchpad?s satisfaction m echanism perform ed the changes. Sketchpad allowed a user to define new kinds of drawings by composing prim itives and other user-defined drawings. It was also noticeable for its ring structure for storing the topologies of drawings. Although Sketchpad was built 30 years ago, m any of its design principles still influence current graphics system design. B orning’s Thinglab followed roughly the p ath of Sketchpad. Thinglab is a gen eral sim ulation system based on constraints [2]. It provides an object-oriented environm ent for building sim ulations where part-w hole and inheritance hierar chies are used to describe th e structure of a sim ulation and constraints are used to express the relations am ong its parts. Thinglab aim ed to design and im plem ent a language th a t facilitates the specification of complex sim ulations. A user can specify all the relations independently among th e p arts of a sim ulation, leaving them to the system to plan exactly how constraints are to be satisfied. Zabala-Salelles’s GOB system (G raphic OBjects) was an interactive system designed to m anipulate tex t and pictures uniform ly [24]. C onstraints were used to specify positioning inform ation in declarative form to facilitate graphical edit ing operations. GOB allowed dynam ic addition and deletion of constraints. The screen was u pdated increm entally — only parts of it were redraw n after each editing operation because th e system of constraints specified precisely which re gions should be changed by an editing operation. G OB also featured m ultiple representations of objects by keeping th e contents of th e objects separate from i their form ats. 27 Gosling’s thesis was devoted to an investigation of algebraic constraints by graph transform ation techniques [5]. An experim ental system called M argritte | was developed through an interactive graphical layout environm ent. T he locality of satisfaction algorithm s was pursued. T he m ajor portion of his work con cerned the techniques for transform ing networks of constraints into forms th a t are tractab le using simple satisfaction algorithm s. M argritte was characterized by its use of breadth-first search to plan propagation and its use of transform ation I to break loops. The constraints dealt by M argritte were arb itrary equations in conventional algebra. 2.3 Solid modeling based on constraints Advanced solid-modeling techniques have m ade th e representation and m anipula tion of 3-D objects possible in a num ber of com m ercially available solid modelers. In these system s, complex objects are created by carefully composing prim itives to satisfy th e constraints among them . In a CSG-based modeler, for exam ple, a complex object is represented by a graph of set operations and prim itives. The locations of prim itives are positioned properly using rigid transform ations. Be cause all constraints are im plicitly satisfied in the creation process (in term s of ! param eter values of rigid transform ations), the editing of an o bject’s specification I ! I , is m ade extrem ely difficult. Param eterization of solid models facilitates th e cre ation of objects w ith small variations, b u t the evualtion of constraints is lim ited in one direction. O ther solid representation schemes encounter sim ilar situations. To solve th e problem , research efforts have been p u t in to introducing constraint m echanism into a solid modeler. 2.3.1 Operational transformations i Rossignac et al. proposed a way to facilitate specification and editing of param e terized solid models under CSG representation [15, 16]. Their m ain concern was to specify positions and dimensions of solid prim itives in term s of geom etric con- j straints instead of param eters of rigid m otions. A user defines a solid m odel by j i specifying a CSG graph and a sequence of m otions to operate on th e collections | i I of prim itives. T he rigid motions are stored in term s of unevaluated constraints on graphically selected boundary features; when needed, these constraints are evaluated sequentially in a user-specified order. i Rossignac et a V s m ethod is lim ited to solving design problem s w ithout simul taneous constraints. For it to be of practical use, sim ultaneous constraints m ust be handled properly. In addition, the m ethod depends fully on users to specify a sequence of rigid transform ation to evaluate constraints. T he validity of the sequence of operations is not ensured by the system , b u t left to users. O ther j i I l I 29 technical problem s also exist, for instance, editing a CSG graph m ay invalidate its p ath names. T he operational approach presented in this dissertation can be viewed as a generalization of Rossignac and others’ work. F irst, for each constraint imposed, a sequence of operations is autom atically generated by th e constraint satisfaction m echanism instead of by users. Second, sim ultaneous constraints are handled properly in th e current approach through operation propagation. Finally, the validity of the sequence of operations is checked dynam ically when executing the operations. 2.3.2 Logic inferencing j B ruderlin et al. developed a system to autom atically build 3-D geom etric objects defined by their topology and geom etric constraints [4]. A 3-D solid m odeler is j used as a graphic editor for sketching spatial objects and defining their topologies. 1 Sketched objects are dim ensioned by selecting points and entering values. The geom etric constraints are first evaluated symbolically by a constraint satisfaction | m echanism w ritten in Prolog. T he result of the symbolic evaluation is a set | of construction steps. In the second step, the symbolic solution is evaluated 1 num erically by procedures w ritten in Modula-2. K im ura and Suzuki [8, 7] presented a uniform fram ework for product model- ! ing where geom etric constraints capture a wide range of geom etric inform ation, such as dimensions, tolerances and assembly. They proposed a m ethod is pro posed th a t combines first-order predicate logic and an object-oriented approach to represent and satisfy geom etric constraints. In their fram ework, solid models are used to store products’ shape descriptions, and logical form ulae are used to represent geom etric constraints on th e elem ents of th e solid m odels, such as di mensions and tolerances. A logic inference engine reasons about these form ulae to generate new form ulae and to develop a solution th a t satisfies a set of constraints. Coupling logic fram ework w ith a constraint system facilitates th e declarative I representation of constraints, and other geom etric facts, and th e inferencing of j i i j their relationships. However, logical reasoning suffers from th e difficulty of com- , i I J puting th e param eter dom ain over which th e representation rem ains valid. For I exam ple, a boundary representation scheme is composed of geom etric descrip tions of boundary elem ents (face, edges, vertices) and a graph th a t captures their adjacency. Param eters are bounded to th e dimensions and relative positions of boundary elem ents. Changing these param eters m ay produce boundary elem ents th a t are not consistent w ith th e adjacent graph and, thus, result in an invalid boundary representation. In addition, com plete and robust logic system s are j j _ ! j hard to im plem ent. Some side effects m ay arise due to the incom plete implemen- J tatio n of logic system s such as Prolog, which adds ex tra costs in m aintaining the j J consistency of geom etric inform ation. 2.4 Constraint research in AI In recent years, constraint-based problem solving has drawn wide atten tio n in various areas of artificial intelligence. In particular, problem solving involving geom etric constraints has been established in a variety of areas such as kinem atic analysis, im age understanding, com puter vision and m olecular stru ctu re analy- i sis. C onstraint satisfaction paradigm is noticeable for its separation of problem ! specification (a set of constraints) and th e satisfaction m echanism (the procedure actually satisfying a set of constraints). Building a generic satisfaction m echa nism is hopeless. However, in a restricted dom ain, a well-designed satisfaction m echanism often perform s reasonably well, for instance, in kinem atic analysis of m echanism [9] and in protein structure analysis [3]. In some dom ains, there is no general rule for solving problem s or inform ation about a problem is inadequately supplied. In such contexts, heuristics are often used. j I I 2.4.1 Geometric reasoning in kinematic analysis K ram er’s research addresses the problem of finding the positions and orientations of a set of rigid bodies th a t satisfy a set of geom etric constraints, particularly I in kinem atic analysis [9]. He presented an approach called degrees of freedom | i I analysis th a t increm entally satisfies a set of constraints by generating a sequence | of actions to guide constraint equation solving, such th a t the equations are solved I 32 in a m axim ally decoupled fashion. He proved th a t th e planning algorithm used in generating those actions is com plete and canonical and has a com plexity of nlog(n) w here n is th e num ber of constraints. A program called T L A was w ritten j th a t kinem atically sim ulates m echanical linkages. \ I 2.4.2 Constraint satisfaction as search problem Brinkley et al. form ulated the problem of arranging a set of physical objects J I I according to a set of constraints as a geom etric constraint satisfaction problem (G CSP), in which th e variables are th e objects, the possible locations of the objects are th e possible values for th e variables, and constraints are geom etric relationships am ong the objects [3]. They present a m ethod to reduce th e search I space by refinem ent along two dimensions: 1) the num ber of objects is reduced | by th e refinem ent of th e structure, representing a group of objects as a single . ! . . . ' ] abstract object, and 2) the num ber of locations per object is reduced by applying I node and arc consistency algorithm s to refine th e accessible volume of each object. Heuristics are employed to control th e order of operations. 2.4.3 Planning with constraints M ark Stefik presented an approach to hierarchical planning th a t uses constraints to represent th e interactions between subproblems[19]. C onstraints are dynam ically form ulated and propagated during hierarchical planning and used to co- v ordinate the solutions of nearly independent subproblem s. T he approach was im plem ented in a com puter program M O LG E N , th a t plans gene-cloning experi m ents in m olecular genetics. A com panion paper [18] discusses th e use of levels to organize control knowledge, which Stefik referred to as m eta-planning — an approach th a t resorts to heuristic reasoning to com pensate for the lim itations of a system ’s knowledge base and, therefore, enhances th e power of th e planner. I ! ! 34 Chapter 3 An Operational Constraint Model T raditional representations of geom etric constraints, via equations involving co ordinate variables of geom etric objects, are based on the analytic interpretation of geometry. U nder such representations, geom etry is essentially ignored in the com putation. C onstraint satisfaction becomes a problem of finding a set of as- j i signm ents for variables th a t satisfy the equations, which often turns into solving a system of equations num erically or symbolically. In this chapter, an alternative approach is presented. Geom etry is represented as a set of geom etric objects which are subject to m anipulation by a list of operations. C onstraints are asso ciated w ith operations to satisfy and m aintain them and constraint satisfaction is th e process of planning a sequence of operations such th a t the execution of the sequence of operations will satisfy all the constraints underlying a given geometry. 35 3.1 Analytic interpretation of constraints G eom etric constraints are often incarnated into a coordinate system , where con straints are interpreted by algebraic equations involving coordinate variables th a t characterize a geometry. For exam ple, the constraint th a t requires two plane lines to be parallel can be defined by th e equation below: ( 2/12 - V t x ) { x 22 - ® 2l) - ( 2/22 - 2/2l)(®12 - ® l l ) = 0 (3.1) where Xij and yi3 are th e coordinate variables of the lines’ endpoints. For con straints th a t involve perm issible locations w ithin some ranges, th eir analytic in terpretations m ay contain inequalities. T he constraint th a t requires a point to lie in betw een two parallel planes, for instance, can be defined by two inequalities: A%x T B \y -J- C \z -j- D \ > 0; A 2x T B 2y T C2z T D 2 < 0 where A i, f?4 , C^, Z)4 are the coefficients of th e two plane equations. A nalytic interpretation of constraints provides a quick way to verify w hether constraints are satisfied or not by checking th eir equations. For exam ple, given a point at ( - 1 ,3 ,2 ) and two plane equations 2 x —3y+z-\-A = 0 and 2 x —3 y + z—10 = 0, one can check if th a t point is in between the two parallel planes by substituting the values into th e inequalities in (1.2) and evaluating them . In this case, the constraint is satisfied. Research which adopted an equation-solving paradigm for geom etric con strain t satisfaction dom inated thinking in the past. T he paradigm is essentially 36 based on the analytic interpretation of constraints: a set of constraints is tran s lated into a system of equations and th e equations are solved by various num erical j or symbolic techniques. Its drawbacks were discussed in section 1.3 of C hapter 1. i \ I i i 3.2 Manipulating geometry by operations j I < i T he m ajor failure of th e equation-solving paradigm resides in its ignorance of ! I the role of geom etry in satisfaction. G eom etric constraint satisfaction essen tially deals w ith interactions of constraints and a solution depends on the coor dination among th e interactions. In an equation-solving paradigm , interactions of constraints are represented im plicitly through shared variables in equations. This makes it difficult to see how constraints interact geometrically. As a result, previous system s often used global m eans such as relaxations to coordinate the interactions. A lternatively, by incorporating the role of geom etry into th e com putation, satisfaction can often be accom plished locally in a decoupled fashion. C onstraint satisfaction can be used to m anipulate geom etry to m eet certain requirem ents. One can view a geom etry as a set of geom etric objects which are subject to 37 m anipulation by operations. O perations, in the context of this research, are well- defined functional procedures which have effects on objects when applied to them . One can specify an operation by th e following syntax: opk(par1,p a r2y...,p a rk) (3.3) where opk is th e type of th e operation and parx,par2, ...,p a rk are param eters of the operation. O perations are designated to m anipulate objects in a m eaningful way. An object can be associated w ith a list of operations and, each of them can be used to change this object. For exam ple, object c i r c l e can be m anipulated by the following operations: • tr a n s la te _ c ( c ,d x ,d y ) : an operation to tran slate circle c by distances (d x ,d y ). • r o ta te _ c ( c , a ,p ) : an operation to ro tate circle c by angle a around pivot P- • s h .rin k _ c (c ,d r) : an operation to shrink th e radius of circle c by d r. The following operations can be associated w ith a slotted block (see Fig ure 3.1): • s e t_ s lo t_ h e ig h (s ,<5h.) : a procedure to alter th e height of slot s by < 5 h , , defined as: s .h = s .h + dh. i t 38 I h s - i b Figure 3.1: Param eters of a slotted block. • s e t_ s lo t_ w id th (s ,^ w ) : a procedure to alter th e w idth of slot s by 6v, defined as: s.w = s.w + < 5 w . 3.3 Satisfying a constraint by operation j A constraint can be satisfied through m anipulating its participants by proper I i I operations. For exam ple, a line can be m ade tangent to a circle by a proper translation, a line can be m ade parallel to another line by a rotation w ith a proper angle, and a block can be m ade to fit into a slot by setting proper param eters of th e slot. A constraint can be associated w ith an operation to satisfy it, together w ith a procedure to com pute the param eter values for th e operation. For exam ple, constraint p a r a l l e l (1 1 ,1 2 ) can be satisfied by r o t a t i o n ( l l , a n g le ,p iv o t) , and th e procedure to com pute a n g le is given below: 39 b2 b2 b2 b l b l b l c l 12 c l 12 C lf 12 (a) (b) Figure 3.2: Different ways to satisfy a constraint. Real rotate_angle(ll,12) { angle = arctg(slop(ll) - slop(12)) return(angle); } C onstraints can often be satisfied in different ways, and th e resulting config urations can also be non-unique. For exam ple, to m ake a block fit into a slot, either object can be altered to satisfy the constraint (see Figure 3.2(a)). W hen a decision is m ade for an object to be changed, there exist different ways to change it. In Figure 3.2(b), to m ake c l tangent to 11, c l can be either tran slated or its radius reset. Therefore, a constraint can be represented by alternative operations to satisfy it, and each of them will satisfy th e constraint when applied. j „ ! b3 b l b2 c l b4 (a) Cb) Figure 3.3: M aintaining constraints. 3.4 Maintaining a constraint by operations A geom etry is often subject to changes due to im posing a new constraint or altering objects’ dim ensional values. T he changes can be in form of operations generated to satisfy a new constraint or operations directly resulting from m anip ulating a geometry. These operations usually will affect some constraints th a t are already satisfied underlying th e sam e geometry. Therefore, the geom etry needs to be changed correspondingly to accom m odate all th e changes. An affected constraint can be m aintained by perform ing an operation. For exam ple, when one of two parallel lines is changed by a rotation, th e other line can be ro tated correspondingly to m aintain th e parallelism . In Figure 3.3(a), c l is originally fit into b4, i.e., f i t ( c l ,b 4 ) is a satisfied constraint, an operation th a t resets th e radius of c l will cause the constraint to be resatisfied, resulting in an operation to change b4 correspondingly, as indicated by dashed lines in th e figure. In Figure 3.3(b), im posing a new constraint f i t ( b l , b 3 ) produces an operation 41 to alter b l, which violates satisfied constraint f i t ( b l , b 2 ) , therefore, another I operation is generated to m aintain the constraint by changing b2 properly. ' Sim ilar to defining operations to satisfy a constraint, a constraint can be J associated w ith an operation to m aintain it, together w ith a procedure to com pute th e param eter values for th e operation. For exam ple, for m id p o in t ( p i ,p2 ,m) constraint, when one of p i and p2 is reset, an operation will be generated to reset their m iddle point m . Provided below is th e procedure to com pute the location of m . m id d le _ p o in t_ lo c a t io n s (p i ,p2) { x = (p 1 .x + p 2 .x ) /2 ; y = ( p l .y + p 2 .y ) /2 ; r e t u r n ( x , y ) ; } T here are different ways to m aintain a constraint as well. For exam ple, con straint c o - l i n e a r ( p i ,p2 ,p 3 ) requires th a t three points lie in a straight line. W hen one of th e three points is moved, either of the rem aining two can be changed to m aintain the constraint. Therefore, a constraint can be associated w ith a list of alternative operations to m aintain it. 42 11 cl <b) Figure 3.4: C onstraint preserving operations. 3.4.1 Constraint preserving operations A constraint is tolerable to certain operations which will not violate th e con straint. For exam ple, the translation of one of parallel lines will not violate th e parallel constraints. In th e context of this dissertation, operations th a t a con strain t can tolerate are called constraint preserving operations of th e constraint. > I I C onstraint preserving operations will be used in generation of operations to sat- j isfy or m aintain constraints in the context of other constraints. Its use will be I discussed in the following chapter. j T hree exam ples are given above in Figure 3.4. T he objects in dashed lines \ represent th eir position after being changed by a constraint preserving operation. T he constraint preserving operations of constraint ta n g e n t ( l , c ) are: • r o t a t i o n _ l ( 1 , a ,c e n t e r ( c ) ): rotation of 1 around the center of c; • t r a n s l a t e _ c ( c ,d ,a l o n g ( l ) ) : translation of c along line 1. 43 j Sim ilarly for constraint t a n g e n t ( c l , c 2 ) , its constraint preserving operations j j are rotations of either c l or c2 around the center of another. For constraint ! { f i t ( r , s ) , the two constraint preserving operations are an operation th a t extends I th e top of r and an operation th a t alters the two sides of s. I I I » » 3.5 An operational constraint model i ! I i i j In a specific problem dom ain, one usually deals w ith a finite num ber of constraint j types. Any problem instance in th a t dom ain can be form ulated as a com bination i of constraints of those constraint types. Problem solving is considered as the process of actually satisfying a given set of constraints. Based on th e discussions in the previous sections, an operational constraint m odel for representing and satisfying geom etric constraints is presented here. ' i I T he m odel consists of two m ajor components: i 1. A Knowledge Base: T he m odel contains each individual co n strain t’s local i ! j knowledge used to satisfy and m aintain it in term s of operations. | l I I 2. A Satisfaction M echanism: Given a set of constraints underlying a geome- ■ i | try, the m odel generates a sequence of operations based on th e knowledge i i ! base about constraints and operations, such th a t th e application of th e se- i I ; j quence of operations to the given geom etry will satisfy the set of constraints. | 3.5.1 The knowledge base T he knowledge base contains two kinds of inform ation, which are organized into two tables. • Table 1: Each constraint type is associated w ith a list of alternative oper ations, together w ith th e m ethods of com puting th e param eter values for th e operations; any of th e alternative operations when applied will satisfy th e constraint. • Table 2: For each kind of incom ing operation presum ably applied to a participant of a constraint type, th e constraint type is associated w ith a list I of alternative outgoing operations, together w ith the m ethods for com puting i th e param eter values of th e operations; any of th e alternative operations, when applied, will m aintain th e constraint upon th e incom ing operation. A n E x a m p le: i Tw o-dim ensional sketch systems usually encounter constraints on plane fig- j ures such as a line, circle, point, and polygon. Consider following set of constraint I types th a t are common in such systems: • c o - l i n e a r (p i ,p2 ,p 3 ) : three points p i, p2 and p3 lie on a straight line. • ta n g e n t ( c , l ) : line 1 is tangent to circle c. 45 • p a r a l l e l (1 1 ,1 2 ) : line 11 is parallel to 12. • d i s t a n c e ( p l ,p 2 ,d ) : the distance between two point p i and p2 is d. • a n g le (p i ,p 2 ,p 3 ,a ) : the angle betw een < p l,p 2 > and <p2,p3> is a. • an c h o r (o) : object o is fixed. | Two types of operations are used to m anipulate a geom etry form ed by these j 1 plane objects (i.e., line, circle, point, etc.): ; j • tr a n s ( o b j , d i s t , v e c t o r ) : translate object obj by distance d i s t along j direction v e c to r. • r o t (o b j , a n g l e ,p iv o t ) : ro tate object obj clockwise by angle a n g le around pivot p iv o t. I As noted above, the knowledge base concerning th e above constraints and | I operations can be organized into two tables: one table contains th e associations ! of the constraints w ith operations to satisfy them ; th e other contains operations to m aintain them . 46 Table 1. Associations of th e C onstraints w ith O perations to Satisfy Them . C onstraint O perations Procedures co-linear(pl,p2,p3) {rot(pl,a,p)} {trans(pl,d,v)} {rot(p2,a,p)j {trans(p2,d,v)} (rot(p3,a,p)} {trans(p3,d,v)} proc_l(pl,p2,p3) proc_2(pl,p2,p3) proc_l(pl,p2,p3) proc_2(pl,p2,p3) proc_l (p i ,p2,p3) proc_2(pl,p2,p3) parallel(ll,12) {rot(ll,a,p)} {rot(12,a,p)} proc_3(ll,12) proc_3(ll,12) tangent(c,l) {rot(c,a,p)} {trans(c,d,v)} {rot(l,a,p)> {trans(l,d,v)} proc_4(c,l) proc_5(c,l) proc_6(c,l) proc_7(c,l) distance(pl,p2,d) {trans(pl,d,v)} {trans(p2,d,v)} { ro t(p l,a ,p )j {rot(p2,a,p)} proc_8(pl,p2,d) proc_8(pl,p2,d) proc_9(pl,p2,d) proc_9(pl,p2,d) angle(pl,p2,p3,al) {rot(pl,a,p)} {rot(p3,a,p)} proc_10(pl,p2,p3,al) proc_10(pl,p2,p3,al) anchor(o) {m ark(o)} proc_ll(o) • In each row of Table 1, a constraint type is associated w ith an operation to satisfy it and a procedure for com puting param eter values for the opera tion. A constraint type m ay have m ultiple entries representing alternative operations to satisfy it. • In each row of Table 2, a constraint is associated w ith an incom ing operation and an outgoing operation; upon receiving the incom ing operation, the constraint can fire th e outgoing operation to m aintain itself. For clarity, the procedures for com puting th e param eter values for outgoing operations are not listed in the table. 47 Table 2. Association of the C onstraints w ith O perations to M aintain Them . C onstraint Incoming O peration Outgoing O peration co-linear(pl,p2,p3) ro t(p l,a ,p ) ro t(p 2 ,a l,p l) rot (p i,a,p ) trans(p2,d,v) tran s(p l,d ,v ) rot(p2,a,p) tran s(p l,d ,v ) trans(p2,d,v) tran s(p l,d ,v ecto r(p l,p 2 ,p 3 )) parallel(ll,12) ro t(ll,a,p ) rot(l2,a,p) rot (12,a,p) rot (11, a,p) tra n s(ll,d ,v ) trans(12,d,v) tangent (c,l) trans(l,d,v) trans(c,d,v) trans(l,d,v) rot(c,a,p) rot(l,a,p) trans(c,d,v) rot(l,a,p) rot(c,d,v) trans(c,d,vector(l)) rot(l,a,center(c)) distance(pl,p2,d) tran s(p l,d ,v ) trans(p2,d,v) ro t(p l,a ,p ) trans(p2,d,v) ro t(p l,a ,p 2 ) ro t(p 2 ,a,p l) angle(pl,p2,p3,a) ro t(p l,a ,p ) rot(p3,a,p) rot(p3,a,axis) ro t(p l,a,ax is) tra n s(p l,d , vector (pi,p2)) trans(p3,d, vector (p2,p3)) anchor (ol) any operation reject Notice th a t some rows in th e outgoing colum n of Table 2 are blank, which indicate th a t these incoming operations are the constraint preserving operations j of the corresponding constraints. ! 48 O ps c i / o p L o o p A n a l y z e r E q u a t i o n S o l v e r K n o w le d g e Base I n p u t s O u tp u t Figure 3.5: T he diagram of the satisfaction m echanism . 3.5.2 The satisfaction mechanism I T he satisfaction m echanism is th e functional p art of th e system . T he infrastruc- j tu re of th e m echanism is illustrated in Figure 3.5. T he m echanism is prepared for two scenarios: 1) satisfying a new constraint c i in th e presence of a set of satisfied constraints Sn, and 2) m aintaining a set of constraints Sn upon an incom ing operation op. In both cases, the m echanism generates a sequence of op erations which will satisfy the constraint or m aintain th e set of constraints when executed. T he m echanism has four m ajor com ponents: satisfaction planner, con- ( i strain t knowledge base, loop analyzer, and equation solver. T heir functions are j explained below. • Satisfaction Planner is th e core of th e m echanism . It is responsible for planning a sequence of operations upon inputs. It interacts w ith other three com ponents in th e planning process. It is discussed in m ore detail in C hapter 4. 49 • Knowledge Base stores th e inform ation about constraints and th e associated operations which satisfy and m aintain them . It is accessed by Satisfaction Planner. • Loop Analyzer handles special cases due to circular dependencies of con straints. It invokes Equation Solver when necessary. C hapter 5 discusses propagation loops in detail. • Equation Solver solves a system of equations. It will be discussed in Chap te r 6. i 50 Chapter 4 Satisfaction Planning ! Based on th e operational constraint model presented in C hapter 3, constraint satisfaction becomes the process of planning a sequence of operations which will sim ultaneously satisfy a constraint network when executed. This chapter presents an increm ental planning algorithm which generates a satisfaction plan by propa gating operations through a constraint network. G eom etric reasoning is used in j th e planning stage to shortcut propagation branching, thereby helping to generate efficient and robust plans. 4.1 Abstract view of satisfaction planning C onstraint satisfaction can be considered a planning problem . T he goal is to satisfy a set of constraints, where satisfying each constraint in the set is treated as a conjunctive subgoal. T he initial state of th e problem is a set of unsatisfied 51 constraints and th e final state is a set of satisfied ones. Satisfaction planning is j i a process of generating a sequence of operations such th a t th e execution of the j sequence of operations will transform th e initial state to th e final state. | An increm ental paradigm is adopted in satisfaction planning. C onstraints are satisfied increm entally in th e presence of other satisfied constraints. Increm ental satisfaction is suitable for applications where constraints often becom e increm en tally available, such as a geom etric design in which one refines one’s designs by increm entally im posing new constraints. Increm ental approaches satisfy a con strain t in th e context of a constraint netw ork through local m odifications, which reduce the com plexity of im m ediately dealing w ith a whole set of constraints and often results in a solution m ore intuitive w ith respect to the previous one. Increm ental satisfaction often involves resolving conflicts arising from satis- p fying a new constraint. Because constraints, in m any cases, are interdependent, this implies th a t th e satisfaction of a constraint m ay violate other satisfied ones. T he planning algorithm achieves consistency of a constraint netw ork by propa gating operations through the constraint network. Satisfaction planning is initi ated when operations are generated due to im posing a new constraint or sim ply j t altering a geometry. T he result of a planning process is a p artial ordering of j operations, which can be organized into a sequence of operations to be executed. In the propagation process, geom etric reasoning is used to shortcut propagation branching. c/op . Geometric Sn Geometric Reasoning c/op_^ Reasoning 1 t _to> ops Operation Propagation Sn Operation op— to Propagation Sn: the existing set of satisfied constraints, e/op: impose a new constraint c or apply an operation op on Sn. opi: an operation generated by geometric reasoning component, ops: a sequence of operations generated in propagation. Figure 4.1: T he abstraction of th e satisfaction planner. 4.2 The outline of the planning algorithm As illustrated in Figure 4.1, th e satisfaction planner has two functional compo nents: operation propagation and geom etric reasoning. • Operation propagation component: propagates th e operation generated by th e geom etric reasoning com ponent to other related constraints. It recur sively calls the geom etric reasoning com ponent in the propagation process. T he sequence of operations generated in th e propagation process constitutes a satisfaction plan. • Geometric reasoning component: generates an operation to satisfy or m ain tain a constraint such th a t th e operation has the least effect on the context constraints based on given heuristic rules. T he planning algorithm can be abstractly stated as follows: 53 M ain A lg o r ith m (c,op,Sn) : { opi *— Constraint_Reasoning(c,op,Sn) ops < — ops U opi Operat ion_Propagat ion (opi, c, Sn) Return(opi) } O p era tio n P r o p a g a tio n A lg o r ith m (op,c,Sn) : { Cs < — Related_constraint (c ,Sn) For each ci € Cs do { opi «— Constraint .Reasoning (ci, op, Sn) Operat ion_Propagat ion (opi, ci, Sn) colinear colinear r o t - P3 (a) c o lin e a r Figure 4.2: G raphical representation of constraint and operations. 4.3 Graph representation of constraints Before one proceeds to the technical aspects of the satisfaction planning, a graph representation scheme for constraint netw orks th a t will be used throughout this paper will be introduced. W ith this scheme, constraint firings and operation propagation can be illustrated. U nder this scheme, a constraint is shown as a bar connected to a few circles. Each circle represents a participant of th e constraint, and a tex t string m ay be associated w ith the bar to indicate th e type of th e constraint. Figure 4.2(a) shows th e graph representation of constraint c o l i n e a r (p i ,p 2 ,p 3 ). Firing an operation to satisfy a constraint can be shown in th e graph by an arrow from th e bar to the circle representing th e participant prescribed by the operation; a tex t string m ay be attached to th e arrow to indicate th e type of the 55 12 13 cl 11 12 13 14 15 cl 11 14 15 p-join' tangent 16 Figure 4.3: A configuration w ith constraints interacting. operation. Figure 4.2(b) shows constraint c o l i n e a r ( p i ,p2 ,p 3 ) firing operation r o t to p i to satisfy it. Firing an operation to m aintain a constraint can also be denoted similarly. T he incom ing operation is shown as an arrow to th e object prescribed by the operation, and the outgoing operation to m aintain th e constraint is shown by an arrow from th e bar to the object prescribed by th e outgoing operation. Fig ure 4.2(c) shows the incoming operation to p i and the outgoing operation to P3. A set of constraints can be represented by showing each constraint and m erg ing the circles of th e same objects. Provided below is the set of constraints under lying th e configuration in Figure 4.3; th e graph representation of th e constraint netw ork is shown on the right p art of th e figure. { ta n g e n t ( c l , 13) , t a n g e n t ( c l ,1 4 ) , p _ jo in t (1 1 ,1 2 ) , p _ jo in t(1 2 ,1 3 ) , p _ j o i n t (1 3 ,1 4 ) , p _ jo in t (1 4 ,1 5 ) , 56 p_joint(15,16) , p_joint(16,ll)} 4.4 Geometric reasoning R epresenting constraints in term s of alternative operations enables th e satisfac tion m echanism to reason about operations generated to satisfy or m aintain a constraint in th e context of other constraints. T he objective is to m inim ize the local effect of an operation generated from a constraint firing to th e other re- I lated constraints, thereby reducing th e am ount of changes required to m aintain ; I th e affected constraints. Inherent in th e constraint satisfaction m echanism , this objective is approached at two levels: 1. W hen there are alternative objects to change, select the one th a t has less effect on other related constraints. I I I 2. U pon th e selected object, choose an operation am ong th e alternatives th a t 1 has less effect on other related constraints. T he m easurem ent for local effect of an operation is subject to a list of heuristic rules. T he following two subsections contain a discussion of these rules. 57 I fit i fit co-llnear }tangent tangent tangent Figure 4.4: Exam ples of application of H euristic I. 4.4.1 Selecting proper objects to change W ithout loss of generality, one can assum e th a t a constraint has two or m ore participants. In satisfying a constraint, operations can be applied to any of its participants. T he following heuristic rule tells which one to choose in th e context of other constraints. H e u r is tic I: Am ong constraint’ s participants that are eligible to be changed, choose the one that has a lower number o f connections with other constraints. Figure 4.4 gives two intuitive exam ples w ith drawings and their underlying I I I constraint netw ork graphs (the constraints to be satisfied are surrounded w ith | 58 ! dashed rectangles). In Figure 4.4(a), to satisfy constraint f i t ( s i , b l ) , it will generate an operation to alter s i instead of b l, because s i has one connection b u t b l has two connections in th e constraint graph. In Figure 4.4(b), to satisfy I I I constraint c o l i n e a r ( c l , c 2 ,c 3 ) , according to the above heuristic, c3 will be changed because it has less connections (2) com pared to c l (4)) and c2 (3). It is intuitive th a t, by choosing proper objects in firing an operation, unnecessary I i changes can be avoided. T here is an exception to this heuristic rule. An object m ay be subject to a j constraint th a t restricts some operations to be applied to th e object. In this case, this object is no longer eligible for the com petition even if it has less connections I th an others. For instance, to m ake two lines parallel, if one of two lines is an- | ! ( chored, th e other becomes th e only choice to be ro tated to m ake th em parallel. j i i In these cases th e heuristic will be overruled. j i I I 4.4.2 Selecting proper operations J Once an object is selected, th e next step is to find a proper operation in th e same j context of constraints. H e u r is tic II: Am ong the alternative operations, select one that can be tolerated by the m axim um number o f the related constraints. j j t I 59 ! J t r a n s ( c l , d , 12) { t a n g e n t | ta n g e n t XV tangent tangent rot (11,a, cl) parallel Figure 4.5: Exam ples of application of H euristic II. This heuristic rule can be im plem ented by searching an operation th a t needs to be a constraint preserving operation of the related constraints. Consider th e two cases in Figure 4.5 (constraints to be satisfied are surrounded by dashed rectangles). In Figure 4.5(a), to generate an operation to satisfy constraint ta n g e n t ( c l ,1 1 ) in th e context of constraint ta n g e n t ( c l , 1 2 ), th e operation generated is to tran slate c l along 12 such th a t the tangency is m aintained. In Figure 4.5(b), a rotation of 11 around the center of c l is used to m aintain th e tangency. This heuristic rule can be applied sim ilarly when a constraint fires an outgoing operation to m aintain itself upon an incom ing operation. Consider th e configu ration in Figure 4.6(a). 11 is changed by an operation to set it at another place (as indicated by the dashed line). C onstraint ta n g e n t ( c l ,1 1 ) m aintains itself 60 11 12 tangent tangent W 11 ) [ c l) 0 segment a_segment anchor on^Tine ancKor <b> Figure 4.6: M aintain constraints in th e context of other constraints, by selecting a proper operation th a t m aintains constraint ta n g e n t ( c l ,1 2 ). In Figure 4.6(b), point p3 is constrained to slide on th e segm ent ( p l,p 2 ) . W hen p3 is moved by a translation along th e segm ent, constraint segm ent (p 3 ,p 4 ) gen erates an operation th a t sets p4 at the intersection of two circles determ ined by (p 3 ,p 4 ) and (p 4 ,p 5 ). An object m ay p articipate in m ore th an one constraint. It m ay be impossible to find an operation th a t m aintains all th e constraints. In Figure 4.7, for exam ple, to satisfy a constraint c o l i n e a r ( c l , c 2 , c 3 ) , it is im possible to generate an 1 i I operation th a t moves c3 while m aintaining all the other three constraints. In this j case, it generates an operation to ro tate c3 around th e center of c l to m aintain j constraint ta n g e n t ( c l ,c 3 ), while other changes have to be m ade to m aintain 61 11 c o -lln e a r tangent tangent tangent c2 c3 11 12 c2 c l tangent tangent Figure 4.7: An exam ple th a t requires operation propagation. cO opO ok opO op< opO c i c2 op: opi' o l Figure 4.8: An abstract view of operation propagation. other two constraints t a n g e n t ( c 3 ,11) and ta n g e n t ( c 3 ,12). T he following sec tion is a continuation of this discussion. 4.5 Operation propagation This section is concerned w ith satisfying a constraint in the context of a constraint network. T he idea is to propagate operations through a constraint network. F irst, to im pose a new constraint on a network, th e constraint fires one of the 62 operations defined in its constraint satisfying operation table. T he operation j ! j generated will be applied to th e object prescribed by the operation. This object, j upon receiving the operation, will propagate it to all th e constraints in which it participates. These constraints, when receiving th e operation from one of their participants, will fire some operations prescribed by th eir constraint m aintaining tables. These operations, in tu rn , will be propagated further, and so on. The propagation process is illustrated in Figure 5.4. The following are some properties of operation propagation. • O bjects participating in only one constraint are called leaf objects. Leaf objects are assum ed to tolerate any operation. • A constraint absorbs an operation if th e operation is a constraint preserving operation. For exam ple, parallel constraints will absorb translations. • O peration propagation in a netw ork term inates if every object stops prop agating. • If operation propagation in a constraint network term inates in finite steps, the network is satisfiable and th e partial ordering of constraint firings in the propagation process constitutes a solution for satisfying th e network. 63 Figure 4.9: Changing location of vertex p i. Figure 4.10: O peration propagation of Exam ple 1. j 4.5.1 Example 1: Enforcing operation to an object I * It is often necessary to change some dim ension values of objects w ithout introduc- | I ing or rem oving any constraints; changing th e location and orientation of objects m ay violate some constraints already satisfied. Therefore, th e constraint network should be resatisfied. 64 12 11 P i 16 Figure 4.11: Imposing a new constraint colinear. j i For exam ple, in Figure 4.9, one m ay w ant to tran slate vertex p i to another location p i ’ . O ther vertices m ust be moved to resatisfy these m id p o in t con straints (the dashed lines indicate the new locations). T he propagation is started by operation t r a n s l a t e (p i , d x ,d y ) applied to p i. T he process is dem onstrated in Figure 4.10. 4.5.2 Example 2: Imposing a constraint to a constraint network Introducing a constraint into a given geom etry will often violate th e existing satisfied constraints. Therefore, the affected constraints need to be resatisfied. T he following exam ple shows how a new constraint is satisfied through operation propagation. j I Consider th e configuration in Figure 4.11, introducing c o l i n e a r ( p i , c l , c 2 ) , j I which will change the tangencies betw een c2 and 13 and betw een c2 and 14. I i 65 p—joint p-joint tangent tangent 11 12 13 c 2 14 c l 15 16 j o d ln t — a t p - j o i n t a n c h o r co lin e a r Figure 4.12: O peration propagation of Exam ple 2. T he propagation is started by operation t r a n s l a t e ( c 2 ,d x , d y ) . T he process is dem onstrated in Figure 4.12. 4.6 Operation propagation with backtracking A plain propagation process m ay fail in two situations: 1. A constraint m ay receive an operation which is unacceptable to it. For instance, a constraint cannot accept an operation th a t tries to move the object anchored by this constraint. ! 2. A propagation process never term inates, indicating a loop in propagation. T he first case is handled by incorporating a backtracking m echanism in the propagation algorithm . T he second case is handled by a special loop resolution m ethod discussed in th e following chapter. 66 c l c2 cO c3 c5 c6 Figure 4.13: An exam ple of propagation failure. j i i Consider th e configuration in Figure 4.13. Suppose th a t c3 is anchored; to | I 1 satisfy a new constraint ta n g e n t ( c l ,c 4 ) , an operation to move c l is generated ] i I and th en propagated to c2. T he propagation fails at c3 because th e operation j tries to move c3 (which is fixed). T he propagation is shown in Figure 4.14. B acktracking is used to generate another propagation route th a t avoids con- i flicts. It can go on recursively until it finds a p a th w ithout conflicts, and can I I resolve new conflicts generated in the backtracking process. B acktracking m ay | I eventually fail when all routes have been enum erated (assum ing no loop is en countered during propagation), indicating an inconsistent constraint network. ! A recursive algorithm for operation propagation w ith backtracking is presented j I below. I 67 on circle on circle c 3 c 2 c l c O c 4 c 5 a n c h o r t a n g e n t t a n g e n t t a n g e n t Figure 4.14: O peration propagation th a t fails. Given 1) a sem antic constraint netw ork S N and 2) an initiating constraint Co, which generates operation opo on object objo, operation propagation starts by invoking OP_PROPAGATION(SN, cq, opo, objo'). A lg o r ith m I. ( O p e r a tio n P r o p a g a tio n w ith B a c k tra c k in g ) O P _ P R O P A G A T IO N (S N , c , o p , o b j) b e g in C * — C onnected_cons(SN , c , o b j ) , fo r e ach c ,- € C b e g in p ro p a g a te op t o c4 - if op c o n f l i c t s w ith c ,- th e n BACKTRACK(c,-, c , op, o b j) else { 68 opi < — N ex tjm ain tain _ o p (cj, op , o b j ) , obji < — O perand (opi) , f i r e opi on o b j\, OP_PROPAGATION(SN, c8, op1,obj1) ;} e n d e n d . • C onnected_cons(SN , c , obj ): returns the set of constraints connected to o b j, except c. • BACKTRACK(cj-, c , op , o b j): backtracks th e propagation on c, when op on obj conflicts w ith Cj. • N ext_m aintain_op(c4 -, o b j, op): returns th e next alternative operation th a t can be fired by c; to m aintain th e change caused by op (on o b j), and returns n i l if it gets to th e end of the list. j t • O perand (op): returns the object operated by op. A lg o r ith m I I . (B a c k tra c k in g ) B A C K T R A C K ( c , o b j, op) ! b e g in j C\ < — T ra c e _ c o n s (c , o b j, o p ), j I opi < — T race_ o p (ci, o b j, o p ), 1 69 i o b j i < — operandCop!) , Cancel_past_effect (ci, o b ji, opi), t if (obji = objo and opx = op0) th e n I Report failure and exit. else j i i b e g in I I i if Next_maintain_obj (c, obj, op) = nil then j BACKTRACK(c, obj, op) else { op2 < — Next_maintain_op(ci ,obj\ ,opi) , obj2 * — operand(op2) , 0P_PR0PAGATE(SN, obj2 , op2) } end en d . The meanings of the procedures are explained below. • Trace_cons(c, obj , op): returns the constraint that fired op on obj and propagated it to c. • Trace_op(ci, obj , op): returns the operation that was applied on a par ticipant of Ci and caused ci to fire op on obj. c l 11 13 c2 c4 c3 12 (a) (b) (c) (d) Figure 4.15: Steps of backtracking. • C a n c e l_ p a st_ e ffe c t ( c i, obj, op): discards all the effects of propagation caused by ci firing op on o b j. i 4.6.1 An example of backtracking in propagation j B acktracking is essentially a rem edy for local propagation m ethods. T he fol- ; lowing exam ple illustrates in detail backtracking in a propagation process. Fig- } I ure 4.15(a) shows an initial configuration in which 11 , 1 2 , 13 are fixed objects. | I Now consider th e operation propagation resulting from im posing a new constraint ! 1 t o u c h ( c l ,1 2 ). I • Step 1. T he propagation process is illustrated in Figure 4.16. It starts at an operation generated to move c l along 11 such th a t c l touches 12. The operation is then propagated to c2. Finally, an operation is propagated to 12 which causes backtracking (see Figure 4.15(b)). i 71 ! touch anchor touch touch c l 11 c 2 12 c 3 1 3 c 4 t o u c h t o u c h t o u c h t o u c h t o u c h Figure 4.16: backtracking in propagation. • Step 2. T he backtracking first causes c3 to be recovered (see Figure 4.15(c)). Since constraint to u c h ( c 3 ,c 4 ) does not have another choice, it backtracks fu rth er to ask constraint to u c h ( c 2 ,c 3 ) for another choice. • Step 3. C onstraint to u c h ( c 2 ,c 3 ) generates another operation th a t can be absorbed by both constraints to u c h ( c l,c 2 ) and to u c h ( c 2 ,c 3 ) . Back tracking stops. The final configuration is found in Figure 4.15(d). 4.6.2 Preprocess constraint network One way to avoid backtracking is to preprocess constraint networks by inferenc- ing objects th a t are indirectly anchored from known anchor constraints. B ut it also introduces the cost of m aintaining such inform ation because, whenever the constraint network is changed (constraints added or rem oved), it has to be recom puted. 72 Chapter 5 Loop Analysis i i i As noted in C hapter 4, th e operation propagation algorithm m ay not term inate, which im plies th a t there is a propagation loop in a given constraint network. Loop cases indicate the circular dependency of som e constraints in a constraint network. In stead ’ of relaxation of the entire constraint netw ork by num erical m ethods, as other approaches often do, th e present approach localizes constraints involved in a loop, relaxes them , and then propagates the solution in term s of operations back to th e constraint network. How to detect, trace, and finally resolve propagation loops in the fram ework of operation propagation is the focus of this chapter. 73 c l c 2 c7 cO c3 c6 c4 c5 Figure 5.1: A propagation loop exam ple. 5.1 W hy loops occur T he operation propagation algorithm is sem antically robust in th e sense th a t once it term inates, th e given constraint network m ust be satisfied. Therefore, for some problem s it cannot solve, the algorithm will not term inate. O peration prop agation is essentially a local satisfaction approach. It tries to satisfy constraints j | by propagating local solutions through a constraint network. This approach, ! although appealing for m any constraint problem s w here local solutions can be propagated through, m ay fail to solve problem s th a t require global coordination. T h at happens in form of propagation loops. A n E x a m p le . Consider the configuration in Figure 5.1: th e sm aller circles t cl, c2, ..., c7 (all of th e same radius) are tangent to each other except for cl and c7, and th eir centers are constrained on the circum ference of th e bigger circle cO. 1 I Now let us see w hat happens to impose constraint ta n g e n t ( c l ,c 7 ). 1 tl t2 t3 t4 t5 t6 t7 c l c2 c3 c4 cS c6 c7 c O ] Figure 5.2: O peration propagation in th e constraint network. T he operation propagation algorithm generates an operation to move c l along th e circum ference of cO so th a t cl is tangent to c7. This operation is propagated 1 j to c2, which, in tu rn , propagates to its neighbor c3. T he propagation follows j I 1 th e chain of the circles and finally results in c7 to be moved. M oving c7 violates the previously im posed constraint tangent (cl ,c7), thereby causing cl to be moved again. This process repeats forever. Figure 5.2 shows th e underlying constraint netw ork and the p attern of the operation propagation. In regard to basic geom etric knowledge, it is intuitive th a t this case cannot be solved locally using operation propagation. Global com putation is required to find a radius for | i cO or cl th a t coordinates all the constraints. ! I 5.2 A necessary condition for loops Given a constraint network, it is im portant to characterize th e sufficient and necessary conditions for propagation loops to occur. Sufficient conditions seem 75 difficult to capture because they often relate to th e sem antics of a constraint problem . In contrast, a necessary condition can be identified w ith respect to the syntax of a constraint network. A N e c e s s a ry C o n d itio n : For a constraint network to be involved in a propagation loop, there must be at least one network circle in the constraint network graph. * I Several related notions are defined below: ! j • A direct path: Given a constraint ct( o i, 0 2 ), a direct path from Oi to 0 2 is ! 1 1 said to exist and represented as 0 1 -^ 0 2 ; sym m etrically, 0 2 - ^ 0 1 represents a , direct p ath from o2 to oj. • A path: Given a constraint network, a path from 0 1 to ot is defined as a sequence of direct paths Ox— Vo2, 0 2 -^ 0 3 , ..., on^ i C ^ o n, represented as Oi-^O2 ~^0 3 - ^ ‘ • • ^On-i0 ^ 1 on, and for each direct p ath o^^Ok+i in the ! p ath , Ok+i^ O k is not in th e p ath. ! • A network circle: A network circle is a closed p ath , i.e., Oi and on are the sam e object. From the constraint netw ork graph in Figure 5.2, a netw ork circle is identified as follows: cl^ c 2 ^ c 3 -^ c 4 -^ c 7 -^ c 6 -^ c 7 ^ c l. 76 5.3 W hen a loop is signaled It is n atu ral to ask how we know algorithm ically w hether a propagation process gets in a loop and when it starts. Based on the necessary condition, a propa gation loop can be detected by tracing the statu s of objects being moved. In a propagation process, an object is m arked when it receives an operation for the first tim e; a loop is signaled when a m arked object receives another operation unless this object is a leaf object. Actually, the propagation algorithm im plicitly | j assumes th a t an object can receive an operation only once because a second op eration m ay violate certain constraints ensured by th e first operation. Therefore, a loop is signaled when the first object receives a second operation. Let us retu rn to th e operation propagation case in Figure 5.2. T he loop is signaled when c l receives an operation again. 5.4 Loop resolution Based on th e above discussion, this section presents a m ethod to resolve a prop agation loop in the fram ework of operation propagation. T he idea is to localize j t th e p art of a constraint network involved in a loop, to solve it num erically, then I t to propagate th e solution in term s of operations back to the constraint network. T he m ain steps of th e m ethod are: loop tracing, equation generation, equation solving, operation assembly, and propagation. 77 1. Loop Tracing: W hen a loop is signaled, the constraints and operations in volved are located by using th e loop tracing algorithm given in th e following subsection. I 2. Equation Generation: T he constraints found are tran slated into a system ( I of equations to be solved. A dditional equations are generated from the operations involved in the loop to guide equation solving so th a t th e solution im plies a transform ation by these operations. A few heuristic rules are em ployed to select other dim ensional equations, such as to fix some objects in th e loop, in order to im prove th e efficiency of equation solving. 3. Equation Solving: T he resulting system of equations is solved by using the j iterativ e N ew ton-Raphson m ethod. 4. Operation Assembly: A sequence of operations is assem bled based on the solution obtained in equation solving. The sequence of operations is consid ered to be a transform ation which, when executed, will produce th e same configuration as did th e num erical solution. j i I 5. Propagation: T he sequence of operations is propagated sequentially to the constraint network. T he diagram in Figure 5.3 illustrates th e control flow betw een these steps. T he inner back loop indicates the interaction betw een equation generation and J Operation Propagation Operation Assembly Equation Generation Equation Solving Figure 5.3: Loop resolution diagram . equation-solving processes: if th e system of equations generated are over-constrained, th e equation solver will request th e equation generation process for a less-constrained system of equations. The outside back loop m eans th a t if the propagation gets • in a loop again, th e loop resolution procedure will be invoked recursively. T he following subsections explain these steps in detail. 5.4.1 Loop tracing W hen a loop is signaled, th e loop resolution m ethod first goes to find the con- I 1 straints and the operations involved in the loop. Taking th e signal object as j i a key, this step proceeds to trace backw ard along th e propagation route until I the signal object is encountered. T he loop tracing algorithm outputs two sets: lo o p _ c o n s tra in t_ s e t and lo o p _ o p e ra tio n _ s e t, containing th e constraints and ■ I i operations involved in a loop. ; 79 Algorithm III. (Loop Tracing) begin { o 0 is the signal object. } loop_constraint_set < — { }; loop_operation_set < — { }; cstr 4 — Constraint_link(oo) ; op 4— Operation_link(cstr) ; loop_constraint_set 4— loop_constraint_setU{cstr}; loop_operation_set 4— loop_operation_setU{op}; obj 4— Object_link(cstr) ; while obj ^ o 0 do begin cstr 4— Constraint_link(obj ) ; op < — Operation_link(cstr) ; loop_constraint_set < — loop_constraint_setU{cstr} ; loop_operation_set 4— loop_operation_setU{op}; obj 4 — Object_link(cstr) ; e n d e n d . 80 cO cl c2 c3 o p O' ol o 2 o 3 o 4 o 5 c 4 c 5 Figure 5.4: An exam ple for tracing constraints and operations in a loop. • C o n s tra in t_ L in k (o b j) returns th e constraint th a t fired an operation on object o b j. • O p e r a tio n J - in k ( c s tr ) returns th e operation fired by constraint c s t r . • O b je c t_ lin k ( c s tr ) returns the object th a t propagated an operation to constraint c s t r . i i i T he following d a ta structure scheme im plem ents th e algorithm : j 1. A constraint elem ent contains th e nam e of th e constraint, th e operation it fired, and a pointer pointing to an object elem ent which had propagated an operation to this constraint (th e pointer is initially set to nil). 2. An object elem ent contains the nam e of th e object, th e operation it received, I and a pointer pointing to a constraint elem ent which had fired th e operation i to this object (the pointer is initially set to nil). | j i 81 i opO \ c5 cO op c l op 2 c2 o p i o3 op2 o4 o p i o2 opO Figure 5.5: T he d ata structure established during th e propagation. A n E x a m p le : Consider the constraint network and the operation propagation flow in Fig ure 5.4. T he d ata stru ctu re established during th e propagation process is shown in Figure 5.5, in which th e dashed line signals a loop. T he o utputs of the loop tracing algorithm are: • loop_constraint_set = {cO, c5, c2, c3}; • loop_operation_set = {opO, opi, op2, op3}. In th e la tte r p art of this chapter, constraints involved in a loop are called loop constraints; operations involved are called loop operations', and objects under loop constraints are called loop objects. 82 5 .4 .2 E q u a tio n g en er a tio n A proper system of equations is generated for next step equation solving. Equa- j ! tions are generated from three sources: 1) loop constraints, 2) loop operations, , ! and 3) other dim ensional constraints. ; ! i I ! 1) Generating equations from loop constraints: ! I i Loop constraints represent th e p art of a constraint network th a t has circular 1 i i dependencies. Since these constraints cannot be satisfied locally, they will have j I to be solved sim ultaneously by using equation-solving techniques. F irst, these j constraints are translated into equations involving th e coordinate variables of ' objects under these constraints. For exam ple, constraint p a r a l l e l (1 1 ,1 2 ) can be tran slated into th e following equation: I I ! ( r l 2 — x ll)(t/2 2 — y21) — (x22 — x21){yl2 — y ll) = 0 (5.1) 1 t i < ! i where ( r l l , y l l ) and ( r l2 ,y l2 ) represent th e endpoints of 11, (x21,y2\) and ; (x22, y22) of 12. T he equations of constraint m id p o in t(p i,p 2 ,m ) are j i I x l -4 - x2 — 2 r3 = 0; y l + y2 — 2xZ = 0. (5-2) f 1 where (a :l,y l) and (x2,y2) represent th e coordinate variables of two endpoints 1 p i and p2, and (x3,y3) of their m iddle point m . 83 2) Generating equations from loop operations: T he system of equations from loop constraints is often under-constrained, m eaning th a t there are several solutions. An arb itrary solution m ay be totally strange to th e rest of constraints in th e netw ork and, thus, causes m any of them to j be resatisfied. A dditional equations are introduced to narrow down th e solutions j ‘ to “favorable” ones in the sense th a t they have less effect on th e rest of th e j I constraint netw ork th an arbitrary ones. A dditional equations are introduced from loop operations to guide th e solution such th a t they facilitate th e later operation assem bly and propagation steps. T he : ! i reasons are as follows: ! I 1. These equations provide a way to guide th e num erical relaxation so th a t it im plies a transform ation by these operations, if a num eric solution is found. 2. These operations also serve as tem plates to be assembled based on the j num erical solutions. I I 3. T he assem bled operations can be propagated back to th e the constraint ! network. I Some exam ples of translating operations into equations are shown below. T he ! equations corresponding to a translation of a line are ( (xTf - xl') - (x2 - a:l) = 0; {y2' - yV) - {y2 - y l) = 0 (5.3) | 84 1 (x2,y2) <xl,yl> ( x l,y l> ( x l ' , y l ' > ( x 2 ' ,y 2 ') (b) Figure 5.6: Exam ples of translating operations into equations. w here and (x2',y2') are assum ed the positions of (a ;l,y l) and (x2,y2) after translation (see Figure 5.6(a)). T he equations corresponding to a rotation of a circle around th e center of another circle are (x l' — xtf)2 + (yV — yO)2 — (rcl — rrO)2 — (y l — yO)2 = 0 (5-4) where ( x l',y l') is assum ed the position of th e center (® l,y l) of th e circle after ro tatio n (see Figure 5.6(b)). 3) Generating equations from other dimensional constraints: T he resulting system of equations m ay still be underconstrained. A dditional equations can be generated from other dim ensional constraints. We fix some loop objects according to the following heuristic rules. H e u r is tic I: Fix those loop objects which are directly anchored by constraints. 85 anchor joint joint j o i n t Figure 5.7: Fix an vertex of a triangle. m i d p o i n t j o i n t j o i n t a n c h o r a n c h o r j o i n t Figure 5.8: Fixing a vertex of a triangle indirectly. This heuristic is intuitive and can be im plem ented by looking for anchor con straints directly im posed on loop objects. Consider th e sim ple loop exam ple involving finding a triangle configuration in which a vertex is fixed by an anchor constraint (see Figure 5.7, loop constraints are three j o i n t constraints). Ac cording to this heuristic rule, p i is chosen to be fixed. T he equations involving coordinate variables of p i are substituted w ith the values of p i. H e u r is tic I I: Fix those loop objects which are indirectly anchored by constraints. 86 12 13 11 14 15 17 16 Figure 5.9: Choosing proper objects to fix. This heuristic can be im plem ented by preprocessing th e constraint netw ork to locate objects which are indirectly fixed. Consider th e loop exam ple in Figure 5.8. It involves finding a triangle configuration in which one vertex pi is th e m idpoint of two anchored points p4 and p5. ! i l H e u r is tic I I I : I f there are still degrees of freedom to fix an object, fix the one that has the maximum number of connections to the rest of the network. Consider the exam ple in Figure 5.9. It involves solving th e rigid configuration am ong 11, 12, 13, 14, 15. According to this heuristic, 15 is chosen to be fixed j because it leaves th e configuration among 15, 16, and 17 unchanged. ! 1 T he system of equations generated from the above three sources m ay be over- j constrained. W hether a system of equations is overconstrained can be determ ined by checking th e singularity of its Jacobian m atrix. If it is th e case, th e equation generation process will be requested to provide a less constrained system of equa- | tions. This can be done by w ithdraw ing some equations from the original system i © • ©■ : Equation Solving Kapon Failuro Figure 5.10: The control flow for equation generation. of equations. The diagram in Figure 5.10 shows the control flow of th e equation generation procedure. 5.4.3 Equation solving T he resulting system of equations is solved by using th e N ew ton-Raphson m ethod. The principle of th e m ethod is briefly introduced below. Given a system of non-linear equations, involving n variables a?i, ..., x n, i = 1 ,2 ,..., A T . (5.5) Let X denote the entire vector of values in th e neighborhood of X , each equation fi can be extended in Tayler series: fi{ X + 6 X ) = fi( X ) + J 2 + 0 ( 6 X 2). ■ _ j oxj (5.6) 88 ; _ _ _ _ _ _ _ _ _ _ _ _ _ _ J By neglecting term s of order 6 X 2 and higher, one obtains a set of linear equations for th e corrections 8 X th a t move each equation closer to zero sim ulta neously: 'f^ocijSxj = fa, (5.7) j=i where < * H = ^ (3i = - f i (5.8) M atrix equation (5.7) can be solved by LU decom position. T he corrections are then added to the solution vector, x™w = x ? d + 8xi, i = 1 ,2 ,..., n, (5.9) T he process is iterated to converge. Iteration stops if th e sum of th e m agni tudes of the equations fi is less th an some preset tolerance, or th e sum of the absolute values of th e corrections to Sxi is less th an some preset tolerance. If th e iteration does not stop in a certain num ber of steps, it is considered as no solution to th e system of equations. T he existing coordinate values of th e objects serve as th e initial guess for th e iteration. If th e num eric process converges to a solution, the next step proceeds to assemble operations based on th e solution. 5.4.4 Operation assembly T he num eric solution obtained gives a configuration of loop objects th a t satisfies loop constraints sim ultaneously. T he rest of th e constraints m ay not com ply w ith 89 th e solution and, therefore, should be resatisfied. However, these constraints cannot be resatisfied directly w ith the num erical solution. P u ttin g this in the fram ework of operation propagation, one can use a sequence of operations to su b stitu te th e solution as if the solution were obtained by executing th e sequence of operations operations. T he sequence of operations can then be propagated to the constraint network. T he task of this step is to assemble a sequence of operations based on the num eric solution. T here m ay be m any sequences of operations to m ake th e tran s form ation and it is preferable to find one th a t relates th e solution w ith previous j propagation because it m ay simplify th e later propagation process. Loop op- I erations provide th e tem plates for converting th e num erical solution into proper j operations. One can com pute the param eter values for these operations, based on I th e num erical solution and th e previous coordinates of th e involved objects. For instance, given th e current and th e previous locations of a line, one can com pute th e param eters of a rotation th a t moves the line from th e previous location to th e current one. It is th e reverse process of translating operations into equations. I For exam ple, param eters of th e translation in Figure 5.6(a) can be com puted I from following equations: i i i dx = x l ' — x 1 ; dy — y l' — y\\ ( 5 . 1 0 ) j 9 0 ! \ _____ 1 Figure 5.11: Assemble operation from previous and current positions. P aram eters of the rotation in Figure 5.6(b) can be com puted from following | i equations: Consider the exam ple in Figure 5.8, the previous and current positions are | rot (11,0: 1,pi) , rot (12,a2,pl) . , As discussed in section 5.4.2, th e equations generated from loop equations j I m ay result in an over-constrained system of equations. W hen this occurs, these equations will be w ithdraw n from th e equations to be solved. Therefore, these , operations cannot serve as tem plates for assem bled operations. This problem can be solved by providing an operation tem plate which is general enough to represent j i any possible change of an object type. For exam ple, the operation tem plate for j I a circle can be I a. = arcig( ) - arctg( yi - yQy x l — xQ ’ (5.11) illustrated in Figure 5.11. Two operations are assembled: X / 1 4 p l \ / p 4 Figure 5.12: Assemble operation from previous and current positions, t r a n s l a t e (C, d x , dy ) & set _ ra d iu s (C , r ). T he general operation tem plate for line can be set_startpoint (P ,xl ,yl)&set_endpoint (P,x2,y2). 5.4.5 Propagation back to the constraint network T he assem bled sequence of operations can be viewed as a single transform ation on loop objects th a t sim ultaneously satisfies loop constraints. By rem oving loop j ! constraints from th e constraint network, one gets a constraint netw ork which , needs to be resatisfied. T he last step of loop resolution m ethod is to propagate th e sequence of operations to th e reduced constraint network. Consider the exam ple in Figure 5.12. A fter solving the loop, one gets a new configuration for loop objects 11, 12, and 13 (shown by dashed lines). Two opera tions are assembled: rotate(ll,ai,pl) and rot ate (12 ,a 2, pi) . T he constraint 92 midpoint coincide joint joint 11 12 13 c l 14 anchor anchor j o i n t c o in c id e p a r a l l e l Figure 5.13: T he constraint network and th e propagation process. netw ork (the constraints circled by dashed rectangles are loop constraints) and th e propagation are shown in Figure 5.13. r o t a t e ( l l , a i , p l ) results in c l to be changed and r o t a t e ( 1 2 , 0 : 2 >pl) results in 14 changed. I R ec u rsiv e lo o p s j i T he propagation m ay get in a loop again, because th e solution is still local w ith respect to the whole constraint network. Therefore, th e loop resolution process can be recursive. Two cases needs to be distinguished: 1. Isolated Loop. T he new loop does not interact w ith th e previous loop; i therefore, it can be resolved in isolation. i f 2. Related Loop. T he new loop interacts w ith th e previous loop; therefore, it should be com bined w ith the previous one for a new solution. Now th e issue becomes how to distinguish th e two cases. T he solution is simple: if th e new loop does not involve th e previous loop objects, it can be 93 Figure 5.14: An exam ple of a recursive loop handled in isolation. cl c 9 c l O e l l c l 9 c 2 0 Figure 5.15: The propagation process. resolved in isolation; otherwise, it m ust be com bined w ith the previous loop for a new solution. Two exam ples are given below: E x a m p le 1: Isolated Loop Consider th e configuration in Figure 5.14. As one imposes a constraint to I i link the inner circles (i.e., c l, ..., c7), one ends up solving a loop. T he assem bled I sequence of operations is propagated to outside circles. T he propagation gets j in a loop again because c9 has been changed, outside circles (i.e. clO , ..., c20) ! I 11 12 16 15 17 13 Figure 5.16: An exam ple of a recursive loop which cannot be handled by isolation. j o i n t j o i n t 13 1 1 4 16 17 p a r a l l e l j o i n t Figure 5.17: An exam ple of a m ultiple loop which cannot be handled w ith isola tion. have to be rearranged. The new loop can be resolved in isolation because the propagation does not involve th e previous loop objects. T he propagation process is dem onstrated in Figure 5.15 (the previous loop objects are indicated by double circles). E x a m p le 2: R elated Loop Consider th e configuration in Figure 5.16. T he previous loop involves finding a configuration for the pentagon (involving 11 , 12 , 1 3 , 14 , 15). W hen this is 95 c9 el cO c2 c8 c7 c3 c6 c4 c5 Figure 5.18: T he exam ple w ith a m ore com plicated initial configuration. ! I done, th e operations are propagated to th e rest of th e two lines (16, 17) which ] form a rigid triangle together w ith 15. However, there is another constraint p a r a l l e l (1 2 ,1 6 ) which causes a loop because m oving 16 results in moving 17 and, finally, 15 which is a previous loop object. T he propagation process is shown in Figure 5.17. This problem , therefore, has to be resolved by combining two loops. I I 5.5 Examples of loop resolution i T hree exam ples are given in this section. Each exam ple is carried out in detail, step by step. 96 ! I Figure 5.19: T he constraint netw ork and th e operation propagation. 5.5.1 An example of arranging circles T he following exam ple is th e extension of the exam ple m entioned earlier. The problem is still to find a configuration such th a t cl is tangent to c7, w ith four j l m ore constraints (see Figure 5.18): ^ i I I {coaxial(cO,c8) , coaxial(c0,c9), tangent(cl,c8),tangent(cl,c9)}. As before, im posing constraint tangent (cl, c7) results in a propagation loop. I T he constraint netw ork and th e propagation is illustrated in Figure 5.19. The loop resolution process is explained below. Step 1. Loop tracing: R unning th e loop tracing algorithm , the constraints and operations involved in th e loop are I 97 i loop_constraint_set = {tangent (cl ,c2) , tangent (c7, cl)} loop_operation_set = {rotate(cl , a , cO) , . .., rotate(c7 cO)} Step 2. Equation generation: T he constraints in loop_constraint_set are tran slated into a system of equa tions. For instance, tangent (cl ,c2) is turned into (x l - x 2 f + (y l - y2)2 - r l 2 - r2 2 = 0 (5.12) I where [xl^yl) and r l is the center and radius of cl, (x2 ,y 2 ) and r2 of c2. T he operations in loop_operation_set are tu rn ed into operations. For in stance, rotate(cl, a , center (cO)) is turned into ( s i - sO)2 + (yl - yO)2 - rO2 = 0 (5.13) where (xl, y l) is th e center of cl, (xO, yO) and rO are the center and radius of cO. Step 3. Equation solving: 1 Solve the system of equations using th e N ew ton-Raphson m ethod. Step 4 - Operation assembly: O perations are assembled based on th e solution found in step 3. For each loop object (cl,c2, . . . ,c7), there is an operation to move it. For instance, 1 rotate (cl ,oro, center (cO)) is for cl. ] 98 cl c2 c3 c4 c5 c6 c8. c9J cO, Figure 5.20: Propagation to th e rest of the constraint network. Step 5. Propagation: These operations are propagated to the constraint netw ork sequentially (loop constraints are removed). O perations on c2,...,c7 are absorbed by th e netw ork because of its rotation around th e center of cO. j T he propagation from c l is illustrated in Figure 5.20. It results in c8 and c9 to be correspondingly changed. 5.5.2 An example of arranging a circle in a triangle Consider another exam ple in Figure 5.18. T he problem is still to find a configura tion such th a t cO is tangent to 13. Im posing constraint tangent(cO,13) results , I : in a propagation loop. T he constraint netw ork and the propagation is illustrated ! | | l in Figure 5.22. T he loop resolution process is explained below. i i | 99 | Figure 5.21: An exam ple of loop resolution. i n t e r s e c t i n t e r s e c t i n t e r s e c t a n c h o r a n c h o r a n c h o r c l c 2 c 3 c O 11 12 1 3 t a n g e n t t a n g e n t t a n g e n t t a n g e n t t a n g e n t t a n g e n t Figure 5.22: T he constraint network and the operation propagation. Step 1. Loop tracing: R unning th e loop tracing algorithm , th e constraints and operations involved in th e loop are loop_constraint_set = {tangent(cO,11), tangent(cO,12),(cO,13)} loop_operation_set = {translate(cOjdXjdy.ll), translate(cO,dx,dy,12), translate(cO,dx,dy,13)} 100 Step 2. Equation generation: i T he constraints in lo o p _ c o n s tra in t_ s e t are tran slated into a system of equa- ; tions. For instance, ta n g e n t (cO ,1 1 ) is turned into laarO + byO + cl y/a’ U = r0 ( 5 ' 1 4 ) where (xO,yO) and rO are th e center and radius of cO, ax + by + c = 0 is the line equation of 11. The operations in lo o p _ o p e ra tio n _ s e t are tu rn ed into operations. For instance, tr a n s l a t e ( c O ,d x ,d y ,1 1 ) is turn ed into |ax0 + ^ + C | = rO (5.15) V a2 + 62 ^ > which is th e same as generated by the constraint ta n g e n t (cO , 11). Step 3. Equation solving: Solve th e system of equations using th e N ew ton-Raphson m ethod. Step 4- Operation assembly: O perations are assembled based on th e solution found in step 3. An operation is g eneratedfor cO which is tr a n s la te ( c O ,d x ,d y ,ll) & s e t_ r a d iu s ( c O , r a d iu s ) . Step 5. Propagation: These operations are propagated to the constraint network sequentially (loop constraints are removed). T he propagation from cO is illustrated in Figure 5.23. The operation is prop agated to th e network, resulting in c l, c2, c3 to be correspondingly changed. 101 ! intersect intersect intersect anchor anchor anchor 11 c l c2 c3 cO 12 13 t a n g e n t t a n g e n t t a n g e n t Figure 5.23: Propagation to th e rest of the constraint network. P2 11 P i 15 14 12 13 p 6 Figure 5.24: A linkage m echanism consisting of rigid segm ents and joints. 5.5.3 The example of mechanism analysis j i I Loop cases often occur in satisfying constraints involving rigid bodies and joints, particularly in m echanism design and analysis. T he approach presented in this I paper is also readily useful in th a t area. Figure 5.24 shows a linkage m echanism . The task is to find a configuration such th a t 1 1 is parallel to 13. T he propagation of operation is illustrated on the ! constraint netw ork shown in Figure 5.25. A loop is detected. T he loop resolution 1 I process is dem onstrated by the following steps. 102 loint joint joint joint ^ o in t o n _ l anchor j o in t ] o m t r o t p a r a l l e l j Figure 5.25: O peration propagation in the constraint network. ! ! ! Step 1. Loop tracing: j l i l R unning th e loop tracing algorithm , th e constraints and operations involved ' ! in the loop are: ' I lo o p _ c o n s tra in t_ s e t = {j o i n t ( 1 1 ,p 2 ) , j o i n t ( p 2 , 1 2 ) , j o i n t ( 1 2 ,p 6 ) , 1 j o i n t ( p 6 ,1 3 ) , p a r a l l e l (1 1 ,1 3 )} lo o p _ o p e ra tio n _ se t = { r o t a t e ( l l ,oc\ , p l ) , r o t a t e ( l 3 , a 2 >p5 ) , ' s e t _ l i n e ( 1 2 , x l , y l , x 2 ,y 2 ) } ! Step 2. Equation generation: T he constraints in lo o p _ c o n s tra in t_ s e t are translated into a system of equa- I tions. For instance, j o i n t ( 1 1 ,p 2 ) is turn ed into i i I 1 ll.x l — p2.x; ll.y l = p2.y (5.16) 103 j w here ( ll .x l ,l l .y l ) represents th e coordinate of l l ’s endpoint and (p2.x,p2.y) I represents th e coordinate of p2. O perations in loop_operat ion_set are tran s lated into a system of equations. For instance, rotate (11, o;i, p i) is turned into (x l - x 2 f + (yl - y 2 f - r l 2 = 0 (5.17) , where (xl,yl) are th e coordinates of pi, r l is the length of 11, (x2 ,y2 ) are the coordinate variables of p2. A dditional equations are generated from anchor (pi) and anchor (p5) con straints. Step 3. Equation solving: Solve th e system of equations using the N ew ton-Raphson m ethod. , Step 4■ Operation assembly: I ( O perations are assem bled based on the solution found in step 3. Three oper ations are assembled: i rotate(ll,ai,pl), rot ate (13, < 22, p5), set_line(12 ,xl ,yl,x2,y2). Step 5. Propagation: These operations are propagated to the constraint netw ork sequentially (loop constraints are rem oved). T he first two operations are absorbed by the network, th e th ird operation is propagated to 15, then from 15 to 14, resulting in two 104 11 12 1 3 j o i n t o n _ l i n e j o i n t j o i n t j o i n t j o i n t a n c h o r Figure 5.26: Propagation to th e rest of the constraint network. operations to move 14 and 15 respectively. The propagation process is illustrated in Figure 5.26. 105 Chapter 6 Implementation This chapter discusses th e issues in im plem enting a prototype constraint system called Auto Constrain which serves as th e test-bed for th e proposed approach. An object-oriented paradigm is adopted in the im plem entation process. C onstraints are m odularized into objects w ith their local knowledge — operations to satisfy and m aintain them selves — being im plem ented as th eir com puting m ethods. O p eration propagation is naturally incorporated into th e system ’s message passing m echanism . Some global coordination functions are achieved by having a black board architecture and several system objects serving as coordinators. T he code is w ritten in Oar — an object-oriented program m ing environm ent w ith symbolic reasoning capabilities. 106 6.1 Object-oriented computation O bject-oriented program m ing paradigm s are powerful tools for im plem enting problem -solving system s th a t are m odular in representation, distributive in com p u tation, and decentralized in control structure. AutoConstrain was designed based on th e following observations. • C onstraints are local and independent com putational units. They have th eir own local knowledge to satisfy and m aintain them selves, and can propagate operations and reason about other constraints locally. Therefore, constraints can be m odularized into objects w ith th eir local knowledge being | im plem ented as their m ethods. i • O peration propagation is distributive and carried out by constraints reason ing and propagating operations locally. O peration propagation and local reasoning can be im plem ented through message passing m echanism . i l • T he control structure of th e constraint system is loose. Some central con trol functions, such as loop resolution and symbolic reasoning, can be im plem ented by using blackboard architecture, where global coordination is I achieved by allowing constraints to com m unicate w ith th e system bulletin- I board. ! P u ttin g th e constraint m odel in an object-oriented environm ent, one can view com putation process m ore intuitively. C onstraints and their participants are rep- I ! I , 1 resented separately and treated the same as objects of th e system . Satisfaction is carried out through a message passing m echanism . C om putation is initiated when one object sends a message to another to invoke its m ethod. C onstraint I objects fire operations by sending proper messages to their participants which, in j i tu rn , send messages to other related constraint objects if necessary. O peration i i j propagation is em bedded in objects’ m ethod procedures in term s of m essage pass ing prim itives. C om putation term inates when message passing betw een objects stops. 6.2 The programming environment: Oar A suitable object-oriented program m ing environm ent will facilitate im plem enta tion of a constraint system . A novel object-oriented program m ing system , O ar (O bject and reasoning), is introduced, based on which AutoConstrain is im ple m ented. 108 6.2.1 Oar environment O ar is a system for object-oriented program m ing th a t combines th e power of logic I program m ing for expressing declarative facts about objects and th eir interrela- f | j tionships, w ith th e concept of message passing as the m echanism for triggering ! j th e im perative knowledge associated w ith objects [1 ]. In O ar, general declara tive inform ation about objects and their interrelationships determ ine an o b ject’s behavior. T he details of m anifestation of such behavior are expressed im pera- ! ! ] tively through message passing. T he inheritance netw ork in O ar is dynam ic and ; fluid. T he class m em bership of an object, and thus its behavior, can dynam ically change as m ore facts about its properties and its relationships w ith other objects are introduced. O ar is suitable for highly dynam ic applications w here objects and their behavior m ust evolve through the course of a com putation, as m ore j i inform ation about them and their interrelationship is assim ilated by a program . C om putation in O ar is carried out by two m ajor com ponents: an inference I j m echanism based on first order logic, and a im perative program m ing environm ent j I ! based on message passing. T he two com ponents are closely interrelated through th e notion of objects. Message passing is th e m eans by which objects use the com putational resources of other objects. Message passing in O ar is associative , and uses the inference m echanism to identify the receivers of messages and their m ethods. T he inference m echanism itself is an object whose resources can be 109 used by other objects through message passing. Some of th e interesting features of O ar are presented below. i 1 . Combining declarative and imperative knowledge: In m ost object oriented system s, declarative knowledge can be specified for only one purpose. This is to reflect a lim ited view of how objects are interrelated through a class- j I I instance hierarchy. As in logic program m ing languages, in O ar, declarative | I i knowledge of a general n atu re can be expressed. Such inform ation can affect selection and activation of m ethods of objects. 2. Predicates as object properties: In a language like Sm alltalk, an object is a concrete entity whose structure is determ ined (and fixed) at th e tim e it j I is in stan tiated , by its position in a predeterm ined class hierarchy. Thus, stru ctu ral properties of objects, i.e., their attrib u tes, are induced by this t static class hierarchy, although their values m ay change dynam ically. As in i logic program m ing languages, there is no such distinction betw een structure and value in Oar. In O ar, an object is an ab stract entity th a t satisfies a given set of properties. Properties of an object in O ar are the set of facts (well-formed form ulae in a form al system based on first order logic) known I about th a t object. T he properties of an object include any well-formed t I i form ula th a t can be derived by th e inference rules of th e logical system , as | J well as the ones stated explicitly, i.e., as axioms. 110 3. Dynamic object hierarchy: A distinguished relationship am ong objects in O ar is th e isa relation. This relation defines an object as a specialization of another. An isa relation betw een two objects can be defined as th e logical consequence of some other facts. Thus, in O ar th e equivalent of a class hierarchy is induced by the properties of objects. Because properties of objects can dynam ically change as m ore facts are discovered during program execution, the object/class hierarchy in O ar is dynam ic. 4. Prototype objects: In Sm alltalk, there is a distinction between an object and a class. T he underlying philosophy of this distinction is th e set representa tion of a class. A class is a set of instances where each instance is an object. I Classes can have subclasses. Subclass definition and creating an instance are two distinct operations in this approach. In O ar, a class is represented by one of its typical m em bers, i.e. by an object. This approach is based i i on th e representation of classes as prototypes. In this approach, any object ' represents the class of which it is a typical m em ber. Defining a subclass and creating an instance are both accom plished by th e sam e mechanism: ! defining extension objects through the isa predicate. 1 i 5. Inheritance of properties: Inheritance in O ar is associative. Propagation j of properties through the object/class hierarchy (O ar’s equivalent of inheri tance in Sm alltalk) is accom plished through a special inference rule: the isa 111 inference rule (a different concept than th e isa relation m entioned above). T he com bination of this inference rule and O ar’s m ethod definitions make m essage passing in O ar effectively sim ilar to the delegation m echanism of actor-based system s [1 1 ]. I 6 . Associative binding of methods with objects: Associative inheritance of m ethod properties leads to a flexible and powerful generalization of the binding of im perative knowledge w ith objects. In m ost object oriented program m ing languages, th e binding of m ethods w ith objects is static and | by program m ers’ decree. In O ar, this binding is associative and dynam ic. For instance, it is possible to define a m ethod as applicable to an abstract (class of) object(s) whose properties satisfy th e preconditions of th e proce- i I dure. Thus, any object whose properties satisfy th e preconditions of such ; i a m ethod, will dynam ically inherit th e m ethod. Furtherm ore, this ensures th a t th e m ethod is never invoked by an object th a t does not satisfy its preconditions. 7. Associative message passing: Message passing in O ar is a generalization ' i ! of message passing in conventional object oriented languages. To send a message, an O ar object specifies a message and a qualifier. T he informal sem antics of message passing in O ar is th a t th e sender activates the specified m ethod of all objects in th e closure of the given qualifier. This generalizes 112 th e conventional message passing in two ways: first, there can be m ore th an one receiver for a message, and second, the sender does not necessarily know the receivers beforehand. Associative inheritance, dynam ic object hierarchy, and associative message passing create alternative courses of action. W hen th e message passing m echa nism finds m ore th an one receiver for a message, or m ore th an one m ethod for a receiver, they are taken as representing alternative courses of action. One of these alternatives can be selected nondeterm inistically, or they all can be pursued in ! parallel in a m anner th a t is transparent to th e program , through branching. The user program can also take control and sequentially send a message to all receivers as in a broadcast. For exam ple, a user program m ay want to send a message to all objects whose color is red and let them prin t th eir names sequentially. j 6.2.2 Favorable features of Oar for implementation T he unique features of O ar m ake it a m ore convenient tool for im plem entation j th an other object-oriented program m ing environm ents such as Sm alltalk, espe cially in th e following aspects: • An object can specify the receiver of a message im plicitly in term s of pred icates. This implies m ultiple receivers if m ore th an one object satisfies th e ! i predicate. An object can specify receivers of a message as a predicate, for . | I ; 113 ; instance, as a d ja c e n t (X), m eaning all objects th a t are adjacent to X. This feature facilitates m odeling constraint system s where constraints are dy nam ically changed. T he existing object-oriented system s usually require a sender to explicitly specify a receiver by its nam e. • C onstraints can be represented declaratively w ith th eir local knowledge about operations as th e facts about these constraints in a logic model. Consequently, a constraint can reason about other constraints in m aking decisions. In th e existing system s, an o bject’s local knowledge is encapsu lated into com putational procedures, and an object has no knowledge of other objects’ procedural knowledge. • T he logic inference m echanism , coupled w ith Oar, provides a base to reason about message passing m echanism in com putation. Therefore, operation I propagation and geom etric reasoning can be sm oothly integrated in the message passing m echanism . Traditional object-oriented system s, in con- j tra st, have no general reasoning m echanism outside of a sim ple m echanism for m aintaining inheritance hierarchy. I 6.3 Constraint representation C onstraint types are treated as objects of O ar and, therefore, are represented by object symbols and a set of predicates involving their object symbols. For m | a constraint type, two classes of predicates involving its object symbol are of im portance: 1) c o n s tr a in e c L p a rt(cstr, i, obji) specifies th a t the ith particip an t of con strain t type cstr is obji (obji is an object symbol representing an object type). This class of predicates declaratively defines th e structure of a constraint type. For exam ple, the structure of constraint type tangent (constraining a line and circle to be tangent) can be defined by th e following predicates. c o n s tr a in e d _ p a r t (icm ^ent, 1 , line). c o n s tra in e d _ p a rt(:fa n g e n i, 2 , circle). 2 ) m e th o d ( c s tr , methodna m e, p a ra # , procjnam e) specifies th a t constraint cstr has a m ethod m ethodjnam e which is im plem ented as procedure procjname w ith para# param eters. This class of predicates defines the behavior of a con straint type in response to a message at run-tim e. For instance, tangent has a I | m ethod s a tis fy defined below: 4 m e th o d ^ a n g e n t, s a tis fy , 3, p r o c s a tis fy ) . A t run-tim e, when it receives a message to invoke its s a tis fy m ethod, tangent will invoke procedure p r o c s a tis fy which will satisfy th e constraint by m anipu lating th e line and the circle properly. 115 6.3.1 Inheritance T here is no distinction betw een a constraint type and an instance of th e type. A f 1 constraint type is a prototype of th a t type. An instance of a constraint type can be declared by using an is a predicate. X isa Y declares th a t X is an instance of Y . And X will inherit all predicates involving Y . This is ensured by a special isa inference rule of Oar. | ti isa tangent implies th a t t1 inherits all the above predicates involving I i I tangent. c o n s tr a in e d _ p a r t( ii, 1 , line). c o n s tra in e d _ p a rt(£ i, 2, circle). m e th o d (£ i, print, 0 , p r o c s a tis fy ). I t I l 6.3.2 Representing constraints’ local knowledge I As discussed in th e previous chapters, a constraint’s local knowledge can be represented in term s of operations used to satisfy or m aintain th e constraint, j i In th e O ar environm ent, it can be im plem ented as m ethods associated w ith a j I constraint object. These m ethods can be im plem ented at two levels: m ethod I level and m ethod procedure level. 1) A t method level: i ! ! ! I 116 ! A lternative operations and their preconditions under the sam e m ethod nam e can be im plem ented by different procedures. For exam ple, tangent m ay have three different ways to satisfy itself and, therefore, can be represented by three i different m ethod clauses. I J m e th o d (tangent, s a tis fy , n, m o v e J in e ):- l l co n stra in ed _ p a rt{tangent, 1, X ), n o t(fix e d (A ')). | I m eth o d (ta n g en t, s a tis fy , n, movencircle) con strain ed _p art(tan gen t, 2, X ) , I n o t(fix e d (X )). j i m e th o d {tangent, s a tis fy , n, report-err or). I T he first m ethod clause specifies m oveJine as th e m ethod procedure for | I s a tis fy under a condition th a t the line is not fixed; the second one specifies | 1 m ove-drcle as the m ethod procedure for th e same m ethod s a tis fy under a con- ! 1 j dition th a t the circle is not fixed; th e last one specifies report.error as th e m ethod procedure. 2) A t method procedure level: I 117 The pre-conditions of some operations m ay require extensive com putation and sophisticated control structures. They should be im plem ented inside a m ethod procedure because com puting facilities and control constructs are m ore conve niently available in procedural languages. In general, th e abstract knowledge of a constraint should be represented ex plicitly at m ethod level, while th e specific and com putation-dom inant p art should be im plem ented into its m ethod procedures. T he general form at of a constraint’s m ethod procedure is specified as follows. procjnam e(par\, par 2 , ..., park) char *par\, *par2 , ..., *par^; I I { local — reasoning — and — computation', operation — formation-, ! operation — propagation; ; 6.3.3 Macro constraints i j ! | M acro constraints are the constraints th a t are defined in term s of previously J [ defined constraints. M acro constraints can be nested and, therefore, provide the j m eans to build an abstraction hierarchy among th e existing constraints. T he present system allows one to define m acro constraints by th e following syntax: *m acro-constraintjnam e(obji, o& ?2, •••, objk) char *obji, *obj2, *objk; { constraint-definition-predicates', I }• T he following exam ple defines a m acro constraint which constrains three lines to form a triangle. *trianglejmacro(l\ , /2, h ) j char *Zi, */2, *h\ I { jo in ( h , Z 2); ; jo in (l2, l3); 1 jo in (l3, /j); I }• I I I T he m echanism for m anaging m acro constraints is not im plem ented in the | system . Presently, m acro constraints are sim ulated by ad hoc procedures. W hen trianglejrnacro receives a message to invoke its s a tis fy m ethod, it creates the j sub-constraints in its definition and invokes their s a tis fy m ethod sequentially. Therefore, a m acro constraint does not exist as an object; instead, it creates a few other constraints. In real im plem entation, a m acro constraint should exist as I a real object and have its own com putational m ethods. I 6.4 Equation solver i i ( A special system object called Eqsolver is responsible for solving equations. O ther objects can com m unicate w ith EqSolver through message passing. An object can send a message containing a list of symbolic equations to EqSolver. For exam ple, a constraint m ay send the following message to EqSolver to find th e solution of two equations x + y = 2 and x 2 + y 2 = 10: s e n d (EqSolver, solve, 1, ”x + y = 2, x 2 + y 2 = 10” ). I I I EqSolver returns the following message after solving it. M ultiple sets of solutions are separated by semicolons. s e n d {client^ solution, 1, ”x = 3, y = —1; x = —1, y = 3” ). i i i If it fails to find a solution, Eqsolver will retu rn an em pty list to th e client. I i i i I 120 ! 6.5 Loop analyzer A special system object called LoopResolver is designed to detect and resolve l j propagation loop. Its functions are described below. j Every constraint object preparing to fire an operation will send a message to consult LoopResolver w hether th e operation will result in a loop, and hold for a retu rn message. send(LoopR esolver, consult, 1, ^ in fo rm a tio n —about—operation fir in g ”). i If no loop is detected, LoopResolver records th e message in its local m em ory and returns a proper message to its client. A message record contains th e inform a tion about client nam e, operation, param eters, originating constraint/operation, j . and some environm ent param eters. If a loop is detected, LoopResolver will track all the constraints involved in th e loop based on its previous records. It will determ ine th e n atu re of the loop I ! by taking the following actions: a) it first tries to prove if th e loop results from I 1 satisfying a redundant or conflicting constraints; if this is th e case, it will return a message to its client to stop propagation and restore its last state; b) if not, it , will invoke a local num erical relaxation procedure to handle th e situation. ; 6.6 User interface design User Interface (UI) sits in front of a constraint system and serves as the m edium betw een a user and the system . User interface design is an im p o rtan t issues of AutoConstrain because 1) for a naive user, UI presents th e user w ith intuitive views of th e system ’s functions and meaningful ways to operate them ; and 2) for an advanced user, it provides the m eans to construct one’s own applications j and integrate them w ith the system. A few considerations in designing and I im plem enting Auto Constrain’s user interface are discussed below. 1. UI as an application development tool: UI should provide building con structs for a user to construct domain-specific applications. Different ap- ! 1 plications m ay require different UI structures. UI should be able to be 1 1 ) restructured, therefore, re-com pilable, from a program m ing point of view. Presently, one can modify AutoConstrain’s UI to incorporate new constraint types m anually and recompile it. This is done by sim ply adding a few b u t tons from a construction kit and associating them w ith th e acting proce dures. 2. UI as an operating panel: AutoConstrain1 s UI provides on-line display of 1 the system ’s functions in term s of buttons and m enus associated w ith the ; buttons; a user can operate the system by clicking these b uttons and choos- i ing item s from menus. AutoConstrain provides six m ain function bottom s: 122 J I I constraint, object, operation, move, system utility, and environm ent. Each b u tto n is associated w ith a m enu containing specific function item s. For exam ple, the operation b u tto n , when opened, will display its m enu showing < all th e operations available. A user can invoke an operation by clicking a m ouse button. I 3. UI as a visualization aid: AutoConstrain can dem onstrate a constraint sys- J tern graphically in two ways: 1) viewing an object configuration under constraints graphically, and 2) showing a satisfaction process dynamically. AutoConstrain provides a sketch pad where figures can be draw n and m a nipulated. One can not only view a sketch of figures statically, but also can see th e sketch changing dynam ically when a constraint is im posed - operation propagation is dem onstrated by th e sequence of figure changes on the sketch. AutoConstrain also provides the graphical aids to create I and m anipulate objects, and to impose constraints, by locating and picking j i objects on th e sketch pad. 4. Miscellaneous functions: AutoConstrain provides other adm inistrative func tions, such as file m anagem ent, flag setting, storage m anagem ent, printing, j accessing system inform ation, and adding and retracting facts from logic ! model. 6.7 Limitations of the implementation T he original goal of this im plem entation was to develop a com plete constraint m anagem ent system w ith the following features. 1. T he system can provide a language w ith form al syntax to specify a con strain t system of a specific dom ain, which can be compiled into a running program . 2. T he system will have a powerful inference m echanism w ith equation solving i capability, and will have facilities to incorporate m eta constraints which are either domain-specific or dom ain-independent. I 3. T he system ’s user interface will be re-com pilable w ith respect to some changes (such as to add and remove constraint types), and will have the m eans to dem onstrate a constraint network graphically. i i Lim ited by resources and th e scope of this dissertation, th e current system has accom plished only p art of the original goal. The system can be im proved in th e following directions. • Presently, m acro constraints are im plem ented ad hoc as predefined Prolog clauses and C procedures. A m acro constraint m echanism should be built in the system th a t allows one to define m acro constraints dynamically. 124 Prolog’s inference m echanism is insufficient due to its incom plete im ple m entation and its deficiency in dealing w ith algebraic equations. In the j I I current system , some simple equation solving is im plem ented which is sep arated from logic reasoning process. Coupling equation solving w ith logic system has been proven to be difficult and m ay introduce new problem s when floating-point precision is concerned. The present user interface is semi re-com pilable in th e sense th at, in or der to add constraint types, a user has to modify a few files to add some b uttons and associate th e acting procedures w ith these buttons. Fully au tom ating th e process needs syntactical parsing on th e form al specification I I I of a constraint system , which is related to the language issue. I Chapter 7 i i Conclusion i i i ! C onstraint-based problem solving is a relatively new research field in com puter , I science and constraint satisfaction deserves m ore attention to explore its potential ; } as a powerful problem-solving paradigm . This research is a step in th e direction | i ! of understanding high-level sem antics of geom etric constraints and exploring the use of geom etric dom ain knowledge in satisfaction. This chapter sum m arizes the , results presented in previous chapters and proposes several directions for future work. , i I | 7.1 Summary and contributions i T he m ajor contribution of this dissertation is its presentation of an operational ! approach th a t represents and satisfies geom etric constraints in term s of opera- * I tions, specifically: j ! 126 • An operational constraint m odel is presented where constraints are repre- I ! sented by operations to satisfy and m aintain them . ; l • A satisfaction m echanism to drive the m odel is developed which satisfies a | I constraint in the presence of a constraint netw ork or m aintains a constraint \ network by planning a sequence of operations. j • A planning algorithm underlying the satisfaction m echanism is designed j th a t generates a sequence of operations by propagating operations in a constraint network. , • A geom etric reasoning com ponent is incorporated in the planning algo- , rithm . A set of geom etric heuristics is em ployed th a t helps the generation of efficient and robust satisfaction plans. ] • A loop resolution m ethod is presented th a t handles circular dependency of constraints. It localizes th e interdependent constraints in a constraint netw ork and resolves them in th e same operation propagation framework, i i • T he im plem entation scheme adopted in building AutoConstrain appears j interesting. It has the characterizations of m odular in representation, de centralized in control structure, and distributive in com putation. | 127 . ---- • T he user interface built in AutoConstrain allows one to construct objects | ! and im pose constraints by graphical m eans. It can graphically dem onstrate , ! th e dynam ic process of constraint satisfaction. ' i j j i T he significant difference between th e present operational approach and o th ers is th a t the present one defines and satisfies constraints at high level, while I I I others essentially tre at constraints as algebraic relations and m anipulate them | num erically or symbolically. This operational approach satisfies a constraint by planning a sequence of operations. A satisfaction plan, when executed, will satisfy ' I i th e constraint and m aintain related constraint network sim ultaneously. Dom ain ! knowledge, incorporated as constraints’ local knowledge, is used at the planning I ! stage to derive local changes in satisfaction process. O peration propagation lo- j < ! | calizes th e changes to th e whole constraint network, while geom etric reasoning | minimizes the changes in propagation. The satisfaction m echanism is m ore robust ; in constraint satisfaction th an other m echanisms in two ways. 1. Local propagation avoids unnecessary computation. For exam ple, know- I ing th a t tangency between a line and a circle is invariant under rotation i around the center of the circle, th e system can avoid using the algebraic i : interpretation of tangency in appropriate contexts. In system s based on the i I i ' algebraic interpretations of constraints, however, the transitive closure of 1 equations involving some given variables is used to localize solutions. This I I 128 ; 1 technique is purely syntactical and disregards the sem antics of th e context of constraints. As a worst case, it may end up solving th e whole set of : i constraint equations, whereas th e present approach localizes th e changes to j th e m inim um . ! I 2. The satisfaction result is intuitive and meaningful with respect to the orig- : i inal configuration. T he other system s m ay be able to solve th e sam e set of j i I constraints, however, in less intuitive way. Locality of constraints has been observed by other researchers as well. However, it was achieved at lower lev- | 1 els, such as the technique of propagation of known states and propagation j I of degrees of freedom used in Thinglab [2], which did not reflect th e locality 1 of constraints in semantics. T he present approach, however, achieves it at a sem antic level. j 7.2 Limitations i i i i O perational transform ation planning is essentially a local approach. In densely- connected constraint networks, operation propagation will encounter frequent I loops which substantially reduce th e efficiency of the approach, and in th e worst ( j I case, resulting in solving a whole system of equations numerically. If backtracking j I m echanism is incorporated, in worst cases, the satisfaction planning algorithm has 129 exponential complexity. T he loop resolution procedure m ay have num erical un- | i certainty since one of th e steps depends on solving a set of equations numerically. j ; I In addition, no m echanism has been developed to explore and track m ultiple j I solutions for a constraint problem. i ! j 7.3 Future research j i Lim ited by th e scope of th e dissertation, this work accom plished only p art of the original goal. As such, a few directions are considered for future research. 1 j • Effort can be m ade tow ard designing a general constraint language th a t i efficiently describes geometry. • T he satisfaction m echanism can be im proved to handle m ore sophisticated ' types of constraints, such as m eta constraints and constraints involving tim e, order, and conditions. • C urrent im plem entation is at a prim itive stage and serves only as a te st bed. To build a practical system , one m ust consider a few m ore factors, especially the perform ance issues, such as effectiveness and com plexity of the satisfaction m echanism , which were neglected by this dissertation. 130 j 7.3.1 Toward a constraint programming language , i Designing and im plem enting a high-level constraint program m ing language, based 1 I I on th e proposed operational constraint model, is th e next step tow ard practical i ! i 1 applications. The notion of constraint program m ing language has been proposed : i by several other researchers [22, 20, 23, 10]. However their languages were de- ; l signed and im plem ented at lower levels - essentially at algebraic levels. T h at : prevented these languages from practical uses because their satisfaction mecha- ! j nisms lacked th e ability to handle com plexity and to understand th e high-level j sem antics of constraints. | 1 . . . I 7.3.2 Enhancing satisfaction mechanism I T he satisfaction m echanism can be im proved in th e following ways: loop conver gence analysis, and network transform ation techniques. I i L oop C on v erg en ce A n a ly sis. Propagation loop is not a disaster - it often indicates an interesting phenom enon. It makes operation propagation compli- I i 1 cated sometim es because one lacks an understanding of th e problem . M ost pre- 1 » vious work seems to intentionally avoid this problem by resorting to num erical \ relaxation, which should be used as a last resort. The idea of loop convergence j is analogous to the iterative approxim ation m ethod. O peration propagation is : I I | allowed to go into loop, and each tim e it finishes a round, one m easures how close ; I , 131 ' th e current configuration is w ith respect to th e desired configuration. If it makes th e current configuration closer and closer to the desired configuration, such a | propagation is called convergent, and one m ay term inate it in finite steps to get a j closely-approxim ated configuration. The issue becomes how to generate th e error | expressions and how to m easure global effects. i ' 1 N e tw o rk T ra n s fo rm a tio n T e c h n iq u e s. This idea stem s from th e analogy I 1 j of m athem atical transform ation, where a problem can be solved m ore easily if | i we transform it to another form. T here are m any exam ples in th e proving of | geom etric theorem s. Transform ation techniques m ay provide us w ith another way to deal w ith propagation loop. T he structure of a constraint netw ork can be transform ed to avoid a loop. A simple way of changing a netw ork structure * | is to cut a link to break a loop. However, a great deal of effort is needed to , i I I . ; look deeply into th e circularity phenom enon. A cluster of constraint networks j indicates independent groups of constraints which can be satisfied independently. i Clustering constraints, in some m anner, will m ake the process of satisfaction easier. T here are ways to divide a constraint network into nearly independent groups of constraints, to solve them independently, and then to integrate the I I i' i sub-solutions so as to reduce th e com plexity of satisfaction. This technique m ay - < ’ work well in a loosely structured constraint network. j I ! i 1 3 2 ! * I 7.3.3 F u tu re im p le m e n ta tio n co n sid e ra tio n s As was discussed in the last chapter, im plem entation of the current approach aim ed to serve as a prototype system. Thus m any issues have been ignored. ! i ' Following are a few considerations for future im plem entation. j i : D e fa u lt C o n s tra in ts . Default constraints are constraints which are implic- ' f itly specified but need be enforced. For exam ple, a default constraint m ay re- | I quire th a t th e length of a line not be changed in a constraint satisfaction process. 1 Default constraints can be handled in two ways: 1) by m aking them explicit con- i straints, and 2) by building them into constraints’ m ethod procedures. Choosing j j one or th e other depends on th e system im plem entation and application domains. J i T e m p o ra l C o n s tra in ts . Temporal constraints are constraints th a t are in- ! I ferred from other existing constraints, or introduced by a user, th a t are valid , I j only for a period of tim e. Being capable of handling tem poral constraints makes a system m ore flexible. For exam ple, if two points p i and p2 are anchored, the , I line 11 determ ined by these two points is also anchored. However, when one ' or both anchor constraints on P i and p2 are lifted, th e anchor on 11 should be • lifted as well. How to m anage tem poral constraints should be of concern in future ' i i I I im plem entation. 133 1 D e p th - F ir s t V e rsu s W id th - F ir s t P r o p a g a tio n . An object m ay partic ipate in m ultiple constraints. This results in branching, when an object propa gates operations to its participating constraints. Conceptually, th e branching is I i in parallel. However, due to the sequential nature of algorithm im plem entation, , one needs to sequentialize the branching. Two possible schemes are depth-first propagation and breadth-first propagation. Each of them has its advantages over another in some aspects. For loop detection, depth-first propagation is m ore fa vorable because if there is a loop, it always ends up w ith th e loop directly and it is easy to trace back all the constraints involved in the loop. For geom etric reasoning, breadth-first is m ore desirable because a constraint would coordinate all related constraints in m aking a decision to fire an operation. I M e ta C o n s tr a in t F ac ility . M eta constraints are the constraints on con- ! straints or on th e constraint satisfaction mechanism. M eta constraints can be i viewed as control m etaphors used in th e satisfaction process. Exam ples of m eta | constraints are: I j • A constraint th a t anchors an object and causes backtracking in satisfaction ' process. i • A constraint th a t specifies the conditions under which local relaxation m ight be used to solve a problem. I I 134 • A constraint th a t specifies th e accuracy required by a relaxation algorithm j I (thus th e num ber of iteration). j • A constraint th a t specifies criteria to optim ize satisfaction process. i ; M eta constraints are usually satisfied using heuristics and dom ain knowledge. , I i For instance, a m eta constraint m ay require choosing an operation which causes { l I ! . . . . . I the least effect on rest of network. To satisfy this m eta constraint, a heuristic I i rule m ay choose to fire an operation on one of th e objects involved which has the least connections. Reference List [1] F. Arbab. Prelim inary report on oar: a system for objects and reason ing. Technical report, C om puter Science D epartm ent, U niversity of South ern California, 1988. [2] A. Borning. The program m ing language aspects of thinglab, a constraint- oriented sim ulation laboratory. A C M Transactions on Programming Lan guages and System s, 3(4), 1981. [3] J. Brinkley, B.G. Buchanan, R.B. A ltm an, B.S. D uncan, and C.W . Cor nelius. A heuristic refinem ent for spatial constraint satisfaction problems. Technical Memo STAN-CS-87-1142, Stanford University, 1987. [4] B. Bruderlin. C onstructing three-dim ensional geom etric objects defined by constraints. In the 1986 Workshop on Interactive 3D Graphics. ACM Press, 1986. [5] J. Gosling. Algebraic Constraints. PhD thesis, Carnegie-M ellon University, 1983. [6] R.C. H illyard and I.C. Braid. Analysis of dimensions and tolerances in com puter-aided m echanical design. Com puter-Aided Design, 10(3), June 1978. [7] F. K im ura, H. Suzuki, H. Ando, T. Sato, and A. Kinosada. V ariational geom etry based on logical constraints and its applications to product m od elling. In C IR P , 1987. [8] F. K im ura, H. Suzuki, and L. W ingard. A uniform approach to dimensioning and tolerancing in product modelling. In Second International Conference on Com puter Applications in Production and Engineering, 1986. [9] G. K ram er. Geometric Reasoning in the K inem atic Analysis o f M echanisms. PhD thesis, Sussex University, 1990. [10] W m. Leler. Constraint Programming Languages: Their Specification and Generation. Addision-Wesley, 1988. 136 [11] H. Lieberm an. Using prototypical objects to im plem ent shared behav ior in object-oriented system s. In Norm an M eyrowitz, editor, Proceedings o f Object-Oriented Programming System s, Languages and Applications ’ 86. special issue of ACM SIGPLAN Notices, 1986. [12] R.A. Light. V ariational geometry: M odification of p art geom etry by chang ing dim ensional values. In Conference on C A D /C A M Technology in M e chanical Engineering, 1982. [13] R.A. Light and Gossard D.C. M odification of geom etric models through variational geometry. Com puter-Aided Design, 14(4), July 1982. [14] V.C. Lin, D.C. Gossard, and R.A. Light. V ariational geom etry in com puter- aided design. A C M Com puter Graphics, 15(3), August 1981. [15] J.R . Rossignac. C onstraints in constructive solid geometry. In the 1986 Workshop on Interactive 3D Graphics. ACM Press, 1986. [16] J.R . Rossignac, P. Borrel, and L.R. Nackm an. Interactive design w ith sequences of param eterized transform ations. In the Second Eurographics Workshop on Intelligent CAD System s, Veldhoven, T he N etherlands, 1988. [17] D. Serrano and A.D. Gossard. C onstraint m anagem ent in m cae. In J.S. Gero, editor, Artificial Intelligence in Engineering: Design. C om putational M echanics Publications, 1988. [18] M. Stefik. Planning and m eta-planning (molgen: P art 2). Artificial Intelli gence, 16, 1981. [19] M. Stefik. Planning w ith constraints (molgen: P art 2). Artificial Intelli gence, 16, 1981. [20] G Sussm an and G.L.. Steel. Constraints — a language for expressing almost- hierarchical descriptions. Artificial Intelligence, 14, 1980. [21] I. Sutherland. Sketchpad, A M an-M achine Graphical Com m unication Sys tem. PhD thesis, M assachusetts In stitu te of Technology, 1963. [22] C .J. van W yk. A language fo r typesetting graphics. PhD thesis, Stanford University, 1980. [23] C .J. van W yk. A high-level language for specifying pictures. A C M Trans actions on Graphics, 1, 1982. [24] I.A. Zabala-Salelles. Interacting with Graphic Objects. PhD thesis, Stanford University, 1982. 137 Appendix A j ! ) i , I i ! Macro Definitions ! ] i i 1 i Im plem enting a constraint system in an object-oriented program m ing environ- * m ent m ainly concerns about how to define objects and th e constraints between them . Building m acro mechanisms into a constraint system will facilitate one to define com pound objects from prim itive objects and other previously-defined com pound objects, therefore m aking a constraint system m ore flexible. This appendix proposes a representation scheme th a t defines geom etric objects, con- . ! I I i 1 straints and operations hierarchically. ; I ! A .l Type system i A type represents a class of objects which share some com m on properties. A ! notion associated w ith type system is the instances of a type. A n instance of a i ! 1 i ; j I ! 138 ! | type is a specific exam ple of th a t type. For exam ple, a point p at location ( - 2 ,3 ) I is an instance of type p o in t. Subtypes can be defined by specifying additional constraints th a t the instances i [ of the type m ust satisfy. For exam ple, we can specify a class of points whose x- j coordinates are greater than their y-coordinates as a subtype of ty p e p o in t. A nother im portant concept of type system is inheritance. It sim ply states | th a t any instance of a type can inherit all the properties specified by its type or ! t » super-types. I I A .2 Geometric objects ' A type specification for a geom etric object type consists of three parts: a type , I nam e, its p art specification, and constraints. P art specification includes the 1 ! nam es of th e parts and their types. A p art of an object is itself an object. I T he constraints restrict behavior of its parts. For exam ple, p o in t type can be j defined as: i I i ty p e : p o in t p a r t s : i j x - c o o r d in a te : r e a l ; y - c o o r d in a te : r e a l 139 constraints: {} L in e type can be defined in term s of its starting-point and end-point, which are instances of p o in t, ty p e : l i n e p a r t s : start-point: point end-point: point constraints: {} C ir c le type can be defined in term s of its center and radius, ty p e : c i r c l e p a r t s : center: point radius: real constraints: {} A.2.1 Path specification j i i An object can refer to its parts by m eans of paths from its type specification. For 1 exam ple, a line instance l i n e l referring to its start point, the p ath specification i is l i n e l . s t a r t - p o i n t . j i I However, an object may or m ay not refer to the parts of it parts depending | on some im plem entation considerations. For exam ple, a line m ay or m ay not be , ! ! able to access the x-y coordinates of its starting-point or end-point. ! j A.2.2 Compound objects | More com plicated object can be defined in term s of previously-defined object : types and constraints. For exam ple, a triangle can be constructed by joining I three line segments properly. ! ty p e : t r i a n g l e ! p a r t s : 1 ' I j l i n e l : l i n e l in e 2 : l i n e i i l in e 3 : l i n e i i c o n s t r a i n t s : j o i n ( l i n e l , l i n e 2 ) , j o i n ( l i n e 2 , l i n e 3 ) , j o i n ( l i n e 3 , l i n e l ) . 141 ! Isosceles-triangle can be defined as a subtype of t r i a n g l e type w ith a con- j straint restricting the lengths of its two edges: t ! type: isosceles-triangle superclass: triangle constraint: length(linel) = length(line2). A.3 Constraint types A constraint type can be defined by a nam e and a specification of its participating objects. For exam ple, a constraint th a t requires two lines are parallel can be defined as: parallel(11,12): 11: line 12: line 142 A .3.1 P r im itiv e co n stra in ts T he prim itive constraints are the constraints th a t a constraint system knows j i exactly how to satisfy. M acro constraints can be defined by composing by these 1 prim itive constraints and other previously-defined m acro constraints. A sam ple set of prim itive constraints are: • c o in c id e ( p l,p 2 ) : points p i and p2 are in the sam e position; • d i s t a n c e ( p l ,p 2 ,d ) : th e distance between points p i and p2 is d; • a n g l e ( p l ,p 2 ,p 3 ,a ) : th e angle form ed by ( p l,p 2 ) and (p 2 ,p 3 ) is a; • s lo p e ( p i , p 2 ,s ) : the slope determ ined by p i and p2 is s; • an c h o r ( p i) : the location of point p i is fixed. A.3.2 Macro constraints i i M acro constraints can be defined hierarchically in term s of prim itive constrains ! and previously-defined constraints. A few exam ples are given below where macro j constraints are prefixed w ith a star symbol (*). I A m acro constraint th a t requires two lines to coincide can be expressed by two prim itive constraints th a t force their starting-points and end-points to merge. ♦ c o i n c i d e ( l in e l ,lin e 2 ) < = = > • i I c o i n c i d e ( l i n e l . s t a r t - p o i n t , l i n e 2 . s t a r t - p o i n t ) , 143 1 coincide(linel.end-point,line2.end-point). i A m acro constraint th a t requires two triangles to be coincident can be defined i j by three previously-defined m acro constraints: j < ♦coincide(trianglel,triangle2) < = = > ♦coincide(trianglel.linel,triangle2.linel), ! ♦coincide(trianglel.Iine2,triangle2.Iine2), j I i i ♦coincide(trianglel.line3,triangle2.1ine3). ' i i A m acro constraint th a t requires two triangles to be sim ilar can be defined ! as: | | ♦similar(trianglel,triangle2) I length(trianglel.linel)/length(triangle2.linel)= length(trianglel.Iine2)/length(triangle2.Iine2)= length(trianglel.Iine3)/length(triangle2.line3). t i i We enum erate several kinds of constraints th a t are often encountered. These ' [ ■ constraints can also be defined based on th e prim itive ones. | 1. dim ensional constraints (distances, angles, ...) ! 2. conform ation constraints (tangent, parallel, perpendicular, ...) 3. coincidence constraints (merge, joint, ...) ♦parallel(linel,line2) < = $ ■ slope(linel.start-point,linel.end-point,s), slope(line2.start-point,line2.end-point,s). ♦perpendicular(linel,line2) 4=^ slope(linel.start-point,linel.end-point,s), slope(line2.start-point,line2.end-point,-l/s) ♦join(linel,line2) coincide(linel.end-point,line2.start-point). ♦tangent(linel,circlel,point1) 4=^ ♦coincide(linel,point1), ♦coincide(circlel,pointl), ♦perpendicular(linel,(point1,circlel.center)) Note (point 1, circlel. center) means the line determined by the two points. 145 i A . 4 Operations O perations represent various ways of m anipulating a geometry. Similarly, m ore j com plicated operations can be constructed from prim itive ones and other previously-! 1 ! defined ones. ; i f 1 A.4.1 Primitive operations 1 i Prim itive operations are operations th a t a constraint system knows exactly how j ! to perform . T he set of prim itive operations of a system m ay vary depending on i I application domains. A sam ple list of prim itive operations is given below. • r o t a t e (p i ,p iv o t ,a ) : ro tate point p i around p iv o t w ith angle a; j • t r a n s l a t e ( p l ,d x ,d y ) : translate p i by distances (d x ,d y ) in x-y coordi- | nates; ! I • r e f l e c t ( p i , a x is ) : reflect p i according to a x is ; • t r i m ( l l ,p l ,p 2 ) : trim line 11 between p i and p2; I • t r i m ( c l ,p l ,p 2 ) : trim circle c l between p i and p2 clockwise. I i I | A.4.2 Macro operations 1 M acro operations can be defined based on prim itive operations, previously-defined i ! m acro operations and constraints. For exam ple, a m acro operation th a t translates a line can be defined in term s * . I | of two prim itive operations th a t translate two endpoints of a line. ' I 1 I ! ' *translate(line) <£=>• I j translate(line.start-point), translate(line.end-point), ! i A m acro operation th a t translates circle can be defined in term s of a prim itive ! operation th a t translates the center of a circle. i I ♦translate(circle) < = $ ■ translate(circle.center). ! I Sim ilarly for rotating line and translating triangle: ♦rotate(line,pivot) \ i ; I rotate(line.start-point,pivot), f i ! rotate(line.end-point,pivot). ! ♦translate(triangle) -<==>• ! ♦translate(triangle.linel), i I I ♦tremslate(triangle.Iine2), 1 | ♦translate(triangle.Iine3). , 1 2 Figure A .l: A m acro operation th a t trim s th e corner form ed by two lines. J T he following exam ple defines a m acro operation th a t trim s the corner formed by two lines in term s of two prim itive operations and some constraints (see Fig- ( ure A .l). | Given two prim itive constraints: • t r i m ( l i n e ,p o i n t l,p o i n t 2 ) : trim th e line from p o in tl to point2. • t r i m ( c i r c l e , p o i n t 1 ,p o in t2 ): trim the circle from p o in tl to point2 clock wise). T he m acro operation can be defined as follows: *t rim_corner(linel,line2,circle) trim(linel,pl,p3), trim(line2,p2,p3), trim(circle,pl,p2). Constraints: tangent(linel,circle,pi), 148 tangent(line2,circle,p2), join(linel,line2,p3) 149 Appendix B A Case Study The following is a scenario th a t shows how a design problem is solved on our con straint system. The illustration is divided into steps th a t reflect the interactions between a designer and th e system. B .l A design problem Given two segments L , L I w ith lengths I, l\ and a circle C w ith radius r, design a m echanism which satisfies th e following constraints: • one end-point of L I is on L; • the other end-point of L I is on C; • th e center of C is on the extension of L; 150 L I Figure B .l: A design problem (1). • the end-point of L I on G can move around the circumference of C while j sliding the other end-point on L and m aintaining th e length of L I. I i I | The solution to this problem involves finding an appropriate position for L relative to C (see Figure B .l). B.2 Satisfaction process Denote the start point of line L as L sta.rtpoint? the end point of L as L endpoint and I i ! th e extension of it as Lextension ■ Denote th e center of circle C as Ccenter. \ DESIGNER: create an arbitrary line nam ed L. impose constraints: length(T) = I, horizontal(T). SYSTEM: 151 L Figure B.2: A design problem (2). Ll Figure B.3: A design problem (3). scale L to length I. the impose function for horizontal(L) returns: rot at e (L 5 L s % a r t p 0 t ? ot ) m eaning to ro tate L around its starting point by a proper angle a such th a t L is horizontal. (see Figure B.2) DESIGNER: 152 L I Figure B.4: A design problem (4). ! ! create another line nam ed L I. i I impose constraints: len g th (L l) = l\, coincide(2/lstartpo;rat,L). SYSTEM: i scale L I to length l\. \ i th e impose function for coincide(L lsiartpoint,L ) returns: < translate (L 1 ,dx ,dy ) m eaning to translate L I by a proper distance (dxydy) such th a t its starting point is on L. ' (see Figure B.3) I DESIGNER: 153 L I Figure B.5: A design problem (5). create a circle nam ed C . impose constraints: radius(C ) = r, coincide{CcentenL extension)- SYSTEM: scale th e radius of C to r. the impose function for com cide(Ccenter ,L ei:tension) returns: translate( C ,dx ,dy ) m eaning to translate C by a proper distance (dx ,dy) such th a t the center of C is on th e extension of L. (see Figure B.4) DESIGNER: im pose constraint: co incide(£lena(p 0{ n<,C). 154 SYSTEM: in th e context of th e constraint: comc\& e(Lla tartvoint,L), the impose function for c o in c id e n t endpoint,C) returns: if distance(C'ce„<er-,^lstaj-tpomt)-radius(C') < length(L l) ro ta te (£ l -jL^-startpoint else translate (T 1 . t ydmin )^£rotate( L I jXl stuT (point tra n slate(L l,L ,d m;n) m eans translate L I along L by the m inim um required distance. for th e first case, ro ta te (L l,L lstartp0 jnt,a) is sent to the constraint coincide(L lsjar.tp0in*,L) which decides it can tolerate this operation and no further propagation is required, for th e second case, tran slate(L l,L ,d T O !n )& ro ta te (L l,L lstar<p0int,Q :) are sent to the constraint coincide(L lstartpoint,L). depending on the am ount of translation dmin , either both operations are tolerated by this constraint, or a translate(L ,L ,dmjn) is propagated to L. 155 Figure B.6: A design problem (6). Assume it is th e first case. (see Figure B.5) DESIGNER: pick up a point Pman on C. impose constraint: coincide(L le n £ £ p o i- n<,Pm[m) SYSTEM: in the context of the constraint: coincide(Llstartj ; ,cnni,-L), th e impose function for coincide(L1 endpoint,Pman) returns: tr anslat e( L 1, L , d)& rot ate (L 1, L 1 st artpo % n t • > «) tran slate(T l,T ,d )& ro tate(Z /l,L lstarip0jni,Q;) are sent to th e constraint coincide(L lstartpoint,L). LI Pmin Figure B.7: A design problem (7). depending on th e am ount of translation d, either both operations j are tolerated by the constraint, or tra n s la te ^ ,Z ,d min) is I propagated to L, where dmin is the m inim um distance required for L to move in order to keep coincide(Z/lstartpojnt,L) satisfied. (see Figure B.6) j DESIGNER: remove constraint: com cide(L lendpoint,Pman). { i l SYSTEM: remove coincide(L lendpoint,Pman) from constraint set, nothing is changed in the sketch. i DESIGNER: 157 ! 11 Figure B.8: A design problem (8). pick up another point Pmin on C impose constraint: co\nci&e{Llend point,Pmin) SYSTEM: J i I similar to imposing com cide(L lendpoint,Pman). j (see Figure B.7) ! I B.3 Discussion Several observations about this case study is presented here. • A designer can deal w ith incom plete inform ation when working on a design. One m ay even finish a design w ithout com plete inform ation to im ply a unique solution. This capability is usually missing in other constraint- based systems. It is hard for systems based on algebraic interpretation 158 j of constraints to deal w ith this kind of problems because some underlying constraints are only im plicitly specified. For exam ple, the following two constraints are necessary to im ply a valid em bedding (see Figure B.8): h>d+ r; h < d — r + I (B .l) • Q ualitative constraints and those involving inequalities can be m ore easily satisfied if a designer can interact w ith the system . For exam ple, pick a center for C on the extension of L, place a circle above a line, put a circle inside a box, etc. • Reasoning about spatial relationships symbolically simplifies the com puta tions and avoids problems w ith num erical m ethods.

Linked assets