Convert Rhino-Grasshopper system into a stand-alone C++ CLI application

I have a CAD system written in Rhino-Grasshopper. It takes as input a CSV file, where each line contains a sequence of 20 numerical parameter values. The CAD system then uses these values to perform a sequence of 10 folds on a single sheet of paper. Upon each fold, the CAD system outputs an STL surface representation file and a DXF point cloud representation file. It is slow and impossible to use from the command line in pipeline with other programs that generate its input and use its output. I would like to convert it to a stand-alone C++ CLI application.

$ /path/to/cad --input_file=/path/to/input.csv --output_dir=/path/to/output

Is it possible to do this? Are there toolkits available for doing this? Perhaps you might suggest another approach.

Thanks,
Andrew

Rhino + Grasshopper definitions can be fired up and executed from the commandline.

Your main problem seems to be the bad performance (CLI is no problem) and that can be dealt with using script components or compiled components (with Visual Studio) in GH. C# has good support for parallel execution (if the task lends it self to be processed in parallel) to speed things up.

You can also write a Rhino plugin directly in C# (no Grasshopper involved) which then can be run from CommandLine by starting Rhino and specifying the command (your plugin) to be run.

C# will be easier to handle than C++ if you have no prior experience with C++ since there’s an Application Interface (API) called RhinoCommon which exposes to C# everything you need to control Rhino.

Depending on the “level” of processing needed, if you for example can do your processing using inbuilt Rhino commands and functions, then you would probably not gain any better performance using C++ than you can get with C#, unless you are a super super pro reinventing (and enhancing) the funtionality which the McNeel developers already provide via the RhinoCommon API.

// Rolf

Thank you, Rolf! It’s good to know I can operate Rhino+GH from the command line. Is there a tutorial or other documentation you recommend for learning how to do this?

My first priority is to use the CLI to operate my CAD system. My second priority is improving its performance.

I found this documentation for the C/C++ SDK for building Rhino plugins:

Thanks,
Andrew

if you make a simple text file you can start the whole thing from a script which looks something like the following (this PowerShell script was copied direcly from a project on my harddisk which starts a GH definition which in turn starts a bunch of other GH definitions)

..\project\run_workflow.ps1 

with content. Here’s how to start both Rhino an any GH definition of your choice:

[System.Diagnostics.Process]::Start("Rhino.exe", "/nosplash /Grasshopper run\\0000_Main.gh").WaitForExit()
Write-Host "Rhino.exe has terminated."

That’s it. Start run_workflow.ps1 from the commandline and the whole thing will start, run and terminate as you would expect.

// Rolf

[Edit: Spelling]

Here’s also a guide for making Rhino plugins using C#:

// Rolf

Is there general documentation for how to do this? The most relevant page I found was this:

For example, suppose the Grasshopper file I want to run is C:\path\to\foo.gh, then would the script become the following?

[System.Diagnostics.Process]::Start("Rhino.exe", "/nosplash /Grasshopper run\\C:\path\to\foo.gh").WaitForExit() Write-Host "Rhino.exe has terminated."

I’ve tried this and variants. Rhino starts up, but does not fire up Grasshopper, let alone run the specified Grasshopper file. I appreciate your help.

Thanks,
Andrew

Perhaps another way to address my problem, though not necessarily the performance aspect, would be to rewrite my system in pure Python outside of Rhino.

Could this be done by way of a Rhino compute service?

The code at the McNeel GitHub looks promising, but most of the examples are simple compared to what I need to do.

Thanks,
Andrew

Not that I know of. @pascal perhaps knows, so lets ping him.

Remove “run\\” from “run\\C:\path\to\foo.gh”.

I my case I had a subfolder called “run” just below the file with this script, so “run” is the folder in which I stored the grasshopper definition. :slight_smile: Sorry, now I see how confusing that must appear…

// Rolf

Let’s back up to the original problem before we make up solutions. What is slow? Is you Grasshopper definition slow or is there something else that is slow?

Hi Steve. There are two aspects to my problem that have different priority. Priority one: how can I operate my Grasshopper program from the command line? Priority two: how can I speed it up?

It seems Rolf has been able to fully address priority one. For priority two, I was considering at first recoding the entire Grasshopper system in C++, C#, or pure Python, though pure Python may not be much faster than Rhino+GH. Hence, I asked if any toolkits exist for replicating or interfacing with Rhino+GH functions.

Now to your question. My code performs a sequence of 10 folds on a piece of paper and performs geometric integrity checks along the way. Then it bakes the successively folded forms into Rhino and saves them as STL and DXF file representations. The whole sequence takes ~6 seconds. I’d like to get it under 1 second. I don’t want to take this thread in the direction of diagnosing particular inefficiencies in my Grasshopper code, but rather, address the question of whether the entire Grasshopper code base can be recoded as C++, C#, or Python.

Thanks,
Andrew

Rolf, presumably the “\” characters are escaped inside the quotes, requiring them to be “\\”. Yes?

Yes, try that. At least that was how I did it.

It can, both inside Grasshopper (one single component if you really stretch it) or with a Rhino plugin without any grasshopper involved. There are guides for both (and in GH you can script C# or Python directly in script components).

// Rolf

This is exactly where I would put effort for recoding so maybe Rolf is better suited to help.

@stevebaer: I certainly appreciate the value of focusing on code detail to improve efficiency, so I’ll likely ping you on a future thread to open up that discussion. Thank you!