I’ve been handed a several years old codebase for a few Rhino plugins that I have been told is compatible for Rhino 5 (maybe 5.5 actually). Looking through the files, I see some Visual Studio projects, some C# files and some C++ files. No Python. I’m not sure what the exact functionalities are yet, but they support energy modeling, so I assume there is plenty of marshaling of 3D data and computations behind the scenes, and not highlighting and tool support for modelers. The plugins are used internally, not commercial or posted in the community.
I need to get the plugins up and running and use them for a project. We still have licenses for 5.5, but we are also using 6 on several other projects, and licensing going forward will all be 6. Ideally, we should port them to 6, so they are still usable in the near future. I have a few months part-time to dedicate to this project.
Is the transition from 5 to 6, from an API standpoint, pretty grand? Or not a huge deal?
Are there any transition guides, or “Rhino 6 programming for the Rhino 5 programmer” articles, or lessons learned during porting? Things to look into?
Given my experience w/ the Rhino API (none), should I attempt it, or just keep them in 5 and use them?
As for my experience:
I have never touched a single Rhino API
I have however coded plugins for Maya and 3D Studio Max decade(s) ago, so I am familiar with scene graphs, DAG, graphics APIs and necessary math, etc.
Plenty of development experience in various languages
I have used Rhino and Grasshopper on a few projects as a user (not a developer), so familiar with the product and basics
I’m interested in any advice you all have, especially if someone has gone through the transition from a developer standpoint.
In my experience (C# using RhinoCommon) it’s as difficult as changing the dll’s for the compiler, but I guess there might be some things that are incompatible. The problem is when Grasshopper 2.0 is integrated into a Rhino release as from what I’ve been told the IGH_Goo interface (and DataTrees?) would be completely replaced with something else, but for Rhino 6/5 I guess (if I am wrong please correct me) there shouldn’t be so many differences.
If the C# code using RhinoCommon, then that should just run in Rhino 6.
The C++ code, on the other hand, might require more work if it makes any calls into the Rhino C/C++ SDK, as there were a number of changes made to the toollkit between Rhino 5 and 6.
Without any more details, this is about alll we can provide.
I did the HelloRhino plugin tutorial and had no issues. It seems so straightforward through the wizard lol
I finally got our existing engine completely built, as well as the Rhino plugin that I said worked in Rhino 5 previously. There were some minor code changes from Rhino.RhinoDoc.ActiveDoc.Layers.Find to Rhino.RhinoDoc.ActiveDoc.Layers.FindByFullPath.
Is there a log file or some more detailed logging I can enable that gives me a hint as to what I need to fix next? I don’t think it has anything to do with code changes, especially since nothing is loaded in the scene yet. I’m concerned its more fundamental than that like the x64 bit plugin trying to use x86 engine code or something…
Yea… something with our managed wrapper .dll not loading properly.
[PlugIn::Create] Start
plugin_name = Portal_Firefly_Test_Plugin
Looking for plug-in’s GuidAttribute
Exception thrown while creating Managed plug-in
Message = Exception has been thrown by the target of an invocation.
Inner exception message = Could not load file or assembly ‘CLI_Bridge, Version=1.0.7549.17277, Culture=neutral, PublicKeyToken=null’ or one of its dependencies. The system cannot find the file specified.
[PlugIn::Create] Finished
System.Exception: No PlugIn subclass found.
at Rhino.PlugIns.PlugIn.CreateFromAssembly(Assembly pluginAssembly, Boolean displayDebugInfo, Boolean useRhinoDotNet)
Unable to load RhinoPluginsCsharp.rhp plug-in: initialization failed.
Any suggestions?
I’m new to this code myself…
Do you think I have something configured wrong path, env var, or plugin registeration wise? Or is it just something incompatible with our .dll?
Yea, this time I did debug it from Visual Studio, in the sense that I hit F5 on the project and it did launch Rhino. But once in Rhino, I brought up the PluginManager and loaded the plugin, and nothing ever happend on the VS side. I thought it would pause execution if it barfed up an exception, but nothing happened. Admittedly, I didn’t set any break points, so I could just set one early on and see if it hits it, but I didn’t know if the linking/loading of the other dlls was happening before that or not…
Which brings me to my next point/problem…
Yes, CLI_Bridge is 32 bit, as is every other dll in the codebase that the plugin wrapped / communicated with…
Now I’m getting the sinking feeling of what the problem is… 32 bit dlls and 64 plugin are not compatible are they? Perhaps I was thinking that it would be ok because 32 bit processes can run on 64 bit OSes / hardware. But for dlls it’s not going to happen is it?
I think I read that Rhino 6 is 64 bit plugins only, right?
And this whole rather large codebase is 32 bit except for the plugin…
So the only reason this all worked under Rhino 5 is because the plugin was 32 bit previously?
Am I totally hosed here?
Do I have to make a choice between converting the whole codebase to 64 bit, or us running back on Rhino 5 (which thankfully we still have a license for), or is there some alternate less painful path?
Welp, it all builds for x64 now… and it’s all loading without blowing up… yet!
I suspect it was built for x64 at one time because so little had to change.
Either that, or there’s tons of subtle errors that I will now discover over time lol
I’ve been working in C#, Python, Java the last 7 years and literally haven’t touched a single C/C++ project in that time. This solution is 32 separate C++ libraries wrapped with 1 managed C++ library and a .NET Rhino plugin. It was last used in 2017 for previous research (some w/ Rhino 5), and now I’m making some modifications for new work this semester.
I guess if I run into subtle bugs, I could look into these types of things (hopefully not necessary):
