You’ll need to have the Rhino 7 WIP installed on Windows.
This allows you to embed and get access to RhinoCommon from inside of CPython.
You must be running a 64-bit version of Python
You can use either Python 2.7 or Python 3.7
import rhinoinside
rhinoinside.load()
import System
import Rhino
# for now, you need to explicitly use floating point
# numbers in Point3d constructor
pts = System.Collections.Generic.List[Rhino.Geometry.Point3d]()
pts.Add(Rhino.Geometry.Point3d(0.0,0.0,0.0))
pts.Add(Rhino.Geometry.Point3d(1.0,0.0,0.0))
pts.Add(Rhino.Geometry.Point3d(1.5,2.0,0.0))
crv = Rhino.Geometry.Curve.CreateInterpolatedCurve(pts,3)
print (crv.GetLength())
I’m following this with great interest.
Can you elaborate some more about how this compares to the current ironpython implementation?
Am I correct that this is unrelated to RhinoCommon in that rhinoinside is a different API with (still) limited methods and classes.
Or is that a misinterpretation?
We use IronPython to provide Python scripting within Rhino. Rhino.Inside is running Rhino inside other programs and in this case that program is written in CPython (i.e. the original Python implementation). The full RhinoCommon API is available because Rhino itself is running.
Any program using the Rhino.Inside technology will require you to be running on Windows and have Rhino WIP installed and licensed. If you want to use RhinoCommon without running Rhino (i.e. on a non-Windows platform) then you’ll want to check out rhino3dm. Rhino3dm’s API is limited but you can use Compute to fill in the gaps.
Nope, it is the RhinoCommon SDK exposed inside of CPython. To be honest, I just got this to work yesterday and haven’t really run it through any rigorous tests. Was just too excited to let it sit there and felt it needed to be “thrown over the wall”
This seems magical. Perhaps I am misreading something. What makes System and Rhino importable to CPython? Looked at init and just went further down the rabbit hole with the clr import.
I tried above in 3.6.4 and get exception:
Traceback (most recent call last):
File "...", line 9, in <module>
pts = System.Collections.List[Rhino.Geometry.Point3d]()
AttributeError: List
I tried with and without the pip --user option, not sure if that matters.
Yes, it is a little magical This library uses pythonnet to expose .NET to CPython (http://pythonnet.github.io/) plus Rhino 7’s “Rhino.Inside” feature to load Rhino into python’s process.
Very exciting!
Now I just need to persuade my company to upgrade to Rhino 6, give me installation priviledges for the WIP, invent a project combining geometry with data wrangling…
Should we consider this the beginning of the end of IronPython engine in Rhino?
Having mixed feelings because I am still getting comfortable using IronPython with RhinoCommon API. I feel it’s either going to become easier or more difficult to use the api docummentation.
This project embeds Rhino inside the python process. Our use of IronPython is to embed a python interpreter inside the Rhino process. Even if we added a different embedded python interpreter in Rhino, we still wouldn’t need to drop the IronPython engine.
The syntax be the same so there is nothing different to learn.
This is huge news! The Rhino/Python user/programmer dream to integrate the Cpython vibrant community packages inside the rhino vibrant community tools! By any chance, is there a plan to implemmet Rhino inside Freecad? As an open source project could this implementation be developed by an independent research team?
This should be possible at some point in the future. We are still trying to figure out some issues with Grasshopper running in a headless CPython environment.
@ffribeiro – from a quick look, it appears that FreeCAD has both a C++ and Python API, so it may well be possible to implement Rhino.Inside (but only for the 64-bit Windows version). We don’t have any plans to investigate this ourselves right now, but we have plenty of samples to provide any intrepid developer with some ideas and we’re always available to answer questions!