algorithmic modeling for Rhino
I/O default letters
I am teaching Grasshopper and one of the things my students find hard to grasp is the meaning of the Input and Output letters. The fact that sometimes a letter means one type of data and sometimes another is confusing to them, and forces you to stop over the letters to find out what kind of data it is.
Take this definition for instance.
The letter S means three different kind of things: Curves, Interval2 and Surface.
The "Interval2" kind is represented by three letters: I, S and D
The "Surface" is represented by two letters: L and S
Connecting the output of the "divide" component to the correct input of the "isotrim" isn't very intuitive since you have to connect the letter "S" output with the letter "D" input, and not with the "S" input...
I don't even think about this and I just pause over the letters to see what kind of data they are, but I have noticed that it is confusing when you are starting to learn.
In most cases I think the letter should represent the data kind. The "loft" component would be easier to understand if there was a "C" input for "Curves" and an "S" output for "Surface". But take the letters U and V of the divide tool and they wouldn't be clearer if they were an "I" for "Integer" kind of data...
Maybe there could be two letters (with the risk of affecting the aesthetics of grasshopper) or an option to toggle a learning mode with more info, or some kind of color coding...
I haven't figured out a good solution yet
By the way, in some cases there is also confusion with the difference between the name of the component in the menu and the label of the component in the canvas, like Isotrim and SubSrf.
One more thing... the learning process would be easier if there was a way to know which kind of data can be used instead of the "official" one... like using "line" instead of "vector" or "point" instead of "plane"... something like a list of acceptable alternatives...
Thanks
Bye
Views: 1228
Replies to This Discussion
-
Permalink Reply by Giulio Piacentino on
-
What you are describing happens to me, too :)
- Giulio
_______________
giulio@mcneel.com
McNeel Europe, Barcelona -
-
Permalink Reply by Evert Amador on
-
I agree! Something else about the output in some components is that the S, C, etc are not consistent, I mean the S appears at the top in some components and at the bottom in others ( I know, my wife keep saying I'm very fuzzy) anyway, this sometimes makes the wires to cross over more than needed thus making it more difficult to tidy up definitions.
As I've said fuzzy old me!
Cheers
Evert -
-
-
Hi Frane,
I suppose that makes perfect sense. I don't want to go to two characters per parameter, the components should be as small as possible by default.
One of the things I can do is have some sort of mode where the short one-letter abbreviations for inputs and outputs are replaced by their full name (not the description) when you instantiate a new one (all inputs and outputs already have names like this), like so:
In this case I'd actually prefer to maintain the same first letter "S" for "Sections" instead of calling it "C" (unless of course the input is also renamed "Curves".
Of course I cannot use similar naming conventions everywhere as some components have multiple curve inputs, and calling them both "C" would be silly.
This is just a lot of boring typing on my part, I'll see if I can get around to it sometime soon.
--
David Rutten
david@mcneel.com
Seattle, WA -
-
Permalink Reply by Frane Zilic on
-
The example of the loft component is quite clarifying.
I don't see the point in calling it sections when it takes curves... why not call it curves and place a C in that input? The curves are interpreted as sections but that is just the way the component works internally.
Something similar happens to the output: The result is of course a lofted surface but generically speaking it is a just a surface. All the other components of the freeform group have an S output except Loft and the ones that generate a Brep.
In some cases the distinction is necessary like in the "sweep" component, for instance, that needs two different curves that have different uses so the distinction makes it easier to understand...
Creating a consistent naming rule isn't easy at all... but maybe there is another way...
The name toggle is a good solution, maybe it could be related to the zoom level... you get closer and the component reveals more info like the full name and/or data kind... I don't know yet.
Just a thought...Putting aside the fact that the names should be as consistent as possible. Is it possible to somehow hilight all the possible destinations when dragging a connection? During the learning process this could help a lot and even make the naming not that relevant. There could be one color for a direct data kind match and another for acceptable alternatives...
Also it would be better if wrong type connections were not allowed. -
-
Permalink Reply by Danny Boyes on
-
Here's one argument for having a diverse array of output names for same type geometry:
-
-
-
Hi Danny
Yes, it helps. But i think it would be better if the letters were consistent with the data type, and in that menu it can, and it actually does, indicate the tool to which the connection is leading. You would get something like
Loft.S
EdgeSrf.S
Srf4Pt.S
Extr.B (maybe for Brep)
It is still very clear for disconnecting purposes...
It would be even better if you were able to select the connection and delete it... then you wouldn't have to bother about that menu. -
-
-
That menu now highlights the wire on mouseover, so the argument is no longer very strong.
--
David Rutten
david@mcneel.com
Seattle, WA -
-
-
"Is it possible to somehow hilight all the possible destinations when dragging a connection?"
No. Or rather, I can't decide whether it will work until I actually convert the data. Also, sometimes you can feed curves into arcs and then you change a value and the conversion no longer works. So whatever list I come up with of potential target is either going to be very incomplete or much too broad.
--
David Rutten
david@mcneel.com
Seattle, WA -
-
-
This feature would be just a dynamic help system, not something that would ensure that the definitions are fail safe, even more when connecting alternative data types like the one you describe.
For a lot of cases I think it should work... but there is something I don't understand...
Is there a way that a component can produce a different result than what the output specifies? For instance, can "Loft" generate any other type of data than a Surface?
If yes of course my request is nonsense, but if not then wouldn't it be possible to detect that I am starting a connection from that "surface" output and to hilight all the inputs that accept a "surface" data type? and in a different colour all the inputs that accept it as an alternative (use at your own risk).
I understand that in some cases the output is relative to the generic input, but even then some assumptions may be made... for example an addition will never generate a surface, or a Brep. This means that when starting a connection from the addition component a lot of possible inputs will be hilighted but no surface or Brep, even more, if I try to connect it to a surface grasshopper shouldn't let me.
mmm... It is highly probable that I'm not seeing the whole picture... :) -
-
-
"Is there a way that a component can produce a different result than what the output specifies?"
This is actually quite a complicated question. The short answer is "no", but I feel there's a lot more to it than most people would realize.
Let's take Numbers and Integers for example. As you probably know every integer can be losslessly converted into a floating point number. So definitely every Number input can be hooked up to every Integer output. When you convert a floating point number to an integer on the other hand, three things might happen:
- A perfect conversion
- The number is rounded to the nearest integer
- An overflow exception occurs because the floating point number is larger than the largest possible 32-bit Integer.
So it seems that you cannot just say that every Number output can be plugged into any Integer input, because there might be an overflow error.
This is a very common relationship between two data types. Surfaces can always be plugged into Breps, but Breps can only be plugged into Surfaces if they have but one face. Lines can always be plugged into Curves, but Curves can only be plugged into Lines if the curve data is linear, and so on and so forth.
Then there's parameters of generic types. What we would call 'interfaces' or 'abstract classes' in OOP. There's a Geometry parameter type which can store Points, Planes, Lines, Circles, Arcs, Curves, Rectangles, Surfaces, Breps, Meshes and any other type which implements the IGH_GeometricGoo interface as defined in the Grasshopper SDK.
A Geometry parameter might contain curves or curve-like data, or maybe a mixture of curves and meshes, or maybe no curves at all. And possibly the contents of the parameter will change when someone drags a slider about.
It would not be particularly difficult to draw little arrows in front of parameters of similar type whilst you're dragging a wire, but I hesitate to add this feature as it may throw people off by fooling them into thinking they cannot plug a Curve into a Number, or a Point into a Plane, or a Mesh into a Box.
--
David Rutten
david@mcneel.com
Seattle, WA -
-
-
It's also possible a certain object breaks default behaviour. The ParamViewer for example is actually a Parameter of type DataPath. But you can plug anything you want into it. Param Viewer just doesn't play by the rules. And nobody else has to either.
To have a system in place that would work well* I'd have to demand that every single input and output provides a list of data types that it might provide/accept. This is putting an enormous amount of work and responsibility on whoever is writing components and parameters for Grasshopper.
I can see the value in having a tight system of type-safe data, but I chose long ago to go down the dynamic path and I think it's too late to turn back now.
* by "well" I mean not giving any false positives or negatives.
--
David Rutten
david@mcneel.com
Seattle, WA -
-
-
"The name toggle is a good solution, maybe it could be related to the zoom level"
That's a solution I like a lot. There's a lot of stuff I could be drawing in high zoom that I'm currently not.
--
David Rutten
david@mcneel.com
Seattle, WA -
About
Welcome to
Grasshopper
Translate
Search
Photos
Videos
-
Field Contour
Added by Parametric House 0 Comments 0 Likes
-
Voronoi Facade
Added by Parametric House 0 Comments 0 Likes
-
Weave Mesh
Added by Parametric House 0 Comments 0 Likes
-
Pathway Frames
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson.
Powered by
