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.
There is a level of âfrictionâ in being able to share GH scripts with others if they have to manually install libraries such as these that does not exist if they are handled automatically by the Package Manager.
Considering how popular these (and possibly a few others) GH plugins are, could McNeel perhaps reach out to the developers and help them migrate the files onto the Package Manager.
Iâm sure in both cases it is just a time/resource issue that these are not on the Package Manager rather than an actual decision to only offer on Food4Rhino.
@Keithscadservices@kiteboardshaper I highly agree with both of you. Take offset surface as a solid: thatâs a foundational Rhino tool that is missing in Grasshopper made available by Pufferfish. The other ones I frequently use are mesh loft, mesh pipe, mesh offset, and flip plane.
one might even consider setting up a poll, where user can list your favorite Non_Native components, that we would like to see brought to native grasshopper.
I for one would like to see MeshExplode or MeshFromPoints (I think both MeshEdit plugin) be brought to gh
So, with todays welcome news that Pufferfish is now available on the package manager, is there anything that can be done to get Anemone on there as well?
Just an idea here also regarding the OT. If you boil it down what happens, then its all about placing libraries into the right folder, to load the required plugins.
When you think about it you could mock something like a virtual environment from Python. You place you project files into a dedicated folder and include all the dependencies in there as well.
Then you write a simple Powershell/Batch startup script which copies the dependencies into the right folder, or you modify the path which Grasshopper should look for plugins within Rhino. This requires that your main plugin folder ideally does not contain any libraries at all.
