RhinoCommon with native DLLs


#1

Hello

I need to integrate a custom renderer which is built as native c++ DLLs into Rhino5
Is there any drawbacks if I decide to use RhinoCommon? First of all, can I use managed C++ to interop with these native DLLs without problems?

We are thinking about it because it’s possible that we will need to support our custom renderer on Mac in the future.


(John Brock) #2

Moved to Rhino Developer category


(Steve Baer) #3

I think using RhinoCommon is a great way to go. @andy and @JohnM can help with any rendering SDK questions you may have during the process.

I would recommend NOT using managed C++ though for interop and instead write exported C functions that your C# plug-in can use through pinvokes. We can help with getting that process working smoothly also. Managed C++ does not exist on OSX, so your going to run into problems if you decide to port to Mac in the future. I also have found that having the clean divide between C# and C++ is really helpful for code separation and debugging.


#4

Thanks, but our renderer has C++ style export interface and as far as I know it’s almost impossible to use such DLLs with PInvoke in managed C++


(Nathan 'jesterKing' Letwory) #5

You should create a C API for your C++ DLL.

I’m currently in the progress of doing this for Cycles. It is written in C++, I have a C API in a separate DLL for it which I then wrap in C#.

With regards to the API, personally I’d hide render structs and classes behind opaque integer IDs. That makes the wrapping process much easier.

/Nathan


(Steve Baer) #6

That’s exactly what I was trying to recommend. This is what I do for the RhinoCommon SDK. The Rhino C++ SDK is really C++ (classes and all those non-C type things). There is a wrapper DLL named rhcommon_c which is a large collection of exported C functions which call into the lower level Rhino C++ SDK.


(Steve Baer) #7

Here’s some related posts that you may find helpful