Simple way to integrate openNURBS into GH project

This problem has been hovering above me for a while.
I’m writing a GH plugin that needs integration of cpp for data processing.
I need to transfer RhinoCommon data structures, mainly Point3d, Mesh, etc. (basic types) and don’t want to use the Marshall approach.

So I decided to use the recommend PInvoke approach to bind managed/unmanaged code.

While all the tutorial recommended me to download Rhino SDK and start a Rhino plugin using the setup wizard, I don’t actually need a setup as complex as that – I just need to integrate some basic opennurbs types so that I can wrap Rhino object and send it to the cpp side.

I also tried to use the opennurbs_public repo from github, but simply using it as a library always create linking issues, like here: Freetype263 issue

Simply put, is there a way to simply use Rhino’s internal opennurbs as a library for this task? If yes, how?
I’ve created another post about this issue: Using openNURBS lib in a cpp/c# mixed Grasshopper Component - #10 by dale

But I never figure out the setup. Always missing this or that…


Grasshopper assemblies should use the version of openNURBS referenced by Grasshopper - the one that comes with Rhino.

Creating a Rhino-dependent DLL is very simple and, yes, involves using the Rhino SDK.

How to create a Rhino-dependent C++ DLL


GitHub - dalefugier/Moose: Demonstrates how to share a common library with both a C++ and a C# plug-in.

– Dale


I followed your post and got these error:

It seems all errors are related to opennurbs from the Rhino 7 SDK.

Well, I just realize that the build is successful, but Intellisense reports all those errors.

Sometimes Intellisense isn’t so…

I noticed someone experienced this before.

Unfortunately, it never did. Maybe clangd/LSP is the way forward, or maybe there is an issue with the order in which Intellisense parses the SDK headers.

1 Like

As this is the only lib/SDK I’ve used that have this issue, I would assume that there might be something non-conventional/non-standard inside the SDK…

It is indeed a bit annoying sometimes…