You should use the Rhino C++ sdk if you’re using this inside grasshopper - don’t use the open source version of opennurbs! If you were to link the open source version, this wil overwrite rhino’s opennurbs symbols at runtime and open up a big can of worms, most likely leading to a crash or unreliable results.
Do not use the open source version of opennurbs inside of the Rhino process. You will crash Rhino.
I would recommend starting a rhino plug-in project and tearing out all of the plug-in command class files. The project will be set up to appropriately use the Rhino SDK as well as the correct version of opennurbs. You can examine these settings for the project and apply them to your existing C++ project or move all of your C++ files from your existing project into this new project.
If you have an existing DLL project, then you need to include the Rhino SDK headers and link with the Rhino SDK import libraries. Often times it’s easier to just generate a new DLL project from scratch, and than add your functionality to it.
The open source version of openNURBS is intended for 3rd party application developers to use to add Rhino 3dm file reading and writing to their applications. It is not for Rhino plug-in use. Rhino already provide a much more full-featured version of openNURBS.
Probably I haven’t explained myself clearly, my cpp part is only used for mesh processing, and don’t interact with Rhino – it is not a Rhino Plugin, but a mesh processing lib so that I can use all the mesh processing libraries available in the cpp community.
In this case, I only need the ON_Mesh and several other arrays to pass the data between Grasshopper ↔ RhinoCommon (middle project) ↔ cpp, managed code ↔ unmanaged code.
Since I’ve already started this project for a while, and I don’t need all those Rhino Plugin functionalities, I don’t want to restart from the wizard and move my code in – and it is not necessary.
And I never figured out how to simply use the OpenNURBS lib provided by Rhino SDK…
Since as mentioned by your team in another post that you don’t think providing such an approach is necessary:
I guess I’ll continue to use the open source version as it is the only working approach to me at the moment.
Well… Yes in a way.
At least I don’t transfer the mesh back, but only ON_arrays which is transferred to List<> in the middle project.
I don’t refuse to use Rhino SDK, but the current Plugin approach is too messy.
I do suggest at least the cpp part (parts that can be separated and independent) can be provided as a separate library, with a CMakeList.txt, and can be integrated by normal cpp projects.
If you already have a DLL, then add the Rhino SDK headers and link with the import libraries included with the SDK. Just keep in mind that the libs are release-only, as we don’t provide a debug version of Rhino.