Grasshopper

algorithmic modeling for Rhino

EDIT : Let us all discuss the pros and cons of a 3D interface in GH.

Disclaimer

1. Content
The author reserves the right not to be responsible for the topicality, correctness, completeness or quality of the information provided. Liability claims regarding damage caused by the use of any information provided, including any kind of information which is incomplete or incorrect,will therefore be rejected.
All offers are not-binding and without obligation. Parts of the pages or the complete publication including all offers and information might be extended, changed or partly or completely deleted by the author without separate announcement.

2. Referrals and links
The author is not responsible for any contents linked or referred to from his pages - unless he has full knowledge of illegal contents and would be able to prevent the visitors of his site fromviewing those pages. If any damage occurs by the use of information presented there, only the author of the respective pages might be liable, not the one who has linked to these pages. Furthermore the author is not liable for any postings or messages published by users of discussion boards, guestbooks or mailinglists provided on his page.

3. Copyright
The author intended not to use any copyrighted material for the publication or, if not possible, to indicate the copyright of the respective object.
The copyright for any material created by the author is reserved. Any duplication or use of objects such as images, diagrams, sounds or texts in other electronic or printed publications is not permitted without the author's agreement.

4. Privacy policy
If the opportunity for the input of personal or business data (email addresses, name, addresses) is given, the input of these data takes place voluntarily. The use and payment of all offered services are permitted - if and so far technically possible and reasonable - without specification of any personal data or under specification of anonymized data or an alias. The use of published postal addresses, telephone or fax numbers and email addresses for marketing purposes is prohibited, offenders sending unwanted spam messages will be punished.

5. Legal validity of this disclaimer
This disclaimer is to be regarded as part of the internet publication which you were referred from. If sections or individual terms of this statement are not legal or correct, the content or validity of the other parts remain uninfluenced by this fact.

Views: 417

Replies to This Discussion

It would certainly be interesting to have the 'executable graphics' of the program definition existing in the same sort of 3D space as the input/output objects.

The closest I've seen to this sort of thing is VP3l from lalalila - a spatial programming language for music. Al Jazari is another nice example of a pseudo-3D programming environment.

It seems to me that a lot of the precedents for Grasshopper's visual dataflow approach are in the world of music creation. (such as reactable and Quartz Composer) (there is a nice article on these over at Lambda the Ultimate)

Such a left-to-right 2D visualisation makes a lot of sense for notating music over time, but one could perhaps argue that something more spatial would be natural for notating architecture.

What do you think might be the pros/cons of a 3D programming space ?
It might avoid some of the confusion of crossing wires, but don't know if this would outweigh the added difficulty of navigating and organising the layout.
Would the programs end up looking anything like the buildings they described ?
>Such a left-to-right 2D visualisation makes a lot of sense for notating music over time, but one
>could perhaps argue that something more spatial would be natural for notating architecture.

That would make sense if each component generated a small part of the final scene like if you where laying bricks. But in reality, imagine this definition:
Create grid of points -> move grid of points randomly -> create boxes on the points.

As you move toward the right, every component transforms the complete scene over time. It's actually more similar to notating music over time.

In the end we are just transforming information, the canvas should try to be a visual approximation of this data manipulation, not the final 3d model the data produces.
I was hoping to trigger such interesting remarks and examples. Thanks Daniel.
The third dimension could be a way to organize the variables and functions.
In "Top view", thinks would look Exactly like they are right now, but if you incline the view, objects could appear organized by "layers".
One could also "stack" some of the objects on top of each other to make them appear as a single object in top view, to simplify the schematic of the definition ; a 3D cluster of sorts...
That statement somewhat irks me. No pros/cons, no room for anyone else to say anything. It comes off as a mandate to the masses.

Personally I think that there is no reason for the GH interface to be in 3d. There are several reasons for this. First one being its a big waste of time. I'd much rather have additional features, and more robust solvers before a new 3D interface.

Secondly, GH already has enough overhead with calculating geometry over and over again. I'd prefer not to have it take up even more memory and processing power.

Thirdly, I see a 3d environment being more of a disorganizing force than organizing one. When in a environment is in 2D, there is a consistent orientation, and an inherent understanding (in the western world at least) of left to right flow. Believe it or not, when you open up someone else's definition, or when the open up yours, this "system" allows one to get their bearings fairly easily and begin to process what's going on within the definition. In 3d, i think that would be lost and actually prohibit communication if someone isn't familiar with the spatial organization you've used.

Ultimately, I don't see how 3d makes anything easier/better. Its still up to the user to lay things out in an organized way, and being in 3d only allows for more potential disorganization. Even worse it allows for an actual organized definition to be perceived as disorganized much more than 2d. The nodes, and also the logical progression tend to have a left-to-right/top-down sort of mentality, so what will most likely wind up being almost 2.5D with a definite linear progression with spatial deviations to delineate parallel/separate logical paths. To me a 2.5D approach flattens to pure 2D just fine, and the 3rd spatial dimension may be nice, but not a requirement.

To me the argument that "what is created is spatial, therefore we should create it spatially" is somewhat weak. What gets created by a given operation (a move with multiple vectors) may have multiple spatial relationships. Yet since the node that performs the operation is singular, there's only the capability to either make 1 meaningful spatial relationship (which may or may not relate to every user) or to make a spatial relationship that does not try to connect with the outcome of that operation. To me, the latter is something that will windup being more prevalent. In addition to this, what sort of spatial relationships to do logical or mathematical operations get, since they don't necessarily have any relevance, spatially?

If you've got some pros for this idea, I'd love to hear them. I don't really see any other than "its cool". Granted I'll give it some wiggle room just because of that, but at some point there's got to be some solid reasons for making the switch.
Hey Damien, cool off.
I was just thinking out loud here.
By the way, I didn't bother reading all your answer : you evidently didn't understand my state of mind.
Thinking out load usually means more than one sentence. You also didn't explain your state of mind so how could I "understand" it. Give me more to go on and I'm sure we'll have a better discussion.
Well it turns out the discussion IS interesting, so I don't regret being a bit provocative.
I'll put a "second degree" warning next time for you, so hopefully you won't get "Irked".
I completely agree that it would probably not be productive to actually switch GH to a 3D interface now or any time soon, and I am also very dubious about whether it would ever really be worth it.

Still, I do think it is worth taking just a moment to consider whether there might possibly be some uses for spatial programming and imagining directions in which things might develop in the distant future.

As for a 3D environment being a disorganizing force compared to the constraints of 2D with a consistent direction - This generally rings true. One of the things about GC that I liked in principle at first was the freedom to arrange components top-bottom, left-right, radially or any other pattern.
However, in practice I found it often just gave a lot more room to make an unreadable mess.
Agreed, left-right is deeply culturally ingrained and anything else is very counter-intuitive.

Even so, just because it is difficult to get used to doesn't neccesarily mean it might not have potential advantages if we could develop some new conventions and organisational principles.

Architects are presumably more in the habit of 'spatial thinking' than average so I imagine they are as well suited as anyone to find a way of using spatial programming (if indeed there is one).

A linear, sequential approach is not the only one possible for computing, and music-like notation might not be the most suitable visualisation of some of the other alternative paradigms.
I guess many of these other paradigms would also require a visual representation of some sort of recursion/iteration/conditional looping - which is a whole other discussion in its own right...

In what I said about possible links between the spatial form of the program and its output, I do not actually make the point that seems to be being argued against above. I was not imagining a direct link at all - just wondering if there might be some possibility of a meaningful abstraction between the two.

As for the last question I posed, my own answer would be:

"probably never in any direct sense, but perhaps the abstract relationships between program structure and physical structure might be something you could develop a feel for"
I'm all fine for ditching a completely linear/sequential approach within the GH environment, thus making way for a completely spatial interface, however with that would also require (in my mind) really developing GH as a true visual programming language. At the moment I feel that nodes are simply representative of commands/methods that would be used with in Rhino/scripting and that a great deal of programming structure is not actually exposed and allowed to be manipulated.

Because of this, some of the programming structures that are all so familiar and useful within code (as you mentioned, recursion/iteration/flow control) are kept at arms length within GH. I'd wonder what an If..Then statement would really look like, or how would a nested For Loop be organized? It would be nice if GH could allow for that granular of a control in order to explore those kinds of relationships...
I think 2.5D would be more appropriate...with some more 4D components...like loading up an mp3 file and using its waveform to change parameters...as was done a while ago by...uhm, hmmm, cannot search the old google group...was it Vicente?

Excuse my very simplified description of the fourth dimension. And now that I think of it I suppose GH is already sort of 2.5D...
a kindof 2d parametric sketching enviroment would be great with parameters for input and output and reference inputs

RSS

About

Translate

Search

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service