I was hoping to just get confirmation of the status/roadmap of the various Rhino technologies, the below is just what I’ve gleaned from various wiki pages and I would appreciate any inaccuracies to be corrected.
Rhino.NET SDK - Deprecated as of Rhino 5, not included in Rhino 6
RhinoScript - Deprecated as at Rhino 5, vbscript engine will not be included in Rhino 6
RhinoCommon - Takes over from Rhino.NET, will be the only SDK interface available in Rhino 6 (scripting and plugin)
Python - Becomes the preferred scripting language in Rhino 5 via embedded IronPython runtime, is the only scripting language in 6
My workplace has a large script written in Rhinoscript that I’m starting to port over to Python, I just want to make sure that some of my reasons for doing this are correct.
I do plan on putting a roadmap together, but just haven’t found the time yet. Your assumptions are a bit inaccurate.
Rhino.NET SDK - This is supported in Rhino 5. It will be deprecated and partially functional in Rhino 6. We will hopefully end the life span of this SDK in Rhino 6
RhinoScript - We will continue to support this in Rhino 6. Note this will only work on Windows and will NOT work on OSX
RhinoCommon - This is the preferred SDK for .NET development and will continue to be improved in V6
Python - Preferred scripting language in Rhino only because it is supported on both Windows and OSX and that it has access to all of the functionality of RhinoCommon and Grasshopper. RhinoScript is still a good choice for existing scripts.
I got the impression that RhinoCommon was not available for RhinoScript, and as such RhinoScript’s lifetime was tied to that of Rhino.NET (i.e. ends at version 6)?
It scares me when I hear guys like this talk about a software that I rely on for my productivity say things like it may be ‘deprecating’. Please tell me it isn’t so!
For the FULL roadmap, the C++ SDK and OpenNurbs toolkits (both the standalone and C++ toolkit versions) should be discussed. Is the ultimate objective for RhinoCommon (hopefully sooner rather than later) to offer 100% of the capabilities of the C++ SDK?
Oops, that was my reply under a different account I’ve been testing some new features out in discourse and didn’t realize I was logged in as that account.
mollifyingly uppercased… …just been curious if this misinformation about having it not included in V6 really is on the Wiki somewhere. I´m looking forward for new functionality of both scripting languages.
We are constantly adding more functionality to all of our SDKs (with the exception of the older Rhino.NET). RhinoCommon already has CreateRollingBallFillet functions on the Surface class.
Hi Steve,
yes, but what about a way to automatically run FilletEdge on ‘selected’ edges ?
OK, edges cannot be pre-selected, but I think in RhinoCommon we could identify BrepEdge’s some way.
Or a way to do that (scripting FilletEdge) already exists and I simply don’t kwon about it ?
Thanks