GeoSharPlus: Cross-Platform C#↔C++ Geometry Bridge for Rhino/Grasshopper

[xliotx]

Hey Rhino community!

I’d like to introduce GeoSharPlus as a cross-platform alternative to RhinoCommon for handling general geometry types (points, meshes, arrays) when you need high-performance C++ processing in your Grasshopper plugins.

The Problem

RhinoCommon is great for NURBS, but when working with basic geometry types and needing C++ performance libraries (like libigl), the data exchange becomes a bottleneck. Plus, cross-platform support can be tricky.

The Solution

GeoSharPlus uses FlatBuffers for zero-copy serialization, making C# ↔ C++ geometry exchange blazingly fast and truly cross-platform (Windows & macOS).

Quick Example

// Convert Rhino geometry to efficient binary format
var points = GetInputPoints(); // List<Point3d>
byte[] buffer = GSP.Wrapper.ToPointArrayBuffer(points);

// Process in C++ (advanced algorithms, libigl, etc.)
GSP.NativeBridge.ProcessGeometry(buffer, buffer.Length, out IntPtr result, out int size);

// Get results back as Rhino geometry - zero parsing overhead!
var processed = GSP.Wrapper.FromPointArrayBuffer(GetResultBuffer(result, size));

Real Usage

Already powering:

• BeingAliveLanguage - A Grasshopper plugin to create computational diagrams for living systems
• IG-Mesh - An one-stop solution for mesh processing in Grasshopper (for Rhino

Why Use This?
Cross-platform - Same code, Windows & macOS
Zero-copy - No serialization penalties
No need for RhinoCommon (get rid of all platform-dependency and SDK)
C++ ecosystem - Access powerful geometry libraries
Open source - MIT license, full documentation

Perfect for plugin developers who need high-performance geometry processing without platform limitations!

GitHub: GitHub - xarthurx/GeoSharPlus: A Cross-Platform template for passing geometries around C++ / C# mixed code.

[Alebrew (Alessandro Ciafardone)]

Pretty cool (and a big fan of BAL, so glad this is involved there as well)

I have been pondering on the idea of meshing in the Raylib C library for a similar purpose in the past couple of weeks, will try to fiddle with this, and thanks a lot for sharing!

[xliotx]

Thanks!

Actually one of the main drive for developing this is because of BAL –

To my surprise, there’re so many students using macOS… and RhinoCommon currently doesn’t support macOS (not to say my experience with Rhino C++ SDK on Windows is also not good…)

Please try it out and submit issues if you need help.

[dale (Dale Fugier)]

@xliotx

and RhinoCommon currently doesn’t support macOS

Thus is an untrue statement. Care to clarify?

@xliotx

not to say my experience with Rhino C++ SDK on Windows is also not good

What isn’t good?

Thanks,

– Dale

[xliotx]

Thus is an untrue statement. Care to clarify?

My bad, I always mis-remember RhinoCommon as a C++ package. I wanted to refer to the issue that C++ sdk is not supported on macOS. See more discussion here:

RhinoCommon NuGet Package cannot load rhinocommon_c without Rhino Program

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?)

What isn’t good?

Quite some through out the years:

Rhino C++ SDK / OpenNurbs in Package Manager

For those of you who encounter this post and also need to develop cross-platform plugins that needs a c++ backend, please check my solution that is now open to the public: GeoSharPlus (Geometry C# C++) This is a Rhino-free library that can pass discrete geometry data between C# and C++. Examples of Rhino type wrapper has also been added as a demo.

Rhino 7 C++ SDK requires Visual Studio 2019

Hi @dale, I’m bumping this topic. Installing the Rhino 7 SDK still requires VS 2019, despite having MSVC v142 added to VS 2022: [image] [image] Is there a way of installing the SDK without VS 2019? Microsoft doesn’t provide VS 2019 installers anymore: [image]

Freetype263 issue

Thanks. I then suggest the open source version of openNURBS should be maintained in a more organized way. The doc is really inadquate.

Missing several data types in Rhino.Runtime.InteropWrapper

I started to explore the methods in Rhino.Runtime.InteropWrapper name space when trying to transfer complex data struct between Rhino and cpp. Little by little, I find that the wrapper is missing some basic methods from openNURBS. For instance, a SimpleArrayVector3d besides the SimpleArrayPoint3d (additional discussion below, though I think it is still needed) And SimpleArray3dex is missing, though there is a SimpleArray2dex. It seems the namespace is created without too much of tests and u…

(The logged 3-year-old issue is still open)

Add const variable types for the SetArray methods in ON_SimpleArray

template <class T> void ON_SimpleArray<T>::SetArray(T* p) { if ( m_a && m_a != p ) onfree(m_a); m_a = p; } The SetArray method for ON_SimpleArray is defined above. In general c++ practice, p should not be modified. It is fine though to be like this, but it will be very helpful to add an overload type of template <class T> void ON_SimpleArray<T>::SetArray(const T* p) I’m working with other cpp libs, such as Eigen, whose methods often return a const type pointer. The practice to conv…

If you want more, I can provide more.

But as an end-user, I feels I spent much more time in digging into the use of the API and ask here in the forum for using the SDK, rather than just read a clearly written and maintained documents for all the usages and examples.

It definitely help me in solving some issues throughout the time, but I finally decided to get rid of it in my pipeline, because time is expensive.

And from my own experience, it seems McNeel is also not actively maintain and updating the SDK based on user feedback (for instance, check the logged issue you did 3 years ago).

You seems also have no interest in joining into the modern C++ package management system (vcpkg, git submodule etc.), and need the user to manually install additional packages. Neither is it easy to automate the task with GitHub Actions.

I understand as a CAD software company, you have valid reason to make these decisions. And I’m not among the majority here and perhaps am one of the few that really doing something that needs the performance of C++ . But clearly the developers are not treated as a very important role in your ecosystem.

If you want to collect more feedback and improve the product, I’m happy to help.