I would like to run a Grasshopper file without actually starting Rhino, or at least with no UI. My use case is to solve, bake and export meshes on a server, using various input parameters. Speed matters because the baked meshes should then be available for the person that made the request.
Since I don’t need the editor UI on the server and displaying the meshes naturally consumes time and resources, I’m looking for a way to avoid that. Preferably by using the RhinoCommon.dll without actually starting Rhino or alternatively by running Rhino headless (to avoid render and editor overhead).
Is this possible with Rhino 6? I’ve looked for docs about this but so far haven’t been lucky.
I’ve seen similar questions have been asked in the past, but perhaps something’s changed by now (or perhaps when Rhino Inside is ready?).
I’ve already built a demo based on the SampleCsAutomation example, but it doesn’t work without UI and with UI it’s not terribly fast.
I doubt that the UI makes much of a difference since the UI is “locked” during solutions anyway (GH including the UI runs in the main thread so the execution time from request until GH replies in whatever way isn’t affected by the UI at all).
If disabling preview in GH altogether there’s not much left which takes any significant amount of time which isn’t easier to optimize in code by faster algorithm’s, parallel execution or utilizing GPU.
Put a black plastic bag over the display, or shut it off, and off you go.
execution time from request until GH replies in whatever way isn’t affected by the UI at all
Is it? Perhaps I’m doing something wrong; for example, to export a mesh I currently use the RhinoScript functions SelectObject and then Export. Since I can’t run Rhino headless the mesh to export is rendered by the editor (and the time to do that isn’t zero).
I’m not sure if you’re implying that the UI can be hidden with your comment “disabling preview in GH”, is that possible? When I tried to run my sample without UI, it always crashes with some drag-and-drop handler exception.
Pressing the leftmost button in the upper right corner will definitely make a difference.
Regarding Rhino viewports: If you send string messages to the Rhino command line then Rhino will try to update the viewports at some point in time, but why not call the functions via RhinoCommon instead? And if rendering still occurs for some command, you can close all viewports but one and turn focus away from anything happening in the 3D space you are working on avoiding any (heavy) rendering to take place.
It should be easy to avoid any UI activity bringing it down to a level which is insignificant compared to what can be optimized in the code doing the actual work.
why not call the functions via RhinoCommon instead?
Can I do that when I talk to Rhino via the COM interface? I can certainly reference the DLL in my project, but when I bake a mesh in Grasshopper I only get back an object ID. The mesh itself will be in the Rhino process, and the RhinoCommon DLL in my process won’t be able to access that, I suppose (I’m not building a plugin).
If you mean to only use the DLL and not the COM interface, then that would be great! I found no docs on whether that’s possible, could you point me in a direction?
As to rendering costs and viewports: reducing the viewports and activity etc. will certainly speed things up, but if the server doesn’t have to render anything at all (no Rhino UI, no mesh, nothing) it will be significantly faster in my experience, so that’s what I’d like to try out.
Okay, but where do I get an ObjectTable from? Seems a lot of RhinoCommon examples revolve around a RhinoDoc, but I don’t have one such either with the COM interface. Is there a way to get one?
I have not tried using COM myself so I don’t know at what entry point you get access to the Rhino internals, but once you’re in, you should be able to follow the links in the class hierarchy. What have you tried? Isn’t there any intellisense hints in your editor, etc.
