I may have been living under a rock for the last few years, but I have just accidentally stumbled over Grasshopper 1.0 Docs (Beta).
This is exactly what I have been wanting for years - a view of each component, with not just the stupid parameter hints, but also worked examples and even videos on how to use each one. Terrific stuff!
It is marked “Beta”, so I suppose that it is still under development, and certainly many of the components are marked “To Be Updated” (looking at you, Path Mapper), but it is still extremely useful.
I have searched these forums, and found no mention whatever! Why!
The only improvement I can think of would be to provide the examples with a link to download an actual ‘.gh’ file to play with.
I hope that this work is ongoing and will be completed. Many thanks to the developers.
Yes, the beginning GH1 documentation has been around for some time now, but its development has been very slow and, frankly, not good:
The use of language is poor, the explanations lackluster, the examples too generic, the use of media all over the place. There’s no layout template to the body of the page and the ribbon takes ages to load. Only individual components are addressed, not overarching concepts.
I can forgive the state of GH1 documentation given where it came from: a sole developer creating a plug-in on the side for no pay. But ever since Grasshopper got officially folded into the McNeel enterprise, expectations have been elevated and consistently underserved.
I mean the entirety of the Rhino Tab is not fully documented. How is that even possible? Just a matter of diligence, but especially in rolling development, you create documentation as you go, not at the end when some poor schmuck, who was not part of the development process, has to step in and has to piece things together.
Which is how the GH1 documentation currently reads. Some poor schmuck, who, on top of their other responsibilities, has been tasked with whipping up the GH1 documentation.
GH2 is a different story. There you can see David concurrently developing the program and the documentation. He even has a linguist at his side. But, I suppose, that is not surprising as a certain amount of pride must be at stake there.
Thank you for your attention. The online documentation for GH1 is produced and maintained by the McNeel China team. We started this project around September 2024. Currently, about 80% of the component descriptions have been completed. The Path Mapper is expected to be completed by the end of June 2026.
BTW, regarding how to use the Path Mapper, I suggest you check out a previous video tutorial by David. It provides a very detailed explanation. I hope it helps you.
Thanks for your feedback. This is a great suggestion. I will log this request to our team asap, and we will update the relevant exmaple files in a future release.
Many thanks for drawing attention to this link.
I always had a vague feeling that something was missing.
It deserves to be better known; many will find this helpful.
I had never even noticed the “Online Reference” entry in the Help Pulldown! Sigh!
Now I see it, I actually like that better than the Question Mark icon, although other people would probably disagree. I see nothing wrong with having both.
The ideal would to replace the ‘Help…’ option that you get when right-clicking a particular component with a link to the appropriate page for that component in the documentation web site, or at least to add the link to that display. Rhino always seems to have many ways to perform an operation.
In my view, the (excellent) Gh 1.0 Online Documentation lacks prominence and a description that is helpful and which encourages use.
“Help” has the attraction of being a single syllable but it’s imprecise and otherwise suffers from the mental picture sometimes conjured up:
Over decades, my general experience of Application-help, is that it’s not always helpful (<—diplomacy in action). I’ve tended to ignore it in the same way that one blocks out display ads in newspapers.
Are not concise, worked examples the very thing that a first-time component user needs?
And do not “Example” or “Examples” or “Using” better capture the intent and usefulness of the Grasshopper 1.0 Online Documentation?
There’s been a lot of visual/verbose clutter creeping into Rhino 8/9 (see e.g. this post). Please also take us minimally minded folks into consideration when adding new icons (i.e. I’d prefer if you didn’t add that link)
Thank you, and I do agree with your point. This was also the original intention behind our creation of the GH 1.0 Online Documentation. In addition to providing parameter descripitions for each component, we also add small examples to illustrate suitable usage scenarios. We hope it can become a dicitionary-an online dictionary with text, images, and videos demonstrations-that users can consult anytime they encounter a component they don’t understand. That is why we also provided search and filter buttons in the upper right corner.
It would better meet our needs if the entries were integrated into the browser that pops up when you choose “Help” from the context dialogue of a component. Why are all these different means of getting to online document being contemplated
when the one that exists is fine but not being used?
I don’t know how many times, against my better wisdom and in the hopes of finding something new, I have clicked that menu item and have been confronted with just the mouse-over tool tips of the component.
It would better meet our needs if the entries were integrated into the browser that pops up when you choose “Help” from the context dialogue of a component.
This!
Help for the component from the Help menu item of the component itself.
The endless frustration of clicking on the Help menu item of a component only to be confronted with such extremely unhelpful tooltips that we’ve already seen when mouse-over each input needs to be vanquished.
While these docs are a good resource / dictionary for individual components, the real struggle for most users, especially those moving past the novice stage, isn’t understanding what a single node does, but how a complex system of nodes interacts.
In reality, documentation for a single component is only a fraction of the help needed. I’d love to see the ‘Help’ button evolve into something more like a Native Context-Aware Assistant. Instead of just opening a browser to a static page for one node, it could leverage an LLM that understands the current canvas. We are already seeing community-driven proofs of concept like SmartHopper or Raven that prove canvas-awareness is possible. I
I want to be asking: ‘How can I optimize this specific logic?’ , or ‘ How to populate this mesh i have highlihted with 100 points given this requeirment and that distance function’ and having the AI act directly on the context of the current work
Would probably kill this discourse thogh > see the StackOverflow graph of questions asked per month
While I don’t disagree with the usefulness of this idea, should we really be expecting such an advanced feature from a development team that is struggling to create the most basic of HTML-driven resources for a subset of what a replete user documentation would be?
It’s a valid concern, but industry is moving toward 'AI’ integration in almost every CAD/BIM environment. While HTML docs where once a resource, they are also a 1990s solution to a 2026 problem. Sooner or later They will have to prioritize smart assistance over static documentation simply to remain competitive.
Many of us are already ‘vibecoding’ inside Grasshopper now, using LLMs to generate compound C# or Python components and bypassing nodes/gh logic 90% of the time.
@jessesn The most likely response from the team to the request to have the online documentation integrated into the in-program help browser is that they “can’t” because the browser does not support advanced features for displaying video media or server-side rendered content. But this is just an excuse for poor scalability. The online documentation needs to be presentable in a browser of choice. So this means a static HTML page, no DIVs or Javascript. It also will help in focusing the team on content instead of presentation, a problem which has been hounding them from the start.
I’ve noticed that the help of a component differs when you right-click an input/output to when you click the main component itself. These sources need to be folded into one help document to avoid confusion.
HTML documents remain a contemporary solution in 2026 and remain at the forefront of the advancement of information dissemination. Their use does not exclude the integration of smart assistance.
