Constraints, Relationships, and Parameters

My last few posts have mostly just offered my opinion. This time, I’m really hoping to get responses from you, the reader!

 

One of the hot topics when we talk about BIM  is “parametric design.” I hear people talk about constraints and relationships and parameters as though they all mean the same thing, so I wanted to clarify a bit and offer my own opinions.

 

To me, each of the three terms means something slightly different, but all three are used to capture what the designer has in mind when creating the model. That’s the whole point of any kind of adding them to a program: to capture the designer’s intent and to help make changes to the model more quickly.

 

A constraint ties two overlapping elements together. A simple example is the edge of a ceiling that coincides with the face of a wall. Constraining them together will mean that moving the wall will move the edge of the ceiling as well.

 

Even at this basic point, there is a question of behavior: If you try to move the ceiling edge, what of the following should happen?

·         The wall moves with the ceiling automatically, without any notification from the software

·         The wall moves with the ceiling automatically, and the wall is highlighted to tell you that the it moved as well

·         The software tells you that doing so would move the wall as well, then offer you the choice to move it or not (and if not, remove the constraint)

·         The software gives you an error message and gives you the options to undo your change or remove the constraint (like one popular software does….)

·         Some other option?

 

All of these possibilities point to this: should there be a hierarchy of constraints, so that one element can move the other, but not vice versa? Or should all elements in a relationship be treated as equals?

 

Moving on, relationships are constraints with an angle or distance assigned to them. For example, two corridor walls that have their faces set to be 6’-0” apart, so that moving one wall moves both of them, retaining the distance between them. Another option is two grid lines set to be 60 degrees apart. Rotating one line would move them both, but moving one of them would not move the other (since the angle would not be changing).

 

For relationships, what would you want to see?

·         The second element moves/rotates automatically with no notification

·         The second element moves/rotates automatically, highlighting the other elements that moved

·         The software informs you that there are related elements and offers you a choice to move them or break the relationship

·         Some other option?

 

Parameters are the most complex and usually involve some form of mathematical calculation. For example, three windows along a wall that are evenly spaced or mullions in a curtain wall that are 4’-0” on center for the entire length of the curtain wall. If the wall’s length is changed, the windows will re-space themselves. If the curtain wall is made longer, then more mullions are added. A more complex example would be a bow-string truss that has a parameter for the radius of its curve, and changing that radius requires all the elements in the truss to change their length.

 

Once again, there are several ways to handle this. I’ll propose what I would like to see the program do:

1.       Show me the proposed new element locations on-screen.

2.        If more than one option is viable, such as spacing the mullions 4’-0” from the start of the wall or centering the mullions so they have equal space on each end, show me both of them and let me choose between them.

3.       Have an option to remove the parametric relationship and let me move the windows/mullions myself.

 

I want the software to take a guess and, if the guess is wrong, let me discard the guess and manually make the changes. I always want the software to protect my work that I’ve already done. If I spend 2 hours working out a mullion pattern, I really don’t want the software to discard all my work just because I made the wall 1’-0” longer.

 

Lastly, I want to be able to change the nature of a parametric relationship on the fly. Maybe I decide that 4’-0” isn’t the right spacing and, just for design options, I want to make 6 equal-sized glazing panels instead. That should be a quick change and not require me to delete everything and start over.

 

I’ve asked a lot of questions in this post and proposed how I would like to see parametric relationships work. If you agree, disagree, or have some other alternative altogether, please comment!

 

 

Parents
  • Tom-

    that's a lot to digest in a single post, but i'll give it a shot!

    i'd take the terms in reverse order.

    a parameter, in the sense of "a function's parameter" is a value used as an input to a function. a different value causes the function to return a different result. Could be static value, like a number, or a pointer to some other property of something else. As you indicate, a parameter is often a dimension in parametric modeling.  That is, the "thickness" parameter, as input to a place wall function, assigned a value of 100mm,  causes the parametric wall to take on a 100mm dimension along one edge. presumably its possible to edit the parameter value to say 250, and update the wall, and all other things being equal, the wall will take on instead the 250mm dimension along that edge.

    I see 'the calculation of the value used as the parameter to the wall function' as a separate exercise. In your example, the calculation of the exact even spacing which divides a curve into approximately 4' segments is a separate (upstream) function that takes as its "desired spacing" parameter  the value  4' and the input curve parameter the pointer to the curve element, and the function returns the exact spacing, or something that can be used as the location parameter for the 'place mullion' function. Perhaps there's something managing the relationship between the output of the 'calculator' function, and the 'place mullion' function, so that i can change the desired spacing parameter, to say 5', and it does its thing, and returns values that the 'place mullions' functions use to re-do their thing.  When you mention changing the relationship, as in change from equal spacing close to a desired dimension to a equal number of bays, in GC-speak we're swapping out one update method for another, and GC is very usable in this area!!

    next, the relationship.  You indicate two kinds, but then again maybe its all one thing. First you discuss element-to-element association. If i place a wall, and when specifying the height parameter, i instead choose "go to the underside of [selected] ceiling element" as the value of the height parameter, then maybe the software can maintain an association between the wall and ceiling element, that reminds the the software that any change to the ceiling needs to trigger an update to the wall. So i move the ceiling, and the wall knows to re-run its place wall function with the update to the height parameter, or the new location of the ceiling.  Association is really cool! its my favorite part of the phrase "associative parametric modeler"  used to describe GC. But in the spirit of a dynamic complex adaptive system, too much connectivity- too much order- brings the system to a halt. Too little, and its chaos. Complex order, argues Stuart Kaufman, sits at the delicate balance between too few and too many associations.

    Now to the constraint. I really dislike this word, and its place in modeling design intent.  When we write custom software here, we structure the data and the exchange of data only to the extent that we must, in order to maintain a productive flow. What does that mean? Say we're generating a surface by lofting between a set of curves. The way those curves were generated cannot be assumed. We have to expect that there is no rhyme or reason to them. They were sketched. The surface generator, not knowing their order, must sort them, test them for applicability as section curve inputs, and then they can be used as inputs to the function. Often, once we establish some sort of predictability, we can encode the anticipated curve reasoning into surface generator. (I say "we," but really i mean one guy from our office- Satoru Sugihara, the true genius who writes code for us.) But the design process is characterized by working often in areas where there is not yet a reason. And so, the notion of constraint, as in a control that comes even before the opportunity of freedom of choice, is tough to swallow. But maybe this is not a current way to think about it. If our constraint-forming and -managing engines are faster than a human designer can choose, then there might be a way forward. Certainly we see the benefits of making things computable.  This is an important area of research. Your point about "capturing the designer's intent" is a valuable area for development.  The Smart Geometry movement has encouraged teaching designers to become more comfortable thinking about design in explicit terms. All the while i hope the software becomes more usable to allow us to think in ways that we usually do when we're thinking about design in implicit terms.

    But maybe this is not exactly on-topic. If i can re-characterize the latter part of your article, and start to flush out the discussion we started in Philly: What kind of system would allow you to change the point-in-time of the decision, from the time you specify the input, to the time you interrogate the output. the inputs would be sets of "maybes," and thus so are the outputs, and by process of selection of the output, the inputs are chosen. Those "maybes" could be just about anything that satisfies the requirements for that parameter of the function. Or, in the case of the curtainwall gridlines, how can the gridlines retain some sort of imprint that it was a common calculator function that put a bunch of gridlines into their location by sending them a set of values as their location input parameters. Not that there needs to be a persistence to the calculator and an association maintained between the calculator output and the gridlines' input, but maybe a designer would benefit by picking all of the gridlines put down by a common method, and maybe then run a new calculator function to supply a new set of values for their inputs. Or, maybe the gridlines can be dragged to some place where maybe the designer wants to see them. Not that forgetfulness is highly valuable (at some point, very far down the road, it will be helpful for a designer to explain to a curtainwaller that the spacing is the result of a desire to have the mullions equally spaced, so that when the wall changes length due to other reasons, then the exact values locating the mullion gridlines is again re-calulated. But this is very far down the road, and maybe doesn't need to factor into the design exploration happening on any given day)

    Thanks very much for opening up the conversation.

Comment
  • Tom-

    that's a lot to digest in a single post, but i'll give it a shot!

    i'd take the terms in reverse order.

    a parameter, in the sense of "a function's parameter" is a value used as an input to a function. a different value causes the function to return a different result. Could be static value, like a number, or a pointer to some other property of something else. As you indicate, a parameter is often a dimension in parametric modeling.  That is, the "thickness" parameter, as input to a place wall function, assigned a value of 100mm,  causes the parametric wall to take on a 100mm dimension along one edge. presumably its possible to edit the parameter value to say 250, and update the wall, and all other things being equal, the wall will take on instead the 250mm dimension along that edge.

    I see 'the calculation of the value used as the parameter to the wall function' as a separate exercise. In your example, the calculation of the exact even spacing which divides a curve into approximately 4' segments is a separate (upstream) function that takes as its "desired spacing" parameter  the value  4' and the input curve parameter the pointer to the curve element, and the function returns the exact spacing, or something that can be used as the location parameter for the 'place mullion' function. Perhaps there's something managing the relationship between the output of the 'calculator' function, and the 'place mullion' function, so that i can change the desired spacing parameter, to say 5', and it does its thing, and returns values that the 'place mullions' functions use to re-do their thing.  When you mention changing the relationship, as in change from equal spacing close to a desired dimension to a equal number of bays, in GC-speak we're swapping out one update method for another, and GC is very usable in this area!!

    next, the relationship.  You indicate two kinds, but then again maybe its all one thing. First you discuss element-to-element association. If i place a wall, and when specifying the height parameter, i instead choose "go to the underside of [selected] ceiling element" as the value of the height parameter, then maybe the software can maintain an association between the wall and ceiling element, that reminds the the software that any change to the ceiling needs to trigger an update to the wall. So i move the ceiling, and the wall knows to re-run its place wall function with the update to the height parameter, or the new location of the ceiling.  Association is really cool! its my favorite part of the phrase "associative parametric modeler"  used to describe GC. But in the spirit of a dynamic complex adaptive system, too much connectivity- too much order- brings the system to a halt. Too little, and its chaos. Complex order, argues Stuart Kaufman, sits at the delicate balance between too few and too many associations.

    Now to the constraint. I really dislike this word, and its place in modeling design intent.  When we write custom software here, we structure the data and the exchange of data only to the extent that we must, in order to maintain a productive flow. What does that mean? Say we're generating a surface by lofting between a set of curves. The way those curves were generated cannot be assumed. We have to expect that there is no rhyme or reason to them. They were sketched. The surface generator, not knowing their order, must sort them, test them for applicability as section curve inputs, and then they can be used as inputs to the function. Often, once we establish some sort of predictability, we can encode the anticipated curve reasoning into surface generator. (I say "we," but really i mean one guy from our office- Satoru Sugihara, the true genius who writes code for us.) But the design process is characterized by working often in areas where there is not yet a reason. And so, the notion of constraint, as in a control that comes even before the opportunity of freedom of choice, is tough to swallow. But maybe this is not a current way to think about it. If our constraint-forming and -managing engines are faster than a human designer can choose, then there might be a way forward. Certainly we see the benefits of making things computable.  This is an important area of research. Your point about "capturing the designer's intent" is a valuable area for development.  The Smart Geometry movement has encouraged teaching designers to become more comfortable thinking about design in explicit terms. All the while i hope the software becomes more usable to allow us to think in ways that we usually do when we're thinking about design in implicit terms.

    But maybe this is not exactly on-topic. If i can re-characterize the latter part of your article, and start to flush out the discussion we started in Philly: What kind of system would allow you to change the point-in-time of the decision, from the time you specify the input, to the time you interrogate the output. the inputs would be sets of "maybes," and thus so are the outputs, and by process of selection of the output, the inputs are chosen. Those "maybes" could be just about anything that satisfies the requirements for that parameter of the function. Or, in the case of the curtainwall gridlines, how can the gridlines retain some sort of imprint that it was a common calculator function that put a bunch of gridlines into their location by sending them a set of values as their location input parameters. Not that there needs to be a persistence to the calculator and an association maintained between the calculator output and the gridlines' input, but maybe a designer would benefit by picking all of the gridlines put down by a common method, and maybe then run a new calculator function to supply a new set of values for their inputs. Or, maybe the gridlines can be dragged to some place where maybe the designer wants to see them. Not that forgetfulness is highly valuable (at some point, very far down the road, it will be helpful for a designer to explain to a curtainwaller that the spacing is the result of a desire to have the mullions equally spaced, so that when the wall changes length due to other reasons, then the exact values locating the mullion gridlines is again re-calulated. But this is very far down the road, and maybe doesn't need to factor into the design exploration happening on any given day)

    Thanks very much for opening up the conversation.

Children
No Data