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
  • 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.

Comment
  • 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.

Children
No Data