Oh really…?
This is a constrained rectangle, anchors, horizontal, vertical, parallel, and length constraints are applied. Nothing tells me it has constraints before nor after selecting it.
Please tell me I’m wrong.
1 Like
I concur. Constraints (no matter for now how they are exosed) should be able to ‘live’ inside blocks. Brings us one step closer to ‘dynamic’ blocks, like old AutoCAD’s.
(Regardless of the idea to embed Grasshopper scripts in blocks, too. Something Mr. Rutten seems to be willing to investigate)
4 Likes
We’ve had discussions about adding constraints automatically on primitives like rectangles. I’ve opened RH-67960 to get the ball rolling a little faster.
Good idea, logged as RH-67961.
There are plans for different constraints not focused on 2D curves. What types of problems are you looking to solve?
I logged this as RH-67962.
3 Likes
I can’t imagine far enough beyond standard solid modeller capabilities at the moment.
- 2D sketches with constraints and parameters
- 3D assemblies with joints/kinetics/motions
The types of problem I sometimes need to solve are complex hinges. This can be done in 2D. So being able to constrain two or more constraint “sketches” to each other would be handy. Maybe this is already possible, I will test.
1 Like
Do you usually do the hinges in 2D? Or are you just trying to make do with 2D? As far as constraining different sketches together, at least right now, it would only work if you instead made one large sketch. In the future constraining two sketches with a joint may be a possibility. I’d be curious to see an example of the hinges you’re doing, and what kind of roadblocks you run into while testing.
1 Like
Two quick examples I can think of where a 3D constraint system would be vital:
A hinge where the pivot is a ball joint rather than a pin.
A helix. Often this needs to be defined by the ramp angle, e.g. for helical stairs.
Making these sketches into Block-like models within the main model is something that also came to my mind, but much as double-clicking to activate is attractive, I can see it being a PITA to use in some instances. What happens if the ‘sketch’ defines an extrusion and it lays on the end of that extrusion? What could you double-click?
It would also be useful to include the base/anchor point for another constraint ‘sketch’ in a first constraint ‘sketch’.
‘Sketches’ of this type is very much following the herd, hanging on to the coat tails of the parametric solid modellers that have it as a fundamental concept and have been refining the process for years. Bringing that functionality to a software late in the day is a fascinating concept because it’s not naturally ingrained into the process of creating a model. I’m pondering that as I do my daily work in Rhino, wondering how it could be integrated in a way that doesn’t stifle the freedom that Rhino has (almost) always allowed. The existing implementation of History does stifle that freedom and is a similar storyline. Although I’ve never used it (but hope to start soon) Grasshopper or a Grasshopper-like interface keeps on coming into my thoughts.
4 Likes
Designing and modelling compound rate coil springs, where the helix angle and coil diameter (and possibly the wire diameter too) need to change along the length of a spring, are difficult things to design and 3D model. They’d make a good design exercise to test any 3D-constrained sketch. The added nuance of quite possibly wanting to animate (or at least realistically deform to simulate compression/extension) is a further embellishment.
1 Like
Constraints are really great, but I agree that it’s of no use if the constraints can’t be seen in the viewport.
There should be some kind of direct constraint workflow. By this, I mean, if there is a tool like the current History toggle called Auto-constraint, where it can at least starting taking care of the basics of two lines that touch each other - coincident, perpendicular, tangent, etc. From then on, if selecting two lines, there should be a 1-click way to assign a constraining relationship to the two - parallel perpendicular, x or y distance between the two, equidistant, etc.
Although I haven’t worked with the Solidworks, Fusion 360, or Inventor, I really like the way Freecad handles constraints (I imagine the others work in a similar way). It is one of the better features of the open source program. Fillets, for example work super well there and are natively non-destructive.
https://wiki.freecadweb.org/Sketcher_Workbench
1 Like
I do like the indicators of the constraints that show up near the object constrained.
2 Likes
I updated RH-67791 for this to be shown even when not selected. I hope to get to it soon.
In the latest WIP if you select some lines/arcs and hold down control and click the middle mouse button a small menu will pop up showing you the constraints that can potentially be created from the selection. Clicking one of those options creates the constraint.
It’s still a little rough around the edges with changes in the works (moving to different key bindings for example) so don’t get too used to its current state yet. The issue is logged as RH-68034 if you wanna follow this features its development more closely. Is this what you’re after?
2 Likes
Hi @Joshua_Kennedy, this new feature doesn’t seem to work on macOS, is there any preference to change or is it just not implemented ye t?
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 +, -, *, and / 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 sin() or tan().
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!
15 Likes
perfect suggestions! I add variables could be local and global, per sketch and per drawing…
1 Like
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.
Thanks!
2 Likes
Oh, well what do we have here 
1 Like
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?
9 Likes