I’m using a C# console program to quickly test some functions related to mesh.
I installed the nuget package of RhinoCommon:
But when creating Rhino.Geometry.Mesh object, I got an error:
Is it intentionally done or a bug?
Fairly sure that’s intentional. For RhinoCommon you need Rhino installed and licensed.
From Rhino - What is RhinoCommon? " RhinoCommon is the core .NET assembly that plugins reference in order to interact with Rhino." So you will need Rhino 
You might be wanting to work with OpenNurbs with which you can use to read/write Rhino files without Rhino installed. Rhino - openNURBS and rhino3dm Guides
1 Like
Thanks. That make sense.
Though for simple geometries, like Point3d etc, it works fine.
openNURBS doesn’t support cross-platform auto-pipeline.
What I’m actually trying to work on is a replacement of that lib on some geometries that I use.
The annoying part is for testing my C# ↔ Cpp code, every time opening Rhino to debug is a very tedious and annoying process… especially when you try to work on low-level memory manipulation…
What is an auto-pipeline?
Not sure where you get that from, the rhino3dm.net package is built for MacOS, Linux and Windows (NuGet Gallery | Rhino3dm 8.17.0), it is very much cross-platform.
Welcome to my day-to-day work.
By auto-pipeline, I mean installing OpenNurbs into my own project as well as Rhino SDK for cpp on macOS can be automated.
This is very important for things like Github action script so that developers can release plugins with cross-platform support.
For now, after asking in several post on this forum, I can conclude:
- OpenNurbs will not be included in ay package manager system (
vckpgfor instance) in the near future, at least before Rhino 9. - Rhino C++ SDK is not available for macOS.
Right, in this topic you asked about RhinoCommon, which is .NET. So I’m not sure whether you now are creating a plug-in based on .NET or a plug-in based on the Rhino C++ SDK.
Adding OpenNURBS to your project isn’t too hard, including having it compile on several platforms. OpenNURBS is cross-platform, as it compiles on Windows, MacOS and Linux. If you use CMake to set up your project it should be straight forward to include OpenNURBS and have it compile as part of your project, since the source code comes with a CMakeLists.txt. This works fine with GitHub actions. You could just make the OpenNURBS git repository a submodule to your project. Note though that OpenNURBS is just the file reading and writing part, it is not the full Rhino SDK.
Perhaps you could explain in more detail what you’re trying to do, so that we can give better info to you.
I’m developing several GH plugins that will need to use P/Invoke to call the function from cpp side (due to performance reason and library availability).
And even with OpenNurbs, I can only support Windows, as there’s no C++ SDK for macOS.
So I’ve developed a custom lib for this purpose (will open-source later), using flatbuffers for the bridge.
For discrete geometries, this works pretty well and I don’t need to deal with the cpp SDK, which have some issues, including VS linting and type hinting (due to some legacy issue from that SDK).
Additionally, there’s no need to maintain and compile code on two different platforms – all can be done from github action.
Suggestion:
As McNeel now step into the macOS side, unifying the developing tools and embrace the Github Action pipeline is very important to developers.
Frankly speaking, the experience in this aspect is not very pleasing…
For your day-to-day work, do you see there’s some space in improving productivity?
For instance, I tried to use C# console application for unit-test with basic geometries (Point3d, Polyline, etc.), all works well.
I can then test some functions very fast, without opening Rhino/GH every time.
(I know there’s that hot-load functionality in VS, but with unmanaged code from cpp, that is not possible).
But when dealing with mesh class, the rhino_c.dll cannot be used.
As you’re charging for the Rhino software, keeping that compiled lib closed seems to be a kind of an over-protected solution, IMHO.
MacOS has been supported already for years, for plug-in development via RhinoCommon. Or did you mean the Rhino C++ SDK.
I integrate Cycles into Rhino to power Raytraced (since Rhino 6) and Rhino Render (since Rhino 7). Cycles itself is C++, the integration plug-in RhinoCycles is C#.
You can use GitHub actions to build for all supported platforms. For instance our rhino3dm, which is our wrapper around OpenNURBS for Python (rhino3dm · PyPI), Javascript (rhino3dm - npm) and .NET (NuGet Gallery | Rhino3dm 8.17.0) is fully built using GitHub actions for all the platforms you can see, and for multiple versions - the version/language/OS matrix is quite large.
You should have a look at GitHub - mcneel/Rhino.Testing: NUnit dotnet unit testing for Rhino3D to set up testing to run within Rhino. You can refer to Automated testing with Rhino ✅ to find out how to do that with GitHub actions as well, including using Rhino in a GitHub action.
As mentioned before, RhinoCommon requires Rhino to run properly. See the previous paragraph with link to post to set up unit testing in GitHub actions so that you can use and test RhinoCommon.
See the earlier paragraph on setting up testing in GitHub actions.
Thanks for the thorough reply.
The Testing Lib you mentioned helps a lot.
Regarding the first part:
Simply put: I need a simple solution to pass Rhino Geometry from the GH environment to the cpp side, do some processing of the geometry there, and pass some geometry back.
For this, unless I miss something, cannot be done easily and universally for both Windows and macOS platform. (If using McNeel’s solution, this need C++ SDK for macOS?)
I pass geometry (mesh) and other data (shaders, images, etc) data from C# to C++ on both Windows and MacOS with the same code.
I indeed had to write a small C API to sit between C# and C++ so I can do P/Invoke and set up C# classes , but it works just fine for both platforms. For Rhino 9 most of the C API, P/Invoke and C# side is automated, all generated automatically from the C++ of Cycles. I’m using a tool I built using the clang Python bindings to parse the C++ code and harvest all necessary data from which I build the C API, the P/Invoke and the C# stuff. And that all works just fine on both Windows and MacOS.
I assume the C++ code you mention is all written by yourself - you should be able to set up the P/Invoke for that just fine. You can also automate the creation of the layers between C# and C++ yourself.
I’m using P/Invoke for sure.
The issue before is for complex geometries (especially for meshes), this process is kind of painful, and I later moved to Rhino C++ SDK which contains some OpenNurbs wrappers.
Then the problem of this post comes, as there’s no C++ SDK on the Mac side.
Then the solution I have now comes to the end finally. (Using flatbuffers to replace the Rhino wrapper)
flatbuffers looks like a neat solution indeed.
1 Like