Feature Request?

Hi, I am a long time Rhino user (10 yrs all PC based) and very new Grasshopper user. I am a product designer and I have a bunch of experience working on AAA video game tittles as a level and character modeler. That being said, I am really interested in Grasshopper and I am having trouble learning it. Learning new software is often difficult especially when you are learning a new paradigm for creating like going from ZBrush to SolidWorks. Node based modeling is new to me.

One thing that I would like for Grasshopper that I have seen in MODO is more connection between the GH editor and the Rhino environment. I would like GH to recognize what I am doing in the Rhino work space automatically. If I create a polyline a polyline node automatically pops up in GH. If I revolve that polyline that connection to the polyline is also reflected in the GH window. This is not earth shattering. It would not only be a faster workflow but it would be a bridge to ramp into using GH faster/make it more likely that I would actually use it. Once I see how things are linked up based on how I already work I can go back in and add sliders and add logic that GH has that I done even know exists.

Is this realistic to ask for?

Thanks!

Replies to This Discussion

Permalink Reply by David Rutten on July 3, 2014 at 11:44am

Hi Kevin,

everyone would love to see that, unfortunately it's one of the more unlikely features to be added, for four reasons:

Not everything in Rhino has a parallel in Grasshopper. Lots of commands simply don't have components that do anything similar. Even if there's a similar component, it may work in slightly different ways. Polyline is actually a good example, in Rhino a polyline can contain arcs, in Grasshopper it cannot.
Rhino commands heavily rely on mouse picking, Grasshopper never relies on mouse picking. A mouse pick provides a command with a lot of information which cannot readily be transferred to GH logic (In what view did the pick occur? How is the CPlane in that view oriented? Where on the object did the user click? Were object snaps or smart-tracking involved, if so, what can we surmise from this context?).
Rhino is a huge project that involves dozens of people. Adding 'GH awareness' to all of Rhino would take a lot of time and effort, both for Rhino developers and for Grasshopper developers.
Rhino and Grasshopper are both plug-in systems. Even if we make this work between native Rhino commands and native Grasshopper components, how can we keep it working when 3rd party code is involved, ideally without dumping a huge amount of work and responsibility on said 3rd party developer?

There are special cases where what you suggest may be relevant. Rhino history for example is currently recordable but not editable. Grasshopper may be a good interface for making the history data editable. We do not know for sure.

David Rutten

david@mcneel.com

Permalink Reply by Kevin Pasko on July 3, 2014 at 12:03pm

Hi David,

Wow. #4 really puts out the fire on my desire to learn this software and pushes me further into MODO. I dont know how Pixologic and The Foundry handle this issue but it doesnt seem to hold them back from regularly developing tons of features that everyone wants. I think the plug-in system paradigm is great for developers but not so great for users. Researching plug-ins is a part time job in itself. I just want a software that works and grows. Is there something that I am missing?

Respectfully,

Kevin

Permalink Reply by David Rutten on July 3, 2014 at 12:57pm

There's no way on Earth that McNeel employees can code up all the stuff everyone needs. We often don't know enough about niche areas to make a functioning tool for people who need that and even if we were omniscient we still couldn't type all the lines of code required.

Actually many people (including McNeel & Associates) hold the view that the plugin system is what makes Rhino and Grasshopper so successful.

Grasshopper certainly isn't for everyone, we've never made that claim and anyone who does is clearly mistaken. Perhaps MODO has been the best tool for the job you need to do all along... only you can make that decision.

David Rutten

david@mcneel.com

Permalink Reply by Kevin Pasko on July 3, 2014 at 2:59pm

Hi Dave,

I used to work for a top video game studio. I understand managing resources for software development. In video games you are not done when something works. Everything has to be optimize to be to run at 60FPS. User interface is a huge aspect of successful products.

My comments were not based on a niche function. My feedback identifies a glaring short coming concerning how Grasshopper is presented in a global sense. There are other software packages that better integrate node based systems that have been doing it for a decade.

I understand the McNeel philosophy of residing in the paradigm of being a platform for plug-ins. I think that is false safety. When you are not extending yourself to continue offering features when everyone else is outpacing you on features you have no future. Its not like your creating an OS... Im not sure if I even fully buy that rationalization because McNeel does try to offer new features. This seems to be a rationalization for slow development rather than an MO. Rhino is a surface modeler not a development platform.

Dont get me wrong, I am rooting for Grasshopper! I would love to benefit from its promise in building functional objects in an environment that I am already familiar. As a design professional when you tell someone that you have feedback on their product and they say, "thats too hard", and "well, this is a funky little thing. its not made for you" is sacrilege. Jazz isnt for everyone. That is not a valid rationalization for consumer products.

-Thanks

Permalink Reply by David Rutten on July 3, 2014 at 4:53pm

I'm a bit confused now... I don't quite follow what "[...] a glaring short coming concerning how Grasshopper is presented in a global sense." refers to. McNeel doesn't invest in marketing much and I don't know how -if at all- we're presenting Grasshopper in a global sense. Lots of our users certainly seem to do so, but we have no control over that.

I know that node-based editors have been around for a long time. I myself used Maya hypershade in 2000/2001, which was at least a year before I learned to program. Nobody at McNeel claimed that Grasshopper was in any way innovative in the grand scheme of things.

I understand the McNeel philosophy of residing in the paradigm of being a platform for plug-ins. I think that is false safety.

It is certainly a risky position to be in. It puts us at the mercy of other companies for a continuous product. The most recent case in point is T-Splines; it was bought by AutoDESK and the future of T-Splines for Rhino is -at best- uncertain. However the alternative cannot be that McNeel & Associates do all the work instead, as mentioned before we don't have the know-how, we don't have the man-power, we don't have the time and we don't have the funds to do everyone else's work for them. We have to choose very carefully where we invest our efforts. One of the areas where we have chosen for a long time to do so is the 'platformness' of Rhino. We want our users to be able to control Rhino through scripting and through plug-ins, both their own and someone else's.

We do of course develop new features ourselves, about a dozen people work full-time on the Rhino code-base, but that is no match for the 10,000 or so individuals and companies who are writing plugins and scripts.

As a design professional when you tell someone that you have feedback on their product and they say, "thats too hard", and "well, this is a funky little thing. its not made for you" is sacrilege.

I understand where you're coming from, and you're probably right in that it's an awkward response to a feature request. McNeel likes to tell people that we listen to our customers and in a way we do. Unfortunately there are so many customers asking for so many things, that we can pretty much pick and choose amongst them without violating our mantra. We do try to pin-point real problem areas, but I'm the first to admit that hasn't resulted in major improvements in those areas (I'm thinking Make2D, the mesher, surface booleans, etc.). These things are being worked on, but they are proving to be more difficult than one might think.

While "that's too hard" may be sacrilege from a marketing point of view, and while it's a dispiriting response to honest user feedback, it's unfortunately the truth. As the developer of Grasshopper, my immediate fealty is to existing users. It is my job to make their lives easier by improving the software*. It is the only thing I can virtuously do. To put prospective users ahead of actual users is to make a promise and break it concurrently.

David Rutten

david@mcneel.com

* I realize adding the requested feature would be a significant improvement, but it comes at too high a cost. The improvements we can achieve elsewhere in the same amount of man-hours dwarf the benefits of this particular feature.

Permalink Reply by Kevin Pasko on July 3, 2014 at 5:12pm

Thanks for your lengthy insightful response.

What I meant when I used the word "global" was expansive over the whole scope of the software not in the geographic sense.

I know some people at McNeel including Bob. I would not say that they are a group that lacks "know-how".

Permalink Reply by Marco Traverso on July 4, 2014 at 11:48am

David,

Out of curiosity, would it be theoretically possible to write a RH/GH plug-in that replicates the functionality of some of Rhino's native commands inside the viewport, and at the same time creates components inside Grasshopper?

For example, a new "Line" command that creates two construct point components connected to a Line component?

Then, if it's possible, it could associate a Rhino object ID with the correspondant component inside Grasshopper; so for instance if the line is extruded, then on the Grasshopper canvas the line component already in place would be connected to a new Extrude component and so on...

Permalink Reply by David Rutten on July 4, 2014 at 3:24pm

Yes that is totally possible. The problem is adding this behaviour to the 1000+ commands in Rhino that are relevant in some way or another to Grasshopper.

David Rutten

david@mcneel.com

Permalink Reply by Mateusz Zwierzycki on July 4, 2014 at 3:37pm

Wouldn't theoretically be better(easier) to reverse engineer the rhino command line history ?

Permalink Reply by David Rutten on July 4, 2014 at 3:58pm

The command line history is very incomplete, not to mention it's localized, so I'd have to write parsers for all 14 languages we ship Rhino in. What we've been thinking about is that it makes the most sense to read in the Rhino History records attached to objects. Unfortunately at present there is no style-guide for how to make history records, nor is there a guarantee of consistency, a developer may choose at any time to change the way history data is stored on an object.

I personally don't think the current implementation of Rhino History is going to help me much, it doesn't record anywhere near enough data and often History data is just missing when it could have been there.

I did discuss this issue with Steve Baer and Dale Lear at the Seattle HQ last November, but it was decided in the end that it is currently not possible to harvest this data and that making it possible would require a huge amount of work.

David Rutten

david@mcneel.com

Permalink Reply by Marco Traverso on July 8, 2014 at 4:57am

OK, thanks for clarifying this. Obviously it would be a very tedious task to replicate all the functionalities, and probably it isn't worth the effort.

Permalink Reply by Paul Arsene on December 6, 2014 at 4:09pm