As I do work in furniture industry, for me this constraints feature will make my work a lot easier. I do need to change the thickness of the materials or the sizes of the units all the time, and right now I do rely on external programs to do this.
2 Likes
IKR. Itās like skipping from horse and buggy to the spacerace without building automobiles.
So many ppl wasted so much time on sketch up 
As we know Rhino is opennurbs and has lots of plugins, eto frame work potential, macros, scripts, Gh etc., So, why say Rhino isnāt [anything]ā¦ What canāt it be in the long run. 
Thereās nothing Rhino canāt do imo 
The stuff I see on the forum any day, blows my mind 
, itās fun when ppl say Rhino not a parametric, cause itās like so parametric, just missing a couple eto frameworks
I think Rhino should take a different approach, relative to itās current ā3D all the timeā aspect per say.
I think it would be powerful for Rhino to approach it in whatever way is as natural as possible to itās own current character of free form.
The whole āsketchā thing and timeline tree, is pretty silly. The weaknesses I remember in those other silly parametric programs is the shackles of the 2D sketches on a plane, and some programs couldnāt even reference entities from one sketch to another.
Some programs would even introduce what they called ā3D sketchesā as appose to there ā2D sketchesā and it was nearly impossible to reference data from one to the other ā it was maddening.
Rhino could approach this very naturally without even calling it one thing or another, cause Rhino is already freeform 3D all the time.
Yeah ok thereā planes and planars and layouts, but the underlying workspace is all the data 3D all the time.
Therefore, I think it would be a waste of time and a huge loss to chase the other silly parametric ideologies the way they do it with silly āsketchesā.
Imo, something like Kangaroo and eto framework technology can be far more superior of an approach to all this, for example.
My comment was about the current status. My understanding is making Rhino āparametricā would require major revisions/rewrites to a large portion of the code. It could happen sometime in the (probably distant) future but that is not the current state and wonāt arrive next month or next year.
1 Like
While true, I guess Iām just seeing Gh get merged in over time, and things Kangaroo can do etc., I see it as inevitable, and some of us users really really would like āconstraintsā right now 
But like I said, I think in due time Rhino could introduce anew type of āconstraintā technology thatās much better than all the other CADās, because Rhino is freeform so therefore I believe it can be done in a correlative and natural way.
The technology I saw Rhino do within the last couple years where āsketchesā were attempted, imo is a mistake.
I think Rhino should find a way to do it without being limited by the āsketchesā ideology, but instead naturally the way Rhino already does it similar to things Iāve seen it do in Kangaroo.
Iām not knowledgeable enough to really know what Iām talking about when I throw around certain nomenclature but if with can take GH and Kangaroo, and make some eto frameworks, I think we could have some really cool āconstraintā technology Seems like eto frameworks is the key, cause Gh and Kangaroo seem to be providing the answers.
It just needs to be more intuitive for the user.
I agree.
McNeel decides in the end, where they see time best spend.
Constraints would bring alot of value to my workflow, saving time iterating and changing dimensions.
That is my humble opinion supporting MR. Kennedys work.
I wont get in an argument into what Rhino is or isnt.
I never said that MCNeel claim Rhino to be parametric to be clear.
I meant to say Rhino in my eyes is not parametric but generative, because it is like a Function Block Diagram (FBD) Language.
You can disagree, because with GH you can design threw changing parameters. I personally make that difference, because Rhino itself is not parametric and thats fine.
Anyways enjoy Rhino. imo
2 Likes