When I look at all the threads on this topic, there has been a lot of very good feedback.
So much development has already gone into Sketch Constraints. In addition, McNeel already has Bongo and Blocks already exist. Instead of developing all of this further and completing it,
everything is being put on hold ???
Hi Wim,
here is a very specific and detailed example of what i would like to see. I would very much like to have the sketch constraints functionality that Joshua Kennedy demonstrated in 2022 in Rhino:
https://m.youtube.com/watch?v=qx97fkC-E3o
Preferably with the easiest and most intuitive usability possible.
As an addition to the existing design / drawing capabilities in Rhino, we need driving dimensions, angles, and constraints. I am attaching a video showing how the interaction currently looks in Rhino Wip in 2026:
You can use the Gumball or move, scale, rotate to change lines, curves, surfaces etc. afterwards. This approach works well for many things in Rhino. However, for sketches, especially for mechanical, mostly prismatic geometry, solid bodies, it is rather a cumbersome workaround with disadvantages. For example, when you adjust angles, other regions of the part are also changed unintentionally. And that is just one of many disadvantages.
It is much easier to understand and interact with when the values are written directly into the dimension.
However, the most pressing problem is that the extrusion distance cannot be changed afterwards in the history. It is extremely important that the extrusion distance can be changed afterwards. Otherwise, this history is almost completely useless.
As long as there is no object manager or history timeline in which objects can be adjusted subsequently, it could also be done through direct manipulation if the value in the history record could be overwritten instead of breaking the history.
15 years ago Did you know something about that plug in or developer?
It’s just sad to be honest, this kind of reply. I for sure have use cases where rhino is quicker. But it is not about that. We are not talking about if rhino is better in some things.
We are talking about features we want that are awesome and are really game changers. That is what you want in a new release.
In version 8 there were some extra tools like push pull (which should have been merged with extrude), auto c-plane and shrink wrap. There are probably more things that got changed, bugs fixed and everything. But not the bugs I had hoped for. I wish xnurbs would be incorporated in rhino and that filleting would be fixed (could also be fixed with history or editable fillets so you can try fillets until they work).
But the thing I hoped for: constraints, was pushed forward again. I hate fusion on so many levels, but love the real parametric modelling it offers. Because I can model exact things very quickly in it. There are so many times that I wish I could just model the part of a project that needs to change later on with fusion and model the rest of the thing in rhino. There are worlflows to do this, but not in a nice way. I would gladly pay mcneel the money I fork to autodesk each year if they fix this.
I have people working in my company, we have rhino licenses and fusion ones. I am currently the only one that uses the rhino license and I use it only 3 times a month and the only reason is that using fusion makes my life easier than when I use rhino and the only reason fusion makes my life easier most of the time is because it allows me to use constraints. Sometimes this breaks and it is annoying but most of the times small edits can be done in a matter of seconds that would take me minutes to hours in rhino. Not exaggerating.
I want to use rhino because the command typing, the freedom it gives me in the interface, the free modelling, the surface modelling etc. But I just keep using it less and less and I think I am not the only one (in the product design scene).
Try using the new Patch command in Rhino WIP; it has already replaced XNurbs. As an XNurbs user, I’ve made several comparisons, and it’s already a valid substitute.
Here is an example of a project where I’m using it. (patch vs xnurbs)
For what concerns the various modifications, it’s only partly true that parametric modeling takes less time — or rather, it’s true only in certain situations. To simplify, mainly when dealing with “standard” geometries like boxes or simple surfaces. I can assure you that when you work with complex surfaces, parametric modeling is not that useful.
I generally work with complex geometries, often including patterns and textures. Everyone I see working with parametric tools eventually gets frustrated, because the software is not as “intelligent” as it’s advertised.
For example, in my case I work in the footwear industry. I see colleagues and companies who, when dealing with simple heels, wedges, or basic soles, use parametric tools and say: “Yes, but I can do this in 5 or 15 minutes, while you might take half an hour.” That’s true — as long as you stay within simple geometries. But once you move to complex shapes, the situation changes completely, and I become much faster.
It also depends on how you set up your workflow. I always structure my work so that any modification can be done quickly, because I expect client revisions.
Take for example a wedge created in size n° 37. When I need to develop it across sizes 34 to 42, the geometry underneath never truly matches, because soles are handmade and not as precise as people claim. So I need to adjust the contact areas, and the parting planes change as well. However, I must keep the same base: everything scales except the base, and also the upper area where the heel or wedge sits (the “crown”). The side-view inclination must maintain the same angle, but in X and Y it must scale. In the lower part of the heel, certain areas must remain unchanged, while others must adapt depending on the size development.
In short, even if it’s hard to fully explain without showing it in practice, footwear grading involves constrained and unconstrained zones. Trying to manage this in a parametric system often results in a feature tree that no longer behaves as expected. In Rhinoceros, this problem does not occur.
That said, I would still welcome parametric tools in Rhino — I’m not against it. I come from SolidWorks and I use Cimatron for mold design, so I understand the logic behind parametric workflows. But Rhino allows you to work effectively in situations where more “renowned” and supposedly “intelligent” software often fails — or rather, where it promises efficiency that in reality is mostly marketing. From what I see, these claims are often exaggerated, especially when presented to clients.
Even if I can’t show much, here are some examples: with parametric modeling, it’s not that you couldn’t do it — but what I can complete in one day, including all variations and adjustments, would take significantly longer in a parametric environment, especially when dealing with complex surfaces, patterns, or textures.
Among other things, I also used the new Patch command in Rhino WIP on this personal project that I work on as an exercise in my free time.
I hearted your reply. Because it is impressive. But I still don’t agree. Your example is one that is quite specific to this application. The patch update is very welcome. But I was talking about rhino8 not 9. I am curious what systems you use to make quick client modifications.
However, I have various of the products we built almost completely parametric with domain ranges big enough to adjust most things. I cannot show them because of secrecy clauses, but being able to adjust the electronics compartment of my machine by changing 2 values and seeing my model update screw holes, lofts, snap fits for the lid, and even outer surfaces is magic. I used to have breaking models but that is not my gripe with fusion anymore. Randomly flipping sketchplanes, problems with persistent errors and some non-derministic behavior, the interface, that copy-paste is not working as it should and the company behind it are the main reasons I have hatred for fusion, but the iteration workload later in the project goes down a lot, since we started using it. The only part in fusion that creates this is their history based constraint system. I say “only” and I understand it is a large amount of work, but I think it would be the best new feature rhino should do.
They should also fix '"low Hanging fruit” like the fillet tool. It turns new users off. Fillet is used extensively in all the solid modellers. I think they can solve it if they create an abstraction for solids above the current system. This would also help solve the unreliability of the boolean operations.
The fillet tool is still a problem, and it remains one. However, in the last link I showed you—about the commands currently in development for the new Rhino—they are making improvements. Click there and check all the commands that are in development.
If you have a Rhino 8 license, you can download Rhino 9 and start testing it. For example, the Patch command is no longer the same as in Rhino 8 (see the first link I gave you). Take a look at that specific discussion.
As for my method, it’s difficult to explain it here. I don’t think you live in Italy or anywhere near me, otherwise I would have gladly shown you how I approach my work in general.
And don’t ask me for video tutorials—I’m not equipped for that, and I don’t have the time to record and edit them. I only upload a few very amateur videos on YouTube, nothing more.
Unfortunately, what you’ll see in Rhino 9 won’t be available in Rhino 8. So in many situations, XNurbs is probably your best option. Yes, it can also be done with native Rhino commands, but it requires more care and time—which I assume you don’t have due to deadlines.
Take a look here: this feature was in development, and I was honestly waiting for it in Rhino 9, but it ended up being put on hold—still, it was already something.
Folks, this is The reason not to stress about sketches driving your geometry! It’s constraining! You think you have more control, but you have less. Every time a colleague passes me a file built with that sketch-based constraint software that uses the tree hierarchy - you know the one - something was either over-constrained or under-constrained and the ‘powerful’ software pulled something out of tolerance. That ‘control’ is an illusion!
Rhino is a free-form modeller. Heavy emphasis on the FREE form - unconstrained modeling. I can do what I want with the geometry. Incidentally, Rhino has been my go-to tool for two decades, paying my bills and making my living. Never once have I thought to myself: “Dude, you need more complexity and rules in your design workflow!” Some folks Need opressive structure in their lives. we freeform modellers dont.
Thank You Bob! For pulling the plug on this constraints development. If it ever makes it into Rhino 10, or 11, or 15, please make sure we can turn it off !
…the NURBS surface modelling bugs many good users have reported over the years, and add missing functions. In my opinion, the problem is the “Swiss Army knife” approach, trying to cater to too many often very different industry sectors (compare industrial design, jewellery design and landscaping design, for example) at once.
It’s surprising that AI hasn’t been mentioned in this thread.
Given the success of auto-coding, it seems inevitable that soon much of CAD will be driven from a prompt (e.g. “make this heel for size 37, preserving wall thickness and continuity”) and refined iteratively.
Once variations can be driven from an AI prompt, there will be less need to maintain a tree of parametric constraints, because relevant constraints can be specified in the AI prompt.
Maybe the Rhino 10 focus should be on making it easily driven by AI?
I’m not really sure what your point about parametric modelling is, other than that for your specific use case - you don’t need it? Some people use it, some people don’t. Most of my work I would never model in Rhino just because changes would take far too long.
In short, parametric modeling is a CAD method in which a model’s geometry is controlled by editable parameters and constraints, which automatically update the shape when values change. The model is built through a history of operations, and every element (dimensions, fillets, angles, distances) can be modified via parameters—something I use when creating molds in Cimatron.
That said, parametric modeling works well with simple geometries, or to put it bluntly, with shapes that are close to parallelepipeds; when surfaces become complex and go beyond standard cases, parametric systems tend to break down.
I moved from SolidWorks to Rhino for the reasons explained above. The only thing I truly miss is the ability to edit fillets and chamfers directly from the feature tree; for everything else, I don’t miss it at all. However, I would like Rhino to have a parametric sketching capability similar to what I mentioned in the link above, where I discussed the possibility of constraining drawings in Rhino—an idea that was later halted during development.
It is very clear there is a continuum of value here - does this capture it?
The point of parametric sketch constraints is not that anyone would be forced to use them, nor that they are applicable to every problem (and i agree that beyond a certain complexity they would be positive hinderance).
The point is that for a huge number of users doing simple modelling that would provide great value - by making design changes very very easy through parametrics with constraints.
My worry is that everyone in this thread are experts and working on problems well to the right of the graph - the users who would benefit the most from Parametric Sketch Constraints are not in the room - they are making productive use of other software - such as @ArtProgTech 's colleagues or @Tom_P 's students or the several dozen companies I support with CNC software.
Thank you for sharing your experiences @ArtProgTech I fully agree and see the same thing in many of the companies we support, we do all their CNC preparation, Nesting and CAM work in Rhino but the actual design work is stuck in Solid works because it is quicker for the customer to make simple parametric / constraint changes to simple 2d drawings than it would be in Rhino. Think changing the radius of a set of corner fillets.
@brvdln your modelling is amazing and very intricate, i think you are well to the right of the graph 
I think the ideal solution would be as @altamiro.aj has said to allow Grasshopper to move to the left of the graph above - have something which automatically builds a grasshopper graph as you model or sketch.
Yes - I know what parametric modelling is. All I’m saying is that the debate is pointless. I use parametric modelling for 90% of my work - you don’t.
If the PCB changes size, or I need to change wall thickness to a part like this - it’s rather trivial with a parametric model. And that’s exactly why it’s built like this - because 3d printing FDM vs. resin vs injection molding ABS vs nylon allows me to make drastic changes like wall thickness and pcb component changes, draft angle etc. very quickly.
I strongly disagree. “Value” entirely depends on the industry sector and concrete requirements. This is why there are so many different 3D programs around, and why many companies use more than a single software.
In my case, I also handle hollowing, wall thicknesses, and everything related to the internal structure parametrically in Cimatron, once the model has been approved.
@david.birch.uk Your chart is excellent, it perfectly summarizes the entire topic.
A bunch of the solutions that were discussed here are showed in this video about the 1.1 update for freecad.
Wow, that looks promising. Until now, I found the interaction in FreeCAD clunky, but it seems to be improving.
@ McNeel: Maybe a FreeCAD-inside-Rhino integration would be possible?
Ideally with the familiar Rhino interaction.
Or perhaps the ability to load FreeCAD models into Rhino as linked blocks, for example, which would update automatically when changes are made?
I dont understand why you need to be so against a feature that you don’t need to use. But has been asked for and would greatly push adoption if implemented half-decently.
If I would make constraints in rhino, I would:
Overhaul the dimensioning tools (they suck a bit now) and integrate the UI with dimensioning tools. Create a panel that works just like a spreadsheet, with sorting and other things integrated. Everytime you make a dimension it connects to two things. You can toggle if a dimension is driven. Then it moves these things. Every dimension goes into the spreadsheet and is easily called or updated from grasshopper (you can use a simple spreadsheet code or reference by clicking on the correct dimension in the dimension sheet panel). This way you can control dimensions from grasshopper (or the other way around!) if you want. This would allow easy architectural changes. Very nice for adjusting floorplans.
I think rhino should not try to make a history based constraints system. This is not the rhino way I think. It should make a spacial based constraints system. So when there is an extrusion for example, there is a curve that is being referenced. Just like in grasshopper, but you dont need to put it all in a large timeline.
You could just make it like a linked list. So for example if you draw a circle. This circle is done on a c-plane. This c-plane is created as an object the moment you draw this circle (lets call it an s-plane for sketch-plane). You cannot select it or move it (without the proper tools). Moving the reference s-plane will move the circle. Okay now let’s extrude the circle. It just refers to the circle. Want to extrude something else? Reference it to a different curve. How do you “select” the extrusion well that is done in de constraints view where the extrusion is for example red (like in grasshopper when selected) and the referenced curve is blue. In the constraints view you cannot select object you select actions. Because the actions alway create geometry, it can be visualised as a vector, you can manipulate these like you manipulate other things in rhino, changing things without auto updating the reference list will just leave things as they are.
You can revamp the Osnaps to use them as constraints. You already have most things that are needed: midpoint, centre, parallel, perpendicular, etc. The only thing you do is when going to the constraints view, your osnaps become constraints automatically (added to the list) and made visible in the constraints view.
Now for the use cases:
Architectural: adjust the amount of windows in a face. Or keep the windows the same while changing the face. Make grasshopper a bit more user friendly by being able to draw some component by hand (that are easily adjustable later with dimensioning).
Product design: make integrations with more complex parts easier, changing a motor, or a pcb becomes a matter of seconds instead of remodelling the whole part. Make 3d print iterations easier. Remodeling a snap fit without constraints based modelling is horrible. Redoing chamfers and fillets should be easy. With this system just make a fillet on an edge, go into the constraints view and change the radius there. Then update the changes (set to auto or manual).
I would prefer available resources deployed to fixing the many bugs and missing functions before trying to enter yet another market segment. If I need solid modelling, I rather use a dedicated solid modelling software with a fully-fledged toolset.
