It is implemented on Mac but there’s no way to get to it currently. It will be switched to CTRL + Right Click in the near future to support be able to support Mac. I’ll add a note to the issue.
The “Constraints” feature is very exiting! Here are some observations after experimenting with the WIP; I’m hoping some of these ideas are on the roadmap (please do tell).
Imagine I’d like to manufacture a basic bracket that I would create on a CNC machine. The bracket has four holes in it:
By simply updating the “WIDTH” and/or “HEIGHT” variable (a “named” dimension), the holes automatically are placed 1.000u from the edges as per the defined constraints:
How can we get there with the Rhino 8 WIP “Constraints” feature? Here are some more thoughts…
There seems to be some confusion around the difference between constraints and dimensions:
Constraints (e.g. Equal Length, Perpendicular, Horizontal, Vertical) have objects as parameters; such as how Equal Length needs two lines (objects). These input objects are listed under the Constraints node in the panel. All of this seems logical.
Dimensions (Height, Width, Angle) seem to deserve a separate node in the Constraints panel. Whereas they are “constraints” of a sort, they differ from the above category in the sense that they equate to numerical values. It’s these dimensions that people will want to edit the values of.
Variables. I’d like to be able to specify parametric relationships, such as being able to define a rectangle using expressions (formulas):
- HEIGHT = WIDTH / 2
- WIDTH = 10
In Rhino, imagine we added a “Dimensions” node in the tree:
NOTE: THIS IS A DESIGN PROPOSAL AND SCREEN MOCK-UPS ARE BY ME, NOT THE ACUTAL RHINO IMPLEMENTATION BY MCNEAL
First note that the names of the dimensions are considered named variables that can be referenced by other dimensions. In this example,
Height is a so-called “driven dimension” and is defined in terms of other variable(s), in this case it’s
Width / 2. The implementation would need to enforce sane variable names typical of programming languages, such that
Width (1) would be invalid due to a space and parens, however
Width1 would be a valid dimension (variable) name.
TODO: Figure out namespacing, such that one Sketch could refer to another Sketch’s dimension variables. This might amount to enforcing similar naming rules for Sketches.
Next, note that the values (displayed in bold) can be edited by double clicking on the bold value:
A grid view might make more sense than what’s illustrated, but the important concept is that the value can be edited and that the value is on the same line in the tree view. The tree/grid view makes it easy to see all the values at once, rather than having to click on every variable to see the “Target length” as in the current implementation:
In order to follow the UI principle of data locality, the data (10.000 in this case) should be as close as possible to the variable (“Height”).
Basic operations such as
/ could be supported, along with
() to specify order of operations. Basic strings could be parsed as one-line expressions. This brings the feature of “Parametric” into “Constraints.” Future additions could do fancy math like
TODO: Consider a global formula editor that would specify variables (and equations) that can be referenced by all Sketches within a document.
Dimension Offsets. We need a way to specify that an object should be a certain horizontal or vertical distance from another. For example, how can I specify that two vertical lines should be 10 units apart? Maybe this can be done with an “Anchor” in the current implementation, but it wasn’t obvious to me how to do this. Another example is specifying that the center of a circle should be a certain distance from a line.
Guides. There are many times when a line needs to be added that is necessary to provide constraints (such as a centerline), but that should not be part of the rendered geometry. Perhaps adding another node in the tree:
Show/Hide Guides. Any geometry type can serve as a guide, not just lines. This is where the current implementation of defaulting to the Center Linetype is very confusing. Sure, we need a way to tell what is a Sketch and what is regular Rhino geometry, but within a Sketch, we need to tell the difference between construction geometry and Sketch geometry. Typically, only construction geometry is dashed or looks like a centerline. It might be possible to add light bulb icons and/or commands to control the visibility and/or style; this would work similar to how Layers are displayed in a tree/grid view where each layer has several options that can be edited.
Patterns/Arrays. Getting into more advanced parametric design, the use case above defines a rectangular pattern similar to
ArrayLinear that is parametrically driven:
- Direction1 = +X
- Direction2 = -Y
- Direction1_Spacing = WIDTH - HOLE_OFFSET * 2
- Direction2_Spacing = HEIGHT - HOLE_OFFSET * 2
HOLE_OFFSET is defined as 1 on the above sketch. Similar possibilities exist for enabling other types of arrays similar to
ArrayPolar to be parametrically driven.
Mirror. Being able to mirror the left half of something and copy it to the right of a Guide (construction line) is a key aspect of parametric design.
I realize all of this could get out of control, and sure we can do similar things already within Grasshopper, but I wonder if even basic Constraints functionality as I’ve outlined above would be useful for the Blocks feature also (i.e. Parametric Blocks)?
Thank you so much for working on this feature–I’m sure whatever the end result is, that it will be great!
perfect suggestions! I add variables could be local and global, per sketch and per drawing…
horizontal constraint.3dm (212.8 KB)
Somehow horizontal gets broken
This is a promising feature. As non-Rhino user, but professional CAD modeler, are there any plans to introduce the concept of assemblies into Rhino with constraints features like you’d find in Fusion or Inventor? The sketch constraints are great, but what would really make me consider “jumping the fence”, is if I could retrieve that sort of component hierarchy.
Oh, well what do we have here
This is all really fantastic feedback. Thanks for taking the time to write it out.
I think you’re right. I am doing some work on alleviating this confusion, namely by hooking up parameterized constraints to dimensions. Double clicking one of these driving dimensions allows the parameter to be adjusted.
This is still a under construction but in the current WIP when creating a dimension from an object there should be a “Driving” option when placing the dimension. You’ll just need to make sure the object is already part of a sketch. The dimension issue is logged as RH-68115. I really like your UI mockup about separating Constraints versus Dimensions. I’ll add a note to the issue.
I opened this as RH-68451. I certainly see the usefulness in this feature, but we need to figure out how best to fit it in.
I’m a big fan of putting the parameter in the panel instead of having to click and move the mouse all the way down. I opened RH-68452 so it can get some attention.
That needs the offset constraint. It’s logged as RH-68002. I added a note to it about to ensure it also works to offset holes like in your example.
You’re absolutely right. This has been fixed in RH-67962 by instead using a halo around constraint curves.
Hopefully it’s a little easier on the eyes.
I’m thinking this would best be addressed with history on the Mirror command. Could you let me know if that’s a reasonable solution for you?
Thanks for reporting this. I notice the constraints resolve the next time the solver runs. Do you remember how you ended up in this situation?
Is that barely visible white fuzziness what you mean by “halo”, or is it an artifact of low-quality discourse display? If it is what you mean, I would suggest a slightly more aggressive appearance - not much, but more. Or something else even better.
Are the two dots before and after the dimension digits the user’s clue that the dimension is for an adjustable constraint? Not very effective IMHO. Also: how does the user know that it can be double clicked to adjust it?
Is there any reason why you can’t delineate the constraint characteristic by simply displaying the dimension with the edit box already exposed and requiring only a single click (or even no click at all, just a mouseover) to edit the value? It would be much easier to visually pick out the adjustable constraint dimensions from the rest and much more obvious that the value can be edited.
I’m imagining that with a mouseover the edit box background could change color to indicate that typing is acceptable. Whether this would be ergonomically practical is open to question given the possibility of mouse “accidents” while typing: If the mouseover locks the edit status until an enter is received things could get complicated if the user wants to escape without changing anything. If it’s editable only with the mouse over the box then bumping the mouse would interrupt the typing and possibly leave the constraint with nonsense for redisplay. This is just a bit of thinking “out loud” in the hope you’ll come up with something really nice. I know it’s not easy, but you do seem to be giving it the detailed thought it requires.
try to move edit point of the line in vertical dir
What I’m seeing is a cyan highlight on both sides of the curve. The curve thickness is also increased. The combined effect is very pronounced in the WIP as well as in the image here on Discourse. I’m not seeing the white fuzziness.
Absolutely. A mirror operation in a constraint-based sketch environment requires a mirror line which is itself constrained and history would have to remember this line and update if it moved. Do you think it would be necessary to add a new option to the Mirror command such as
Line? Since the Mirror command requires a plane (not just a 2D line from the sketch), perhaps the mirror plane could be implicitly defined to be orthogonal to the CPlane of the current viewport.
The mirror line is construction geometry, which I discussed in my previous post, but it occurs to me now that we can already create construction geometry in Rhino today by placing curves on a separate layer.
I was browsing this thread and saw some alarming posts from some users that was re-inventing the wheel or treading through very familiar tracks… now, I don’t mean to step on anyone’s toes, but is this being designed by people only used to Rhino or is design input being considered from people well versed in different CAD packages? I know it’s a sensitive issue to (publicly) look at what others are doing, especially if those others are huge, well established, deep pocketed and historically litigious corporations, but this is a well established field and the problems here have been pretty much solved for decades.
I’m just curious, because Siemens recently tried to be “revolutionary” with a new sketch solver paradigm for NX which backfired spectacularly because it seems they had a very innovative idea, but never asked their users if it was any good (and so far, it’s very much the opposite).
In opening the sample files I get an error message. Running (8.0.22116.12305, 2022-04-26)
Same error message here with latest Rhino 8 WIP
Yes, you should expect these files to break - the development of this feature is still in the early stages and necessary changes to the plumbing will make older files not work.
Will the sample files be updated for a later/the latest Rhino WIP when necessary so that people can still have a look and try the constraints as implemented in Rhino?
I assume they will work the same or at least very similar to how it works in other software but there might be (small) implementation differences that could generate comments for improvement or change.
@wim I noticed that when copying/duplicating an object with constraints, the copied/duplicated object has no constraints.Will future updates allow for creating a copy of an object to include the same constraints as in the original object?
Hi Art -
Thanks, that feature request is on the list as RH-66905 and I’ve added your request for this.
As for updating the samples, I suppose it’d be more meaningful if users try their own stuff and provide feedback based on that - as you just did.
i totally agree that variables and formulas are essential. a must.
i think @mattytraxx 's input on the UI is great - values next to constraints list.
i love the idea that different types of constraints show in different font/color/bold/… see discussion above