One of the things that makes Grasshopper powerful is its plethora of plugins and a great community of developers, so I am very grateful. However, these are a few issues that I have had with plugins over the years, especially with Rhino 8.
Random plugins start/stop loading with Rhino updates. For instance, NGON and lunchbox stopped working.
They are a pain when sharing your script with clients. Some plugins download automatically while others (like Pufferfish) require the legacy loading into the components folder.
Developers sometimes do not keep them updated. For example, I have had to replace all the old Human components with the Rhino 8 “rhino” attribute components.
There is no way of organizing them at the top. Some plugins have only a few components, yet occupy the same tab size as plugins with a full screen of components.
Many plugins are libraries of a hodgepodge of utilities that firms have developed. Often these components do the same thing as many other plugins or core Grasshopper does. I much prefer libraries that do specific things that are distinct so that I don’t download what I don’t need.
Plugins make starting grasshopper slow
Why not use the paradigm that is used when coding: You call a library or only a part of a library when you need it? You don’t load the whole library every time you open the IDE.
If anyone has thoughts or solutions for these points let me know.
plugins that extend the capabilities of grasshopper or fill in its gaps are great. eg: human, elefront (still using R7), Firefly (haven’t used it in a while, but it led to some cool connections between live environmental data gathering and grasshopper visuals)
plugins that are glorified clusters or offer “shortcuts to do xyz” or are toolboxes of a firm’s favorite scripts tend to be bad and end up causing more headaches because you inevitably run into an issue and so few people know how to correctly troubleshoot the plugin let alone help you/keep the plugin updated
First off, I want to express my immense gratitude to all the incredible developers who dedicate their time and effort to creating and sharing plugins for Grasshopper, often for free. Your contributions enrich the community and push the boundaries of what’s possible. Thank you!
Opportunities for Improvement
That said, I believe there’s room for improvement in how plugins are developed, organized, and integrated. Here are some areas I’ve noticed where things could be more streamlined:
Naming Conventions
There’s no standard guideline for naming components nor their In and Outputs.
Some plugins use full descriptive names, others use abbreviations, and some rely on single letters. This inconsistency can make it hard to understand what a plugin does at a glance (and don’t get me starting how this messes with my OCD ;).
UI Design
Plugins like Millipede introduce their own unique UI, which can feel disconnected from Grasshopper’s native experience. A more unified or standardized design approach could enhance usability.
Shared Codebase
Many plugins lack a shared codebase or repository for collaboration, like GitHub. This would not only encourage shared development but also improve transparency and bug fixing.
Prefix and Naming Standards
Some plugins use prefixes like “LB_” (e.g., Ladybug) to organize their components, while others don’t.
Having a consistent prefix or naming guideline would make it easier to identify the plugin a component belongs to.
Native vs. External Components
It’s hard to distinguish native Grasshopper components from external ones at times (e.g., components like Mesh Edit.
A small UI indicator, such as a highlight , could help clarify whether a component is native or comes from an external plugin.
Suffix Naming Conflicts
Some plugins use suffixes like “point_” for their nodes and then have like dozen of them named like this. This can surpase native nodes with the same name in the search field, making native ones impossible to find via this menu. A consistent naming hierarchy could solve this issue, or a scroll and filter option in this menu (as i proposed before).
Dependency Tracking
Grasshopper doesn’t natively list plugin dependencies for a file nor is it avaialble as a node or menu item. MetaHopper has one method, and with python one can created a custom node that tracks external plugins, their names, libraries, and usage counts (search forum). However, it would be great if Grasshopper had a built-in tool to handle this.
Invisible Tracking
ShapeDiver has this invisible node it seems. I don’t have it installed anymore, but when i open a older file that once had a node by them and that was delete, it still prompts it at lanuch asking for ShapeDiver Document Payload object
can wait what Joseph_Oster] has to say to your question ,
I’m avoiding plugins while I learn and get better at GH but I’m finding more and more that if I want to ever incorporate GH into actual profitable work I can’t be starting from such a low base every time I start a project.
I agree with the comments regarding more popular plugins: McNeel should purchase them off the creators, refine them, and then include them in GH.
