Although, as a user I’d like to interact with the two points, I suppose having them assigned this way allows me to drag them around in the workspace directly, which is probably ideal.
It would be cooler if GH could calculate the equations in realtime during the dragging of the points however.
I think it would be interesting to get a point to be residing along the circle somehow, for experimentation. It might not make sense for certain circumstances but, it would in fact be a good ‘constraint’ to have in the future.
I like how it constrains the point to the circle, position of the curve at the point of tangency and length of curve, and size of the circle. Really cool
I guess what’s missing is center of circle position, and maybe a couple other things. It’s hard to say how to turn these things into universal constraints however.
Grasshopper operates (mainly) as a Directed Acyclic Graph (DAG). This means dependencies flow one-way only, and there are no dependency loops. Updates flow only downstream.
When people talk about geometric constraints they usually mean some system where different elements can be interacted with while maintaining specified geometric relationships between them. This is in direct conflict with the DAG approach, because the interactions between the elements need to be bidirectional.
Say you have a pair of lines you want to keep parallel, but also to be able to drag the points of either one. This is not possible to set up as a one directional dependency.
Some geometric constructions can be set up in a directed parametric way, but this is not the same thing as a constraint solver in the way that term is typically used, and if you want to switch which elements drive and which are driven, it generally requires making a new GH definition.
All this is not to say it’s impossible to include loops, bidirectional relationships or constraints in Grasshopper, but just to point out how these things require something beyond its main way of working.
The one-way dependency is an important part of Grasshopper’s conceptual clarity though, so anything which goes outside of this faces UI challenges in making it clear and easy to use.
Kangaroo tackles this by containing all the cyclic/bidirectional dependency inside one self-updating component on the canvas, with everything upstream and downstream of it keeping to the regular Grasshopper one-way system; the relationship setup as Goals upstream and the processing of results downstream.
This works well for some things, but for some types of geometric constrained systems it becomes very cumbersome compared to conventional constrained sketch setup, where the creation of relationships happens mainly by clicking on the geometry itself.
The Constraints project aims to tackle this within the Rhino interface. There has also been some discussion of new ways of setting these things up within GH2. This is all still WIP stuff though.
The AzAlt(Azimuth Altitude) cluster accepts a plane as input and has a plane output, so can be chained together for a multi-axis system. This model from 2.5 years ago uses one AzAlt for the bottom cylinder, a second AzAlt for the top cylinder and a control to rotate the box at the top end. Cool.
Thank you for the knowledge, this is very interesting.
This gives me hope and I still think it’s all possible.
I really appreciate your insight. This still gives me hope, and I very much look forward to the future of Rhino and GH.
I really hope we don’t limit ourselves to the concept of “sketches”. I think “sketches” is a limiting concept. Unless, it means “3D all the time” – per say.
