Rhino WIP Feature: Constraints

Another good example: Rhino Paramerics

1 Like

Really sad and hard read that constrains is postponed till Rhino 9.

The same happened to Flair, am i wrong? Also postponed to Rhino 9

1 Like

So sad!

I’m a teacher of design, and also I make a lot of technical drawing for big show with a lot of furniture to draw. Always, the customer or students changes things like thickness of matérials, size etc… And I always spend so much energy, concentration lost for redrawing everything. And this make my pratice of the software to the point of no longer enjoying.

I was hoping constraint can save me a lot of time, make less errors, make my life better.
For me, it was the most big game changer with the SubD tools.

Thanks for the improvements though.I understand this is not easy to devellop a such complex program.


Hi all,

Thank Goodness for this delay! Having Constraints at some point the future would be great. A very useful and welcome addition of new tools.

More importantly, it’s frustrating to see some many existing features in Rhino done kind of poorly, with a limited toolset, and immature workflows.

I rather see the existing tools get a lot better than seeing any development resources put into completely new functionality, while leaving not-good-enough existing functionality alone.

Here are my top 15 examples that come to mind, before development happens in new features:

  1. SubD’s need a lot of rethinking and a lot more/better tools
  2. SubD conversion to Nurbs need massive improvements in patch logic
  3. We still need a new/better mesher for Rhino that can make high quality meshes more efficiently, and faster, at taking more advantage of multi-core processing, even GPU processing. We have an ancient mesher that produces tons of bad meshes, ignores its own geometry rules and takes forever to run.
  4. Layout and text tools are… something else, we don’t even have proper multi-page layouts
  5. fillets and shelling continue to be subpar in very repeatable cases
  6. Solid editing still destroy geometry in 2-degree surfaces, and cannot do any proper design-intended extension on 1-degree surfaces
  7. Brep booleans have seen a great improvement but need a lot more of it
  8. Mesh booleans, even the newer stuff still doesn’t work in hard cases of coplanarity last time I checked
  9. Quad remeshes continues to tear out models, and create weird spirals in pipe-like geometry
  10. Need need better import<>export to pro MCAD tools (Solidworks, Creo, NX)
  11. Blocks need to be a lot more flexible, and a lot more useful
  12. We need better import<>export & Live-linking to pro CG tools (Blender, Unreal, Unity)
  13. Bongo is still a dead end-street, in need import<>export of animations via FBX/Collada/etc
  14. We need massive performance viewport improvement in PBRs, they melt the Rhino viewport, even on an RTX 3090.
  15. The V8 wip workspace re-work is frightening. Great to see see native SVG support, scary to see everything else so far that seems mostly regressions from V7.

I can keep going, but I think this is a list that benefits most users, in most industries, and it can easily use McNeel’s 4X their current development capacity, and 10X their current UX capacity.

The Contraints that Rhino needs the most in my opinion is having the constrain of not putting any effort in new tools before improving everything we already have.

So yeah: Constrains are dead. Long live Constraints!



PS: and for those who do not know me…

I’m saying all this because Rhino is the tool we use the most. It’s the one that is worth giving a damn about for us. It’s the one that allowed me to grow in a pretty exciting career, kick some ass in the corporate innovation world, and now in the last few years build a really amazing world-class design team working on all kinds of great projects. Many families thrive out of the work that in our company alone gets done thanks to Rhino.

So Rhino, McNeel family:

Now let’s keep the constrains on.


Let’s hope the constraints features can be as ground breaking as we want them to be and as intuitive as possible. Although there was a lot to be desired, it had/ has a lot of potential still. But it definitely needs a click reduction and typing reduction overhaul. As disappointing as the announcement was, hopefully it is for the better in the long term.

1 Like

Talk about:

Quadremesh can’t even recognize edge corners or creases and put mesh vertices and edges where they define these original NURBS features. Singularities cause a completely unusable mess.

As a result the command only realizes Dr. Lear’s original vision of “round tripping” from NURBS → SubD → NURBS in a very limited number of simple special cases.

So that’s what I think of when somebody mentions “half-baked, unfinished commands/features” and there’s been no mention of finishing it for Version 8 - just as if everyone at McNeel thinks it’s done and extremely usable when really it’s just a swell sounding bullet point for listing in sales information.


i could go on citing really elementary stuff…

1 Like

I don’t see a point in implementing assemblies. In Rhino you can assemble anything any time you want. The named views are pretty cool, and think there was a plug in to smooth the movements, if it’s still necessary.

I’ve seen the Freecad constraints, and I will state, they are a real pain to use. Using their implementation made me yearn to be back making stuff in Rhino.

[I’ve used FreeCad for its FEM and for setting up OpenFoam cases, still I wanted to check it out, so I followed a good V8 cylinder-head tutorial. I find it interesting that it’s almost impossible to select the interior surfaces of an object with a mouse and keyboard. Because they have accommodated/implemented other Open Source software, it has improved its usefulness. The dark Batman theme is good. The CFD and FEM are the draw for me; the CNC is interesting, but if I had to draw something, I turn to Rhino.]

As an experiment, I made a single-cylinder head maker in Grasshopper. It made the cylinder and the liner.

Part of the material problems are likely related to the needless disk caching. Even a NVMe is 1,000 times slower than DRAM. Many modern video games can run chock full of 4096 textures.

That 3090 must be nice for cycles.

I’m sure you already are but you need to be hammering us with the failing examples so we can fix them. Feel free to ping me directly and I’ll at least make the issue and get it on the right persons list.

Can you start a thread about this and go over the gaps in your workflow and what’s too slow?

What do you want to do with blocks that you can’t?


Please do. We only know what you tell us.


I have no idea what Rhino is doing. But I know I can take the exact same model with the exact same PBRs an it spins smoothly in Blender. In Rhino after reporting the issue to the they got to to work at 30-45 PFS. Not useful for design work.

When a computer stops to keep up with you in realtime, it creates a lot of frustration, anxiety, and distracts you from what you should be doing: not thinking about the computer, and be focused on design, modeling, creating scenes, etc,

Nothing is good enough for cycles in Rhino, it’s still very slow. We don’t do any rendering work inside Rhino anymore, only OpenGL viewport screenshots, and for most of our work those are great to document daily progress.

For rendering we use Cycles and Octane in Blender, and both run great there. In rhino, the whole flow of work is extremely slow, not just rendering, but creating materials, applying them, changing viewports. Again, it all feels like I went back to a prior decade of computer performance. So we decided we are done with it until that changes, if ever. This is why what I want the most of the McNeel development team right now is a live-link between Rhino and Blender.



I am the same person as Juan_Gallo so:

-better editing in place sketchup like
-editing of non uniformly scaled blocks
-defining block axes not only insertion point, when redefining prompt to ask if instances position should adjust to new axes or recalculate to remain in same position (very important when you decide to change block definition deep in the design process resulting inn instances to change position)
-i think blocks should have both definition user key values as well as instances should have separate key values thus two level hierarchy
-acapulco plugin and blocktools have few very useful simple functions just implement it in rhino (some already are in wip8)
-improve macros so they can handle blocks better (quit block editation)

Elementary stuff, mostly drafting
-rich text editation like in autocad
-scalability of texts
-richer annotation settings like in autocad (dimension line invisible, if there is no space for dimension have leader to value, more units available (such as gradians for angles)
-support .shx special linetypes like in autocad
-detail view to be any shape not only rectangle like in autocad
-improve Fx in texts so that there is some kind of placeholder instead of long code to extract attributes
-have ability to clip/crop regions of linked files/blocks with any shape like in autocad
-new dimension type to be able to easily annotate in 3d space like in sketchup
-new dimension type to dimension curves like in autocad
-new dimension type for elevation ordinates like in allplan

Hardcorer stuff
-true reliable technical vector display mode which is actually usable
-expand clipping planes to include clipping objects of any shape, jagged strings of clipping planes, possibility to create unrolled views and advanced views such as jagged views

-save display modes in file
-audit commands to respect current cplane not only world cplane (cap, …)
-cap all holes like in gh (suboption of cap)
-improve reliability of some most important commands (fillets, booleans, …)
-grasshopper to support referencing subobjects
-general audit of consistency (like you can selby whatever but you cant selbylineweight or printcolor…)
-audit and refinement of some commands to support two sets of selection
-booleans to support any type of geometry
-intersect two sets should support any type of geometry (meshes are not supported)
-support project origin which is arbitrary point far from world origin and operations are calculated in respect to project origin to avoid far from origin problems. global coordinates would just be addition of project origin - world origin
-pushpull like in sketchup, support collapsible breps (when you make hole in a wall and move some face of the hole to the end of brep resulting in zerothickness region should automatically perform boolean difference and delete zero thickness *optionally or have a prompt what should happen)

when this is done i would then move to new territories such as dynamic blocks, flair, constraints, …
what i have mentioned is something very expected from universal versatile CAD package, nothing too specific for any industry. honestly i expected at least “Elementary stuff, mostly drafting” to be a priority for v8.


Hi Joshua,

Thanks for your interest on this. Let me please get you up to speed with feedback already provided.

I used to send a lot of examples, and I’ve seen with a simple search here on those that lack of examples provided by uses here doesn’t seem to be your bottleneck. But please let me know any very specific areas you are thirsty for examples and then, only then, I’ll stop doing billable work and gather those examples for you.

I’m going to ask you the same thing that you guys ask us, your users: Please be specific, provide me descriptions of the types of cases you are interested in, what kind of geometry problem you are trying to solve. Examples of intersections, number of edges, snippets of code, screenshots, etch will be helpful so I can focus only on relevant examples and I do not overcrowd your system with repetitive examples of failures that we have all been sharing here ad nauseam.

Are you sure you need more threads on this? Why don’t we start reviewing the top search results from my posts alone on SubD friction and limitations? I think most of this is still unaddressed AFAIK.
From August 1019:

April 2020:

Also April 2020:

From February 2021:

From February 2022:

from December 2022:

In summary… lack of feedback probably ain’t the problem. Don’t you agree?




I didn’t say it was. I just saw your top 15 were kind of broad so I was hoping to hone in on your problems.

Well I was trying not to get too off topic here but it’s fine. Thank you for linking the posts. It seems like a lot (most [all]) of the problem for you is selection. I get it. The CTRL+Shift approach for subobjects is time consuming and awkward. I don’t have any good answers about marquee/paint select outside the commands which you’ve already been pointed to quite a few times. The one reason I can think is making those default for selection breaks muscle memory users have built with dragging objects but I know that doesn’t help you.

As for this one:

Hopefully I’m not spilling the beans on anything but there are two advanced options being tested right now that might help.


With both those options set to True the object you’re about to select will highlight and if CTRL+Shift is held down the subobject you’re about to select will highlight. One quirk I noticed is it quickly becomes painfully obvious how bad selection can be (even in a simple example a SubD edge behind a face will highlight even though it’s not visible). It also looks like the SubDs aren’t highlighting correctly. I’ll log that.


It’s in the WIP so you can check it out and let us know what you think.

Also, I know it’s time consuming to type this up so thank you for doing so.


Possible here:

This thread got a little contaminated already, so allow me to upvote some just here:

Oh yes!!! +1




Partially possible already with a SplitFace and ExtrudeFace worklfow. Use this option:
What I would like to see here is SplitFace supporting drawing zigzag lines on a face, not just a straight line from one edge to the other.
Edit: Such a tool should maybe called differently, “Knife” maybe, seems to be unoccupied. Numerous polymodelling 3d apps have it. One for nurbs would be great!
Edit2: Just read Joshua’s post. Well, could work. I’m just not happy yet with the way autocplane works.

1 Like

How about a persistent lasso/ paint selection? In other software, like Blender or Illustrator, you switch to a different selection tool if the rectangular selection region is not appropriate for the task at hand. In Rhino, you need to fire-up the lasso command for each and every selection action.


I am into the same situation. I do furniture design and all advertisement jobs into the furniture design industry are asking for SolidWorks skilled designers because in SolidWorks you can quickly adjust the thickness or sizes of different materials that are used in the furniture fabrication. Well, in Rhino I wish you luck if you will try to do the same. Possible, yes, easy to do so, NO way.

McNeel should consider to develop some tools targeting the furniture design and fabrication industry because it is a sector that it grows every year, Furniture Market to Hit USD 720.2 Billion by 2028

The Fusion360 guys realized this trend a few years ago and they are actively developing tools for Fusion360 targeting exactly this sector of the industry.