Constraints: Priorities?

I've been inspired to have another go at using Mstn Constraints and Parametric modeling.

As mentioned elsewhere, Revit can be a bit too reliant on Work and Reference planes when it comes to modeling. Setting up all those 'constraints' geometry then binding the primary geometry to the reference planes can be a bit much. Using a Revit toilet cubicle example, I thought that I would try to replicate the design in OBD U9.2 (Mstn 16.3).

I have to say, I ran into all kinds of problems trying to use 3d Constraints to position elements parametrically with respect to each other. So, I went back to setting up some 2d construction geometry that I would constrain first. This is similar to the old DDD workflow.

1. Place two Lines so that they intersect each other, the use the 2d Coincident Constraint to constrain a 3d solid to both Lines. The result is not very useful. Moving the any of the Lines is blocked. And you will can not move the Cylinder to follow the lines. Moving the Cylinder does move the constrained lines. So, not  the bi-directional constraints solving behaviour you would expect. Doesn't matter if you pick the Lines or the Cylinder first. BTW: the Cylinder is intended to replicate the cubicle partition supports in the Revit vid above.

2. Redo the steps but instead constrain a 2d Circle to the lines. Flexing either the Circle or the Lines work as expect. The geometry moves around to preserve the coincident relationships. Bravo!

Now, you can constrain concentric the 3d Cylinder to the 2d Circle which is constrained to Lines. And move any of the four elements around and the Constraints work as expected.


It would be good if Bentley could publish some info on how the constraints work with each other and when both 2d and 3d elements are involved. Most users would not expect to have to use a 2d 'go between' to control a 3d element. Is there a priority list involved? Is the solver looking to solve 2d to 2d constraints first? And if it finds a 3d element in the solving set it moves to a 3d first or only behaviour?

It would be good to know. At the moment Revit is winning when it comes to ease of use.


  • Hello Dominic,

    It's not the best idea to use a 2D constrain tool on a 3D element. I would create 2D elements, the two lines first, coincide them the create a circle that I would coincide with one of the lines. Then Extrude the circle into a solid. 

    Please refer to the following video on the Best Practice on the design intent and constraints in MicroStation Part 1 Parametric Modeling: Intent and Constraints - YouTube



  • I would create 2D elements, the two lines first, coincide them the create a circle that I would coincide with one of the lines. Then Extrude the circle into a solid. 

    Hi Aimable,

    Curious about how much experience you have with Mstn 2/3d Constraints?

    The issue of mixing Constraints is unavoidable due to the lack of functionality provided. Acknowledged problem on many levels. See archived Microstation Insiders discussions.

    Just advising users to avoid mixing is not very helpful. Probably said before as well. The reason why we do it is because it is not clear how to do what we want otherwise.

    All MCAD apps have started with this 2d Constraint sketch then extrude way of working. They all end up providing 3d sketch planes that are coordinated with each other and even 3d constrained sketching. In the AEC sector, Revit also had to provide Adaptive Components to support AEC modeling tasks that are very different to the old and basic MCAD sketch and extrude a part jobbies.

    I find your post worrying as it suggests that all is well just dont do this... pretty annoying for users who end up hitting a ceiling later. Even more annoying if it gives the dev team the impression that they have cracked it. No reinforcements needed. Its just a user education thing. Look our support colleagues seem to think so as well.

    PS: the Youtube vids are rather useless as they tend to stick to MCAD style solid modeling type exercises, or for simple 'one degree' of freedom type objects like lighting poles where there is just about enough functionality.