I’ve encountered an issue with Grasshopper Player in the latest version of Rhino 8 (rhino_en-us_8.14.24345.15001) and Grasshopper version 1.0.0008.
I rely on the “Keep Open After Command Completes” option because I work with a custom Windows Form application that interacts with Rhino. My application includes buttons to:
Retrieve objects from Rhino,
Bake objects into Rhino, and
Display previews of processed objects in Rhino.
These functionalities require the Grasshopper file to remain accessible, making this option critical for my workflow.
In previous versions, enabling this option in Grasshopper Player allowed the files to load and run without opening them in the Grasshopper editor. This setup facilitated a seamless process, where I could open and run the same Grasshopper file multiple times simultaneously through Grasshopper Player, as configured in my RUI.
However, with the latest update, checking the “Keep Open After Command Completes” option causes the Grasshopper file to open in the Grasshopper editor and remain open. This behavior prevents me from opening the same file multiple times simultaneously, which disrupts my workflow and introduces unnecessary constraints.
Is this an intentional change in behavior, or could it be a bug introduced in the recent update? If this is intentional, is there a workaround to restore the previous functionality while maintaining interaction with Grasshopper files through my Windows Form application?
@kike Thank you for the clarification regarding the intended behavior of Grasshopper Player in Rhino 8.
We’ve developed a custom plugin for Rhino, but with plans to expand its functionality in the future, we decided to implement our components in Grasshopper. Our workflow involves running these components via RUI by linking to the Grasshopper files and executing them through Grasshopper Player.
Our plugin is built using Windows Forms, and each component adds or processes specific objects in Rhino. During development in Rhino 8, we encountered an issue where Grasshopper Player didn’t function as expected for our custom components. After consulting with you on this topic in this thread, we implemented the solution you suggested, which allowed us to proceed with our development in Rhino 8.
The ability to run the same Grasshopper file multiple times simultaneously through Grasshopper Player is integral to our workflow. It allows us to execute and manage different instances of the same file without interference, particularly for handling separate data streams or multiple operations in parallel.
Given the recent change in behavior, we’re now facing challenges in maintaining this workflow. Is there any alternative or workaround in Rhino 8 to achieve the previous functionality of running the same Grasshopper file multiple times simultaneously without opening the file in the Grasshopper editor?
Thank you for your assistance, and we appreciate your continued support!
On this thread I was suggesting @Yasaman.ag to enable this setting in order to keep the UI defined on the Grasshopper file up and running after the GrasshopperPlayer command ends, but not as a way to run this same file multiple times simultaneously.
I’m really interested to understand why running multiple times simultaneously is integral in your workflow. Do you mind meet somehow on a quick Zoom call? Please contact me at kike at mcneel.com.
Thank you for your response and clarification. To better explain our workflow, I’ve shared an example component from our plugin here
Please review it, and if needed, we can arrange an online meeting to discuss the specifics further. I believe seeing the component in action will provide better insight into our requirements.
I see, you are running the same definition but not simultaneously.
Because of the previous bug every time you run the BOLT command it was loading again the Grasshopper definition and keeping the previews always there.
I see several issues with this implementation.
How did you clear these previews?
What should happen with this geometry when you open a new document?
It will not scale when you change current document units.
How do you modify this geometry once is “created”?
Are you trying to avoid Baking the geometry for some reason?
The first solution that I can think of is baking the resulting geometry.
This should fix all the issues listed above and the one you mention.
@kike
Thank you for taking the time to answer my question and provide valuable insights. I truly appreciate your detailed response and the effort you’ve put into helping me address this issue.
I’ve created a simple component to demonstrate a workflow similar to what we aim to achieve. In the attached video, you’ll see the following: 1- Simultaneous Instances of the Same File:
In previous versions of Rhino 8 and the current version of Rhino 7, it is possible to run multiple instances of the same Grasshopper file simultaneously, allowing the creation of different objects with each instance. 2- Custom Baking Process in C#:
The baking process is entirely handled in the C# code behind the component, not through Grasshopper’s baking components. The final output is a block object with a specific name, and all entities inside the block (e.g., curves, hatches) are assigned specific attributes programmatically. 3- Dual Functionality for RUI and Grasshopper:
The component is designed to work both as a Grasshopper definition and through RUI in Rhino. These workflows are separate and provide flexibility depending on the user’s preference. 4- Issue with Grasshopper player in recent Rhino 8 version:
As shown in the video, this workflow, particularly the use of the component through Grasshopper player with RUI, is no longer possible in the latest version of Rhino 8. This is a significant limitation compared to earlier versions.
Thank you again for your time and assistance!
Thanks for the clarification video.
As I mentioned before this workflow had serious issues in Rhino 7 and Rhino 8 before the fix.
With this I’m not trying to say the approach is wrong or impossible to support, but in my opinion is a corner case. Keep in mind that there is no single command in Rhino that can run multiple times simultaneously.
I think we will need a component that the user can place to signal Rhino the solution is done and the document can be effectively closed.
I would say that enabling this correctly, on the GrasshopperPlayer, needs an amount of work that deserves to be done in v9.
In fact, we have to release our Plugin in next couple weeks, so we have lack of time. Is there any temporary or alternative solution to this problem just for now?