Some people on those forums were discussing about constraints in general, like assembly constraints with mechanical conections that are something we would get with bongo or kangaroo in GH. It was not clear of what they really wanted to achieve.
Essentially, people that use the other cad softwares kinda know what they want, but we have to remember that developers are programmers, not projetists, I wouldn’t even bet that they use rhino beyond what they are implementing or have implemented.
I will see if I can make something like that to help on this regard, however, to try to give some light into the subject right now, I would resume as the following:
Dimension driven sketchs. That means that I could draw losely the shape I want with the the lines and curves tools and afterwards, insert a dimension and that dimention drive the curve length, radius, etc.
Tip: On the first dimension inserted, scale all the curves accordenly to the dimetion inserted.
Geometric constraints to easily solve issues on the drawing. That means, I can place a line perpendicular to another and tie their ends together, so the lenght of one defines the start position of another and so on, that is more usually usefull when working with tangents and stuff. Or if I want to make a curve longer and want everything after that to move together when I make it longer.
Forced history and update of curves/dimensions. That means, lets say I made a floorplan, or general arrangement of a boat, and I want to make the second floor/deck above it. I can make the second sketch and constrain it to the first one, if I change the first one, the second will update accordenly.
Overdefinition troubleshooter. If I have two lines set to equal lenght, and try to define the dimension on both, the second one should have something to show that its dimension is driven, not the driver, or, it should give a warning that I cannot change that line lenght because it has a equal lenght constraint on another line. So I can delete/suppress that constraint to be able to keep working.
Extrusions/sweeps/cuts/etc should have history forced on when a constrain driven sketch is used for it. It would be confusing for how the users are used to work with constraints if the surface/solid/mesh making commands would not update if they changed some dimention on the original sketch. So we would need history to be locked on, and we would need to have a new toolbar with only commands that work without breaking history.
Sketches usually are 2d only on a specific plane and are constraint to that, so a dynamic cplane could be created on model faces to draw on it with planar/project to cplane activated. Advanced users could use 3d sketches but that usually is not the case, since the constraint model approach is to make it easier to do mechanical parts and those usually don’t require 3d sketches and usually if you reach that point you ask for help to the hidden Rhino user on the backroom with no lights on.
Parameters, being able to create parameters and define values and use those parameters on sketches and update the values to update the whole model is awesome. So having a “thickness” parameter and being able to update that and the whole model to become thicker or thinner is an amazing tool to have. However, for that to work, lets say, with the command Shell, the Shell command would need to appear on a model tree where it would store the selected face and dimension used so the user could update that if needed. At this point we already moved away from constraint sketches and are working with the 3d model and commands itself.
The thing is, I truly believe that Rhino is already capable of all these via grashopper, however, grashopper is entimidating for new users, heck, I even have some fears to look on some spaghetis that I made myself.
However, I think that this is not something that should be coded from zero as a completelly new functionality as I think that would be a waste of resources and just introduce more commands to do the same thing, what I think should be done instead is to make some kind of panel and clever commands running grashopper in the background, with a “linear feature tree” as the users are more accoustumated to use, with the option to have this open in “regular grasshopper” to look at the spagheti.
This way, not only you create what the users want, but in a matter that might even make it easier for them to move from linear parametric modeling, like those other softwares do, into truly parametric modelling with GH. A way that I would consider more Rhino-like.
Seems to me what you guys are talking about, Altamiro & Ftxuk, Quan Li, is another kind of software - basically for production. Have you tried FreeCad? it is open source, free download, very powerful, uses a “sketcher” set of tools to do what you’re talking about - constraints & nearly unlimited, but it is not as intuitive as Rhino - Rhino is for designers and is not “constrained” in my view. In FreeCad, Solidworks, even Revit, the ability to change ideas, concepts, and model is always locked by the history stack and the constraints. Constraints have to be done in an order and if you want to change the driver, well, it’s pretty much start over, whereas with Rhino, it’s a conceptual modeler where you hash through ideas and make it work. Grasshopper is there and can do all of what the “constrained” software can do (& more) but it also is “un-restrained” if you will, allowing users to be much more creative than the, what I call, the production software like I referenced above so I like Rhino/GH like it is, the others feel like your hands are tied while working in them . . . my 2cents . . . Cheers!
linking to an earlier comment i made on this so as to not repeat myself:
i cant think of what sort of cad work wouldnt benefit from constraints (as in, reference measurements and the relationships between them.) dont all our 3d models start with reference curves?
imo it is as intuitively useful as like, oven mitts
I see this idea every now & then & I disagree completely. Just because GH is parametric, doesn’t mean it’s the same as a parametric modeller. It’s like saying a tennis ball is the same as a basketball because they’re both balls.
1.) Sketching. This isn’t possible in GH. I mean yes, you can tediously create start points and vectors and lengths and eventually end up with this shape, but this will take so long that to consider it a viable alternative to a sketching environment in a parametric modeller makes no sense.
Grasshopper is great for certain things, but to say that GH “is there and can do all of what the “constrained” software can do” is, in my view - entirely untrue.
You’re absolutely right. In Rhinoceros I can do what a parametric program does, but with fewer steps than a parametric CAD. In parametric software, when a specific modification is needed on complex geometry, the entire history can fail from the start. In my company there are two designers who use parametric software only for molds and simple surfaces, but when it comes to complex geometries (textures, patterns, meshes with surfaces and edits), I work faster.
I work in footwear, and when I develop a heel, sole, wedge, or platform, I have to produce sizes from 35 to 42. But not everything scales the same way: some parts must stay fixed, like the base of a heel, or certain areas must change every two sizes. Doing this with parametric software is very tedious for complex geometry. Parametric tools work for simple heels, but not for complicated ones. Do you know who’s faster? Me with Rhinoceros, because I’m not constrained by anything.
Hi @brvdln
Nice work I can see why constraints would be a problem in what you are doing.
But constraints are not only for sketching or designing they are for attaching other features to a model and having those features update when things on the base model are changed. In your models you have no other features attached so they really don’t benefit from constraints.
Holes and pockets are features that benefit from constraints because in Rhino they become cumbersome to redo constantly and are based off of the main model. In a mold where the back of the model has pockets and they are always a standard size, draft and placement and may only get added or removed depending on how long the part is.
Window placement and door placement in architecture are also models that benefit from constraints. Rhinos lack of history with constraints makes doing updates in this type of work very tedious and time consuming.
In addition to constraints Rhino needs to update it’s history like split and many other commands need to be history enabled and we also need to have less break history warnings, I’m sad to see that nothing is being done for V9 in this area.
Also I want to point out that when Rhino does get constraints just like Grasshopper and any modeling tool in Rhino those who don’t need constraints don’t have to use it. For who has need of the meaningless? We only use what we need or has meaning for us. I do see how it will benefit my needs but I am also glad that we can use Rhino as you point out so wonderfully without the limits of constraints. I think it’s exciting and meaningful that we could possibly have both.
Yup. Also because most products go through protoyping (3d printing, cnc etc.) I often want to make bosses thicker, change wall thickness slightly to suit the prototyping process. With a parametric model it’s mostly trivial to make such changes with a few clicks - I don’t need to rebuild surfaces or do any work - the whole point of parametric is time investment at the start allows relatively quick changes later on. As a business we wouldn’t survive if such regular changes had to be manually built each time like in Rhino.
Every industry is different. Some people don’t need parametric, some do. And I don’t mind that Rhino isn’t fully parametric, but having at least a parametric sketching system would be super useful.
Well, yes, but that was at home, and I even used it for some freelancing work and all.
However, at work, the IT department is the one that tells me what I can and what I cannot have. Opensource software is pretty much completely out of the question for safety reasons. We have Autodesk products, Siemens products and Aveva products to work with, and 3~5 Rhino licenses for those users that really solve the problems .
Precising that I agree with the request of a sketching system using constraints, it seems to me that the idea of starting the development of a plugin is the best one.
We all know Grasshopper is fantastic for advanced parametric design. What we are missing here is the simpler sketch-based parametrics / constraints which are driven from interaction with geometry in Rhino - rather than by nodes and wires in Grasshopper. But why do something in competition with Grasshopper - why not augment it and make it easier to use and open to more people?
It would be amazing if we could enter a mode in Rhino where every command and point/length selection we do is automatically added into a Grasshopper model which is made for you – and where to change a point or length we simply had to move/change it in Rhino – rather than find the right node in Grasshopper spaghetti then change it. Add something like the Constraints panel from @Joshua_KennedyRhino WIP Constraints Sketch - YouTube and I think we could have something amazing.
Would it work universally? – no, would it cover the basics yes, and if you go beyond the limits you’d have a ready made Grasshopper model to start from. Would you build a whole model using it? Not likely, would you use it for several time for smaller design elements? potentially.
I would love to build this - could it be made as a plugin? Almost certainly not – you’d need deeper integration into Rhino. Could it be done without changing every single command? probably (just hook the Rhino.Input.Custom classes like GetPoint).
Constraints sketching in Rhino would be amazing. As mentioned in this thread, unfortunately it probably will take a long time.
In my opinion, an extremely important first step as it would offer significant advantages even without constraints, would be the extension of CurveBoolean with enabled history. It would enable subsequent modification of parts while maintaining freedom in design.
This request already has a YT, but in my opinion it is too urgent to be left on the heap. It is not an improvement on top. Rather, it is a central feature that is missing in the foundation. Although I suspect that Rhino already has almost all the functionality needed for this.
The Rhino command „Revolve“ is history enabled. Rhino examples usually revolve a curve with many points and spans. In NURBS modeling, however, it is preferable to draw each curve individually and cleanly, building to corners and with overshoot. Fillets/Blends can then be added and adjusted afterwards. This enables significantly better control. Currently, however, this destroys the revolve history in Rhino.
This problem would be solved by revolving the curve boolean instead, if curve boolean would be history enabled.
The CurveBoolean operation eliminates the need for join, explode, trim, etc., so that the history is not constantly disrupted.
I also have been frustrated by the lack of parametric sketch constraints. I also keep finding myself wanting a more contemporary parametric design tree similar to engineering focused CAD applications. But I LOVE rhino, and one of the reasons why I love rhino is the community of brilliant people that help to make it better. Some of the best features of rhino were built by users of it: Grasshopper, kangaroo, everything made by Andrew Heumann, etc.
With that inspiration, I have been slowly working on a plugin to add these features (which includes parametric sketch constraints) into rhino. I’m a month away from finishing my masters, so time has not been on my side recently, however I do plan on flushing it out when I’m finished.
For the sake of organization, I’ll make a new post that covers it in detail. I’ll repost a link here when thats posted.
x 
.
