Hi,
In RhinoCommon I see that PointCloud is inherited from unmanaged C++ type Rhino.Runtime.CommonObject. Is it possible to cast .NET PointCloud object to pointer IntPtr and directly read in C++?
Use Runtime.Interop.NativeGeometryConstPointer. Check the API help for details
– Dale
Could you point me to the right API file?
Also what do I need to reference as C++ Rhino sdk? Before I was using C++ Plugin template, so I did not need to do anything for linking rhino library. But this time I would like to reference library files and headers myself since I am compiling dll PInvoke.
I really need your advice here, since I think it would speed my PInvoke workflow.
Can I just directly cast PointCloud to this type?
And is this pointer would look like ON_PointCloud* on C++? Or do I need to cast it too?
You get a IntPtr from this method, pass it to the C function that accepts ON_PointCloud*.
Thanks, the C# side compiles. But I have problems on C++ linking.
If I compile I get error, even if I add stdafx.h @dale showed in Moose example on github.
What I am missing? I am using 64bit application, so why it gives me this error about WIN32?
I added Rhino7SDK .lib files:
And headers:
Linking seems to work:
Here is the best way, I know of, to make a Rhino-dependent DLL:
Keep in mind that the project’s Debug build configuration really is a Release build that disables optimizations and generates debugging information. This is because we do not distribute debug version of the Rhino SDK libraries. Something to keep in mind when linking this project with other libraries.
– Dale
Note, there is a non-const version as well. You should carefully pick which version you need.
Thank you for a response.
Is there any way to explain how to reference Rhino C++ SDK from scratch in C++ DLL without starting from Rhino C++ DLL?
I added property sheet but this does not resolve the Win32 error.
@stevebaer thanks for the reference
I added this, I hope it is correct, since I do not have C++ part working yet:
IntPtr c0 = Rhino.Runtime.Interop.NativeGeometryNonConstPointer(PointCloudNET);
No, not that I know of. You’ll just need to open an example the samples mentioned here.
Rhino plug-ins define Win64:
– Dale
After this I also had to change to MFC,
but this give more errors. I guess I will try what you initially suggest by changing the initial Rhino plugin.
1 Like
I changed the initial Rhino Plugin and am able to pass pointclouds back and forth between Python script and C++ DLL using the serial number of the pointcloud. The details are in the listings of my scripts (Python and C++) here:
Not sure if this helps you as this is from a Rhino pointcloud in Python using Rhinocommon to a Rhino pointcloud in C++ using the C++ SDK. You want to go from a .NET pointcloud to C++. Could you do this by first transforming the .NET pointcloud to a Rhinocommon pointcloud in Python and then going to C++ land?
I like the combination of Python & C++ DLL because I can use all the rs.stuff and Rhinocommon in Python to interface with the user and create Eto Forms and then get the fantastic performance of parallel execution inside C++ to do the heavy lifting. Now I can work with 6.6GB pointclouds with 1/4 billion points in under 15 sec for import, combining and coloring which is a 7th heaven for me.
Regards,
Terry.
Hi,
Terry I saw your nice work with python bindings.
I already can pass PointCloud from Grasshopper to C++ and from C++ back to Grasshopper. I am doing this through PInvoke double arrays. It was really easy to set it up. But I noticed around 200-300 ms latency for 1 million points just because looping in C# is not fast even with multithreading.
Then I noticed that it is possible to avoid conversion PointCloud-double array-ON_PointCloud to only PointCoud-ON_PointCloud suggested by @stevebaer .
I thought it would be straight forward to reference rhino as a library to C++ dll project. But it seems the only way is to start from RhinoCppPlugin and change its parameters for Shared Library compilation as @dale suggested.
Did you also use Rhino CPP Plugin template ? From what I saw today it is hardly possible to reference RhinoSDK as a library, without using dll template.
You could run the C++ plug-in wizard to create a hello world plug-in and then examine the resulting vcxproj file in a text editor to see what is different with respect to your current DLL project.
Which C++ Wizard are you refering to?
Is it one of these two:
For CPP I could not understand the linking and custom property changes. Dale was saying that the only way is to use plugin project from start.
Do I miss some other more easy way to link Rhino C++?
Yes, the Rhino 7 Plug-In project you have selected in your image is what I was referring to. My suggestion is basically the same as Dale’s, but slightly different approach.
You can create a plug-in project and bring all of your current source into it
-or-
You can create a plug-in project and examine the contents of the vcproj to figure out what you need to change in your current project
Coming to this topic from other topics and saw the discussion.
Is there any plan to change this routine?
Usually people have their own cpp projects and at some point, they want to make it to Rhino.
By requiring start from the Rhino 7 Plugin-In project rather than adding Rhino7 SDK as a library is really a pain, especially when the cpp project is big and complex.
It would be really helpful that McNeel can make this process a bit easier, allowing using Rhino 7 SDK similar as other cpp libs. Using package manager like vcpkg or simply added within Visual Studio.
No, we have no plans to change the current C++ plug-in (DLL) architeture.
In order for your application to access the features of Rhino, it needs to be running in Rhino. Hence the requirement for a DLL.
The Rhino C++ SDK is not standalone - it requires Rhino. I’m assuming the other C++ libraries are just standalone.
Vcpkg doesn’t make any sense for the Rhino C++ SDK, as you don’t need to build it and it only works on Windows with Visual Studio.
Thanks,
– Dale