Doesn’t matter how much time it takes once you’ll understand and will have trust it will help you to solve your problems and will love to spend as much time as you’ll need to have a solution for a particular item. And when you’ll be in trouble for sure this enthusiastic community will help you with a lot of ideas. I’m not a programmer - I’m thinking in terms of Basic language [from the old Sinclair Spectrum computers-if you remember…]- but with Rhino first and then Grashhopper I’m creating my tools for designing footwear. As I am a self-taught person at one moment I found to be much more easy to learn Autodesk-Delcam Powerpoint from Rhinoceros tutorials searching for similar functions [‘it have to be something similar in Powershape’…] than to try to understand the help language of the first one! Thanks now I can rely only on Rhino-Grasshopper [impatient to include Kangaroo at one moment in time…] This is my experience!
And in the late sixties they did essentially the same thing although using pen and paper for the visual flowchart- part:
(I think it reads 1969 in the upper right corner)
FBP, inherently parallel, components likened with multiple machines in parallel in a factory , “you don’t even have to think about it” says the father of Flow Based Programming (FBP).
Since those days many of us went astray into the ever increasing über complexity of modern IT. (OK, some of our latest stuff is actually useful, but über complexity is still a problem).
// Rolf
OK, but how long to get as good as Laurent Delrieu?
There is no real answer.
The important is to solve your problem or the ones of other people. I began with my problem on ship modeling for making some ships I sell on turbosquid (Vessel 3D Models for Download | TurboSquid) so I automate propellers making (https://www.youtube.com/watch?v=D9LJBL19v-0) and handrail generation (Handrail generation - Grasshopper). It didn’t take me too long as Grasshopper is a fantastic tool. There are some tricks like baking, DataTree, some components with names that are not self explantory (for a French native)… But if you know the logic how to make a model on Rhino you must apply this logic to Grasshopper. Grasshopper is a big Lego, you must know the bricks (you have them). To know them you must use GH and it is good to answer other problems because it pushes you out ou your confort zone. So you learn new things that you will use for your own project.
It seems obvious, but it is also useful to know how to use a search engine to find ressource on internet. Most of the questions were already asked.
O.P. here. This is a helpful discussion for me. Thankyou all. I have been following this thread and watching tutorials.
Is it accurate to say the following? (If so I think a Rhino- savvy person – like me-- could very smoothly and intuitively learn to wield it, and success would be directly related to Rhino knowledge):
-
Grasshopper is a visual display of a) a linear command flow for a given object which allows b) the retroactive adjustment of c) any of the parameters/nested-parameters of d) any of the commands/nested-commands. It’s e) a chained command history for any object or group.
-
These commands include those a) specific to Rhino and b) any plug-ins installed, as well as c) commands which are unique to GH.
-
Using GH requires knowledge of only the following: a) the commands of a Rhino installation, b) those of GH, c) the basic vocabulary of how to connect parameter adjustments to command boxes (and a block/sub-block for every nested command parameter/sub-parameter), d) creating a linear flow of modification actions as a direct visual representation of the command history, and e) how to trigger and interpret GH’s context help prompts to explain the controls of any GH element/command.
Please suggest any changes or additions to the above. It think it’s a dawning understanding not just of GH but basics of any UI’s node-based control system, which I see in VFX, animation, and the controls of the FX mode of at least one NLE (Da Vinci Resolve).
1.) This is what it should be, but is not!
Grasshopper uses a subset of Rhinos functionality, but since its not possible to call all Rhino commands directly, difficult and overcomplicated workarounds are often required. This however is nothing to blame the developer of, since its a limitation of Rhinos programming interface, and exposing all the commands in a scriptable manner would require a huge amount of additional development.
2.) Grasshopper is built ontop of Rhino, so its bound to it, however some functionalities are added, also through 3rd party plugins.
3.)Well, as said in 1:) Grasshopper ideally should require command knowledge only, plus some basic math and knowledge about its data management, but thats not the case.
Especially because GH is limited in its Nurbs capabilities, a higher understanding of how Nurbs are working is required to master it in a professional usecase. Any pro user in this forum had to learn much about it during the last years, or is completly working on polygonal data only. This actually makes it only conditioned useful as an modeling tool. But it certainly is a great tool for automating repetive work (at least to a certain degree). The biggest drawback of GH in my oppinion is its limitation in making continuous surface models.
Another aspect is the missing mouse information any Rhinocommand works with. It is actually a challenge to give this information in a “relative” manner.
Visual programming, is programming and sooner or later you will start writing real code. So learning how to code is a good idea. I opens new doors in pushing gh boundaries. And doing this in order to solve real problems is a sign of mastery.
Sure … Like any other improvement in Rhino. 
object or collection of objects
… and f) how to google (other search engines are available) for real information on the components and their use because the inbuilt help information is often wholly inadequate at present.
g) Understanding of data tree structures and their manipulation. Data trees are normally hidden away in the engine room but here they are front and central: beyond developing trivial apps you need to understand them to know why GH isn’t matching up your data flows in the way you want (and what best to do about it).
h) Understanding of the concepts and techniques of refactoring programmes (here to include rearranging diagram layouts for clarity).
i) Understanding of an effective way to take an algorithm and translate it into code.
j) Understanding of how to include just sufficient documentation to allow a stranger (or you, two years later) to quickly understand what your programme is intended to do and how it goes about it.
k) The ability to design and execute test cases to prove that your programme does what is intended, particularly under extreme or unusual conditions.
Regards
Jeremy
This is enlightening. Helpful comments here. It seems like the comments above indicate where GH becomes less intuitive and the real learning challenges begin.
I can see how mouse input becomes challenging when it has to control relative rather than specific conditions. The other challenges seem to represent potential educational rabbit holes. At least seeing them listed as they are in the above few posts begins to suggest a road map for learning them. Each seems significant.
Of course this is a personal learning curve, but I can at least share my experience, since I’ve only just started with Grasshopper myself.
I’ve been at it for about 9 months now, in my spare time, more or less like a hobby.
I have no real programming background, nor did I know Rhino before I started exploring.
The only experience with 3D modelling for me was Autodesk Fusion 360 and (not advanced) Revit (if that even counts), apart from standard AutoCad. I thought it look cool and that’s why I wanted to explore it. The idea of being able to real-time parametrically change a model was intriguing.
Those 9 months were certainly not entirely filled with Grasshopper, so I probably could have reached my level of understanding in about half the time. However, I just went with it, since I really didn’t need to hurry. I thought of an idea or concept and then I tried to model it without hard coding as much as possible. Along the way I googled and searched on youtube whenever I was stuck.
At this point, I think I basically understand how Grasshopper works, how data flows through the components, how to manipulate data and how to not end up with that very familiar first meme from above.
In my opinion, it’s all about getting to know all the different components, know what they can do and how to use them. Learn the differences in types of geometry so you don’t end up putting a BREP into a surface input, hoping it magically converts into a surface. Once you know all of this, the possibilities are endless and programming Gh scripts becomes a joy. The bridge between the idea and the model becomes obviously smaller with increasing understanding.
For me, as a civil/structural engineer, ultimately it’s about making a parametric model that can be analysed structurally and adjusted based on the results. Therefore, I’m exploring the world of Kangaroo and Galapagos/Octopus, combined with Millepede or Karamba.
And this is the part where my level of understanding diminishes, because at least for me, this requires a lot more time to fully comprehend. In fact, I need to learn more about the different components and understand what they do, so I can use them to achieve something that makes sense. I would probably still be learning in 10 years, as Michael said.
I don’t know for sure of course, but if I would have worked on it 8 hours a day, I probably would have achieved my level of understanding in a couple of months, give or take.
Anyway, I can recommend 3 youtube channels that helped me a lot learning how to use different components: Parametric House, Daniel Christev and Om. egvo.