Constraints, Relationships, and Parameters

Let me just say: Wow!!!! Thanks for great and detailed comments. There are ideas and points in here that I never considered, and that is exactly why I asked for them!

I hope you will all be along for the ride as we move forward :-)

Hi Tom,

Eventually, I think you need to look at the history surrounding these three terms, to get a productive understanding of them. Most of them originated in the MCAD world and have been implemented there. I think CATIA V5/6 has the most interesting, app to look at. It has the widest range of approaches or 'workbenches'. Plenty of stuff on YouTube, including tutorials on Digital Project.

The animation world is also a good source for precedents; look at SideFX's Houdini for an idea of what Mstn could be like if it was GC'd over. Another interesting sector is the rules-based apps in the Plant world. And, CityEngine. They pretty much all use the terms parameter, relationship and constraints, but in significantly different ways.

In the AEC world, its worth looking at Rhino, which has been very successful in attracting 3rd party developers that have given Rhino some very powerful 'parametric design' tools. See LEDAS' RhinoDirect for MCAD style constraints solving; RhinoParametrics for MCAD style procedural feature based design; T-splines for sub-D type modeling; Grasshopper for GC for Houdini/Maya style scripted 'dataflow modelling';  StrucDraw for some interesting 'event watcher'-based ways of node-based modelling.

Rules-based examples are harder to come by. PDMS 12 has a new and interesting approach using association objects/nodes that are open to rules based methods. CityEngine 2010 is based on a geometric grammar and has now got a GC/GH-like visual scripting interface. I suspect that the dataflow/DAG approach that GC embodies really needs to merge with rules-based world soon, or at least try. Constraints solving is probably being added already? See PowerCivil's Civil Geometry Platform. Where is Bentley's Design++ at, the world wonders.

1. Parameters: Or do we really mean arguments?

Stephen's Scenario 1:

- touches on two different mechanisms:

a. Named Groups Propagation: Mstn commands acting on a collection of elements, collected on the basis of their user attached attributes (Named Group). The arguments used as part of the command are not saved / persistent. They could be. I guess, using a macro recorder- See Modo's Toolpipe ? I guess, the info can be saved as an attached attribute to the named group. Rhino's implicit history? Or like RhinoParametric's nodes?

What if we don't care about saving the manipulation info ('parametrication' for later adjustment or reference by others)? What if we are content with propagating changes to multiple elements. Move slab also moves wall, and vice versa. The current Named Groups facilitates this already, but I can see the need to name group everything properly in advance being a real drag. It would be good if Mstn could expand the active attributes settings to include Element Templates and Named Groups, so that the creation of new elements with these additional attributes would flow better.

Going further: The user could use the Named Expressions to provide a more flexible version of the 'Respect Relationships' functionality, found in Triforma. Moving a slab will move the bottom of the wall, not the whole wall. Putting a kink in the slab would put a kink in the wall as well, using existing tools. This means stacking a number of tools (Tool pipe?) to act on the relevant geometric elements. InfoSnap already can collect tools for a context menu, based on the highlighted element. I guess, it would be easy for Mstn to recognise and collect the two elements based on their proximity. It would seem like both wall and slab element were sharing parameters, without re-jigging the whole file format.

How will the multiple tool settings be handled? We are after all using multiple tools. Some error trapping / warnings will be needed based on the tool / element type combinations.

Maybe, the user could build a dynamic inference framework, so that similar elements can be collected dynamically. See Solid Edge's Live Rules. Or, ArchiCAD12 Curtain Wall's directional selection tools. Live Rules / Synchronous Tech is pretty radical as it tries to infer patterns and parameters, as opposed to just reading predefined ones.

b. Fields: I think Fields are one way links only. Editing the displayed text does not update the corresponding attribute value in the geometric element. This two way or 'parametric' behaviour can be seen in the way Feature Solids work. This is where the geometry is defined 'parametrically' and the values used are accessible. Problem I think is that exposing all the info defining the normal Mstn elements will bloat the file and slow things down. Currently, you can modify the x,y,z coordinates info via the Element Info Dialogue. But you can't force it to look up a value, like you can with Feature Solids. A good metaphor here is the spreadsheet. MCAD apps have really explored this in depth. I think Inventors' iLogic / iCopy is a pretty good example to look at if you want to understand how this kind of 'parametric design' can be incorporated into Mstn.

Speadsheet cells can contain values, formulas, even little subroutines+ data trees? that are interdependent. GC/GH and Houdini/Maya all use a DAG to allow the user to steer the solving (propagation?) sequence. Like Excel, they don't like circular references very much. Powerful, but too 'hard coded' to be context sensitive to be really useful most times. Design++ is based on a Frame-based Object System, which recognises that a lot of attributes need to be evaluated to steer a solving sequence. So, the 'cells' in the Design++ 'spreadsheet' are more verbose, and propagation is not fixed, which can be problematic when it gets lost and takes off on a 'frolic of its own'.

The cells can also be locked, and routines suppressed / constrained. How will the solving sequence cope and re-route the solving? Possible with GC? Maybe Bentley should look at something like MZ-Platform. One easy way to handle this is to bump the locked 'parameters' to the start of the solving sequence. Perhaps, points are a good starting point. They mimic mouse based input (important advantage!). A line, curve, cone etc can all be defined as a bunch of points. The point attributes refer to a spreadsheet and solved first? and grouped together with its resultant CAD command generated geometry as an 'object' ? Kinda sounds like early GC or RhinoParametrics.

I suppose Revit's separation of reference versus construction geometry allows it to prioritise solving reference geometry first in a similar way. I guess, by using points, I am hoping to limit and streamline data exposed to the user and spreadsheet. The 'hot points' could use the same Named Groups propagation scheme and dynamically replace the relevant, user-selected Element Info. So, Moving a hotpoint, would propagate to the appropriate points (in terms of x,y,z coords) in both the wall and slab. It would seem like both wall and slab element were sharing parameters, without re-jigging the whole file format.

Further, I guess you could also tag the active Accudraw info or ACS into the 'hot point' to help the user on the return visit. Why not save a whole recorded macro, saved as a linked file?

Further still: I like the way PDMS 12 addresses problems like pipe penetrations, by attaching a associative object (point or node) to the intersection between the steel beam and pipe. The point encapsulates the relevant info and linkage info so that changes in one element can propagate to the other, regardless of the creation history (GC's Achilles Heel). It refers to a user defined rulesbase to generate the appropriate actions or 'behaviour' to re-establish a 'proper' pipe penetration. Bentley: Design++, but easier, please?

Stephen's Scenario 2:

Driving the height parameter with a formula is a typical spreadsheet technique. See above.

Driving Dimensions?: Are really powerful and intuitive to use. I think this way of working has a lot of relevance in the AEC world, where there will always be a need to deal with lots of dumb geometry efficiently. They are integral to the history free modelers like LEDAS' Driving Dimensions for Sketchup, RhinoDirect, Kubotek KeyCreator, SpaceClaim, Cocreate, Solid Edge, NX. I guess, Revit and BA's HUD dimensions are similar. They provide an alternative way of selectively providing 'parametric' functionality to non-procedural or 'dumb' geometry. I suppose it would be relatively easy to move a dimension's witness endpoint based on user input and propagate changes to the dimensioned object. Mstn's DDD already can do a lot of this. The dimension string element would need to extended to include a concept of base or anchor point so that the user can control which end (or both) moves. It would be easy to allow multiple objects to be driven by the same dimension point like CoCreate 17.0. With a bit of work, it would be great if Mstn could target and drive the position of multiple sub-element primitives like edges, vertices, faces.

So, looking at our wall + slab example: The driving dimension would act as an intermediate controlling object. One end of the dimension is keyed to the bottom of the upper slab, and the other end keyed to the top of the lower slab. When the lower slab is moved up, the dimension acts as a normal 'reference' dimension, but will need to propagate its updated length value to the wall. But, mentally, the user associates the dim with the wall, so he will expect the dimension to drive the height of the wall when he edits the dimension text. The dimension will need update the slab position in this case. This could in turn trigger more propagation 'upstairs'. So, will all upper slabs be 'pushed' up? or will the next higher wall shorten? Yikes.

2. Relationships

Marty mentioned 'parametric' and 'associative' relationships. For discussion's sake, let's say that relationships can be grouped into two camps, based on whether they are linked.

a. Imperative relationships: These are relationships that are one way and strictly hierarchial. Procedural apps like GH/GC and most MCAD history based feature modelers fall into this category.

b. Declarative relationships: Relationships are bi-directional. The best example is the geometric constraints modeling, where the relationships;- algebraic(length/x etc), geometric (coincident, perpendicular, tangent, parallel etc) and dimensional (length, angle) are declared and solved as a set of simultaneous equations. I think a lot of solvers and simulation software work like this as well. Sometimes, I think solvers are really just procedural apps that can deal with circular references. Real geometric constraints solvers have enough mathematical classiness that they can tell you when the system is under or over-constrained....

I think most systems are really a combination of both. The typical MCAD package like CATIA uses constraints solving in controlled contexts like sketches or as mates within an assembly. This approach is successful, I suspect, because the number of constraints / relationships 'in play' are always restricted in a understandable way. Look at the way DP uses sketches to define walls, in particular, the way it can define and modify the geometric relationships between elements without worrying about the creation history, because the relationship is declared as part of a set of simultaneous equations. Once the sketch is closed, the 'wall' objects are regenerated based on the revised sketch.

The sketch acts a 'seed' or 'schematic' view of more verbose constructs downstream. This is a really powerful way of working that chimes with the powerful recursive and procedural techniques available. If you look at AC12's CW tool and the way the Schematic View can be isolated and manipulated, the ease and flexibility is hard to ignore. The way the key geometry is isolated and contained also allows the vendor to provide a more responsive object that can interact with the user, because they can do the required use case testing and error trap within a combinatorial restricted environment.

ACAD and VectrorWorks also offer constraints solving, but without containing them in sketches. I think this is great, if they eventually provide a dependency view to help the users avoid 'spaghetti' dependency networks and allow the user to nest constraints sets (Dynamic blocks that can propagate with each other?). Bentley's PCS was pretty cool in the way it could inherit constraints.

Back to the wall + slab example: You could use 'skeleton modeling' techniques that are widespread in the MCAD world. The user would define a geometric skeleton in a sketch that would drive both the wall and slab. The interface between the two elements is abstracted to a simpler geometric element like a line or plane (or even a 'hot point'). The elements can have an offset from the plane using simple parametrics. Even, if the sketch isn't assisted by a constraints solver, the fact that we have a one to many propagation will go along way, 'parametrically' speaking.

3. Constraints:

See 2.b above.

Also, its worth noting that sometimes parameters can be made to look like constraints. See VariCAD 2010's new constraints. If you only allow the user to modify the z position parameter of an element, you could describe this as being 'constrained' to the z axis, without any solving.

What about Revit? I think it falls into the same category. By 'constraining' a construction element to a reference line/plane etc is really just sharing or chaining parameters, no constraints solving. Revit was described a 'context sensitive parametric change engine' that would avoid the long regen chains that plagued MCAD modelers.

OK. Let's ignore the lack of 'real' GCS. Revit's families are still difficult to figure out because it isn't always clear how the components behave and propagate in context. We know walls are slaved to levels. We know windows/doors need to be hosted by a wall. Walls are projected up to roofs and trimmed. But, how all the individual parameters are shared, chained or propagated is pretty much hidden. I guess its no wonder, most users do not expect the slab / wall abutment to be linked.

Having said that, Revit 2011's Massing family and Adaptive Components are pretty powerful. Would be interesting to see what Revit comes up with next, and what GS does with its System Technology.

Hi Tom

In summary, as I see it, the Constraint is either applied to the Object Origin or a Dimension of that object.

Depending on whether the constraint is set in both objects will determin the relationship

Parameters just need to be a variable list with formulas and limit options

Regards

Stephen

Scenario 1 - Constraining an object to another object by origin

A wall and a ceiling are constrained together.

They should have either an active relationship (in this scenario if the slab moves the wall moves with it and vice versa).

They have a passive relationship (the first element selected will move the second but the second element will not move the first).

The objects do not have to be physically connected just their origins relative to each other are constrained together.

This is similar to current behaviour with graphic groups and active and passive relationships

In these terms you are effectively inserting a "Field" element property into the Origin Coordinates of one or both object.

Wall Origin.X = Slab Origin.X

Wall Origin.Y = Slab Origin.Y

Wall Origin.Z = Slab Origin.Z-300

Depending on the relationship (Passive or Active) Slab Origin XYZ may be defined as the reverse of this.

-----------------------------------------------------------------------

Scenario 2 - Constraining a Dimension of the object

The Height Dimension of the wall is constrained by the Z Height of the slab

If the slab moves the height of the wall adjusts to match the height of the ceiling.

This may have a formula or parameter added into the dimension

e.g. Wall Height Dimension = "Constraining Object Z Height" - 150

I see this working in a similar fashion to inserting a field of an element property.

Edit the dimension...insert element property, click on slab and choose the Z origin and it inserts it as a value into the dimension as a "field"

additional fomulas can then be added ... it would also be useful when you click on the "field" in the dimension that it hilights the element it is the property of...

For more complex scenarios a Dimension Element itself can be constrained by start and end points linked to other objects and by size formulas.

---------------------------------------------------------------------

Given the potential complex relationships I do not want warnings asking me if another element should move on a fully parametric building I would be there all day saying yes.... I, am adding the constraints, so I don't need to be asked afterwards if it should happen.

In terms of warnings, if I am constraining an object, then the only warnings I want are that it is over constrained and their is a clash, or to hilight objects that have changed as a result of an element manipulation, perhaps in a hierachical tree dependency diagram (similar to the projectwise file dependency diagram but for elements).

In terms of seeing where the constraints are I want to to be able to right click on an object and to "show 1st level constraining object" which will hi-lite the slab if the wall is clicked. Then to have an option to show the dependency heirachy in a tree diagram to show the multiple levels of dependencies and to be able to hi-lite them by clicking in the tree diagram.

----------------------------------------------------------------

Finally Parameters

I just need a set of variables like those in GC where you create a variable and have it is as slider or a fixed value or as a formula based on other variables.

Just some Friday night thoughts to add into the melting pot...

Regards

Stephen

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.