Before anything just let me state that your post is going to be super helpful and I’ll probably bookmark it. I had a feeling that would happen . But anyways thanks for digging that up.
The best resources on Rhino in general do require some digging. The level 1 & 2 training manuals for instance.
I found the resources available for C# plugins (both for GH and RhinoCommon) to be a little lacking. I actually use Visual Studio to code (very simple) GH plugins (probably better to call them scripts not plugins) and I actually copy/paste the code into the script editor in GH. This is a huge time saver but will probably get me in trouble if I ever code something more complex.
Very helpful! And thanks again. I wish we didn’t have to dig for this stuff.
I might be old school but I greatly prefer having a PDF and not videos. Almost everything is videos these days. It kills me to have to scroll through a video to try and find something. The Level 1 and 2 manuals are perfect for me. But that style of resource is very rare these days.
And being old, I seem to do much better with MDI-style interfaces. Simply figuring out how to navigate through the GH canvas. I remember one thing that killed me was figuring out how to add an input variable to a C# script component… I think I spent like 30 minutes (you just need to zoom in until the “+” sign appears). No biggie but add in like 100 other things like that… Some of these things are hard to search for. It was never the little things that were killing me like they are these days.
Some of us have to admit that we maybe just aren’t GH material. But I do know that the learning resources could be improved (or even just organized a bit better).
I think the lack of GH help documentation deserves a lot more attention. It doesn’t get enough on this forum, and the message doesn’t reach the developers loudly enough, probably because the forum users are expert enough at GH to post and have cobbled together their lessons successfully already.
The answer to your question is probably, yes, there is enough stuff there, and there. And becoming a discourse forum navigation guru will help. But browsing and becoming talented at searching a forum, even a helpful one, is not a replacement for a thorough help system built into the GH interface. A new GH user should not need 1) to know about discourse.mcneel.com or 2) an internet connection.
For example, the best explanation of the biggest hurdle to using GH effectively - its, um, peculiar handling of data - is still found in a video tutorial series from over 10 years ago when Brother David used a crummy microphone. Grasshopper Masterclass with David Rutten - 01 - Overview of Data Trees on Vimeo I’ve been using GH since 2008 and I admit I still have trouble with “trees” because I cannot remember how many paths any given component will spawn, so building a new definition - even a simple one - is a risky proposition. Encounter enough invisible hurdles with insufficient help available and I’ll just say “(Expletive), I’ll just write it in RhinoScript and be done” or give up and model it explicitly.
@ThomasAn I think GH expertise is a perishable skill, except for maybe an elite level of users that have internalized how each of their commonly used components work. For the rest of us, I wish I could right click on any default component and read the official, current position on its behavior and related topics.
@Helvetosaur RhinoScript 101 and the chm file changed my life for the better forever. Every day I open GH, I wish there was something close to a current 101 for it.
@ThomasAn since you are familiar with scripting, this might be useful.
I’m personally terrible at putting large grasshopper definitions together, but one thing I do like to do is create a very small definition composed of a single scripting component and a handful of inputs to that one component (typically sliders). I can then write my function and test it under a large number of different inputs to see how it behaves.
From my humble experience, don’t expect Grasshopper to be like Rhino or like scripting.
It’s a different thing, and pretty cryptic at first, yeah.
I never became fluent in Grasshopper (fortunately I did not have to), and I like scripting very much.
Grasshopper is programming, but a different kind of programming.
I strongly agree with Steve. Grasshopper can be very useful to test scripts and explore ideas.
And you don’t have to learn much in order to be able to use it that way:
Just geometry ‘params’ to link them to components’ input and output, how to link input params,
then the Panel, the Slider and the script components under “Math”.
How to set Grasshopper preview, how to “bake” geometry … maybe someting else I don’t remeber …
Learning to master the components and the data etc. is a different and much complex task IMO.
The Trees (which are not trees) are particulary difficult to understand for me.
Not the data structure itself, but how the different components handle them …
Grasshopper has its own vocabulary and its own concepts, that may be different from what we are used to with Rhino or with scripting.
( I think you would find it easier to learn how to program new Grasshopper components than to master it. )
Anyway, as I said, I think that learning a little Grasshopper may be very useful at times.
I have literally zero knowledge in any coding language yet I am responsible for implementing huge scripts that big company is relying on and making money. I’ve learned Gh from most simple cases and it wasn’t difficult to learn at all. The only thing that may be an obstacle for some is grasping the idea of handling data trees. With little effort it comes too,
You’re pretty much right. The worse thing in my experience is that you can’t interact with Rhino objects unless you use 3rd party plugins. So for me it became useless since after creating and baking 1000s of objects the objects don’t have texture mapping or textures and McNeel and David never fixed this until V8 I think, years in the making. I’ve moved on to Blender. Contrast blender where all things are accessible which is way better for animators and visualizers. However the GH community on the whole is pretty good and Lady bug I find really useful for design.
Think of GH like an excel spreadsheet but instead of cells you use those widgets. Just like in excel you can populate a cell with many different kinds of data and or formulas. Like in excel you might work with a data set of numbers or object properties etc. You can retrieve data or reference an object in the first area of Gh this is where you reference your object’s if need be.
Think of it like an old style Rhino command script but you have to build objects using those widgets or tools. The worst part is getting used to the arcane bs that seems to be inherent in the GUI, like how many caveats there are to moving things, vectors that kind of work etc. And then if you use V7 you won’t have textures or mapping etc. you have to use 3rd party for that so many times it’s easier for me to use VB scripting in Rhino instead.
GH shines if you have to do parametric things but I’ve found that most of the time I just don’t have the hours to waste getting things fully parametric. By that time the jobs over.
RM
Fictional conversation:
“We take note of your comments as they represent first-impression observations and UI first impressions are critical in adoption of a product. Instead of trying to gaslight you that your experience was invalid, we will consider if there is something we can tweak in the tutorials or help-screens to bring the more important info forward and noticeable. For example we could make the GH welcome tutorial screen first mention how to actually link Rhino geometry to a GH node before we inundate you with other concepts.”
Same experience here, compared to many here I’m still relatively new to Rhino, but I’ve used a wide range of technical interfaces for decades, including similar “patcher” style environments such as Max/MSP, and various scripting protocols.
The fact that a necessary and often used function like Bake is buried in a context fly-out definitely seems oddly obscure. I think that anyone building user interfaces really needs to read Don Norman’s The Psychology of Everyday Things. One of its core arguments (which is incidentally contrary to what might be construed from the synopsis in that link and some summaries of the work) - is that the concept of “intuitiveness” is in no way fundamental or objective - but is rather a result of exposure, observation and conventions. And that what seems obvious or trivial to an experienced adept is often quite arbitrary. Non-discoverability is the bane of use adoption. (maybe that strategy benefits free-software development, where adding users actually represents a cost)
Am looking forward to really digging into GH at some point - I even had this tutorial printed out for off-screen reference.
After my first week of using GH I was far more frustrated at the GH window being unable to dock (it still frustrates me) than anything in GH itself. I agree the interface at first glance gives no hint as to it’s utility, but after 15 minutes of following a beginner tutorial it becomes evident how the workspace functions and then you’re away exploring the various tools.
Same here. It’s really direct and useful.
Quick tests, simple debug.
I tried VisualStudio but developing there feels “distant” from the real environment.
GH made me learn C# in no time. No prior experience in C# at all…
Sadly Rhino 8 script editor is not yet ready, lacking descriptions of methods is a hard wall for me…
lol … what you wrote made sense. Ok.
But now?
Did you understand the use of params to “link”/reference Rhino geometries… and later bake to have an output to Rhino again?
I periodically teach GH to groups of people… this problem of yours is more unique than rare.
Usually the real problems are vectors and datatrees (which are not present in Rhino)…
Is this something we have logged as a bug? @eirannejad is making a lot of tune ups based on feedback lately and it would be good to make sure he is aware of this.
I did write so on the thread he was following… no more replies…
By the way. Can I ask if you feel the same?
Are you using the c# editor in Rhino 8?
I do not remember all the methods and sub-methods of all the Rhino and System libraries. Descriptions helped me learning and using it.
Not having descriptions really “cut my legs” and after a couple of rows of code i go “well, let’s just do this on Rhino 7”…
One of its core arguments (which is incidentally contrary to what might be construed from the synopsis in that link and some summaries of the work) - is that the concept of “intuitiveness” is in no way fundamental or objective - but is rather a result of exposure, observation and conventions.
I hope the fact that this could apply to my situation doesn’t mean I’m getting old haha! I have found that figuring out what does what has taken me much longer with Grasshopper. One reason for that is the lack of a manual and having all the information in one place. This post has helped with that however. I have also found that I just find my way around other programs faster for whatever reason. In recent years it’s not just Grasshopper. Programs like Sketchup felt awkward to me. I also don’t like a lot of mobile interfaces.
The subject of making GH more “user friendly” is valid, there is plenty of room for improvement
But some aspects of this discussion remind me of a comment I once saw on a video about Berkey water filter systems, which are excellent in my experience. The comment was that they leaked so this person had stopped using it. The problem was obvious to anyone who uses the gravity flow system correctly. The top container is never filled until the bottom container is empty! It is designed that way for good reasons.
If you’re coding in C# I’m sure you noticed that the method signatures and description are shown after you type (. But yes, it would be more useful to get the descriptions before you select the method.
Several user’s in this thread have complained about the difficulty or obscurity with baking (which is a valid criticism). Grasshopper in Rhino 8 has a new component called Content Cache which will “bake” any content (not just geometry) directly into the Rhino document. You can add a boolean toggle to this so that any change in your Grasshopper definition will be reflected directly in the Rhino model. Here’s a quick demo video.
. But anyways thanks for digging that up.
It is designed that way for good reasons.
