Rhino WIP Feature: Constraints

Just to clarify - @Ryan656 are you talking about actually conflicting constraints, or redundant ones?

Neither should crash it, but trying to add actively conflicting constraints (such as making a line of fixed length both horizontal and vertical) should currently be detected and prevented, with a message on the command line.

As for adding non-conflicting but redundant constraints (such as making line A vertical, line B horizontal, then also making A and B perpendicular), it currently does not prevent this - we know this is an issue and are working on it.

1 Like

At a risk of asking something completely off topic, there is no way to apply these constraints to objects other than curves (e.g. boxes, polySrfs, blocks etc.)?


Hi Daniel, that’s right, before I updated rhino it was crashing when adding conflicting constraints, after I installed the update it allows it which is technically incorrect, but now it doesn’t crash which is of course better and the main reason I brought it up. You seem to be aware of the issue so hopefully it will get fixed at some point :+1:

1 Like

Are there any updates coming up (e.g.the constraints toolbar) in the next few weeks? I’m contemplating whether or not I’ll give this a new try.

1 Like

Hoi -

No. This project is on hold until we start working on Rhino 9 WIPs.

1 Like

That’s very disappointing to hear, it was the main thing I was looking forward to for V8…
It is also by far the most clicked link in the WIP features thread, so I must not be the only one to think so.

E: @wim the feature should then be removed from this list, I would assume:


I am very exitced to see constraints in Rhino and the ability to use them within Grasshopper hopefully

1 Like

Looks like this project it is postponed for Rhino9.

They need to solve a lot of problems to make the Constraints really working, like the incorporation of spreadsheets support in Rhino to be able to drive the Constraints using mathematical formulas a la SolidWorks or FreeCAD.

P.S. Spreadsheets are also useful for the creation of BOMs in Rhino. I cannot wait for this feature to be incorporated in Rhino.

McNeel should have a look at the defunct “RhinoWorks” plugin.


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.