I’m trying to get RhinoCommon running from an external ironpython interpreter. My process so far has been to add the following lines to the top of my python script to specify path directories for the modules:
import clr, sys
sys.path.append(r"C:\Program Files (x86)\Rhinoceros 5\System")
sys.path.append(r"C:\Program Files (x86)\Rhinoceros 5\Plug-ins\IronPython")
clr.AddReference ("RhinoPythonHost.dll") # Had to add this because scriptcontext was complaining that RhinoPython.Host was missing
sys.path.append(r"C:\Program Files (x86)\Rhinoceros 5\Plug-ins\IronPython\Lib")
This has allowed ironpython to find RhinoCommon successfully and the following command executes as expected:
circle = Rhino.Geometry.Circle(Rhino.Geometry.Point3d(0,0,0),5)
However, to write this to the active document, I’m having trouble getting scriptcontext to succeed. For example, running the following yields:
It’s finding the module since:
<module 'scriptcontext' from 'C:\Users\Nic\AppData\Roaming\McNeel\Rhinoceros\5.0\Plug-ins\IronPython (814d908a-e25c-493d-97e9-ee3861957f49)\settings\lib\scriptcontext.py'>
So perhaps, there’s some other dll I’m missing that isn’t allowing the scriptcontext to link to the Rhino.RhinoDoc object?
I’m writing an automation tool that pulls data from a database and then iterates over the content to generate a model and save an STL. Ultimately, I’d like to be able to execute the python script in an automated way, e.g., new data comes into the DB and triggers the generation to start without user input. It’s a little trickier if I need to open Rhino, launch the python editor and click run. I understand that I’ll need the Rhino app open for this to work, but this isn’t necessarily a problem since I can launch it from a shell script if I need to.
@stevebaer any details as to why this strategy isn’t possible? It feels so close, but perhaps the internals of the rhinopython .NET libraries are too heavily tied to dependencies in the Rhino app? Is there any roadmap to utilize RhinoCommon without the Rhino app in the future? I don’t necessarily need to render each iteration, as I’m only looking to generate the model and export an STL as my end product. Without the app, the export function would also need to be accessible natively through RhinoCommon. It doesn’t look like the openNurbs project supports everything that RhinoCommon does (sweeps, lofts, boolean ops, etc.) but correct me if I’m wrong.
In the new world of custom-everything and scalable 3d printing, you’d be leading the way with a well built SDK and massive geometry library. My fingers are crossed. Until then, it looks like I’ll have to settle for ActiveX.
That is correct and is exactly why you need Rhino running in order to get access to these advanced functions. We place a lot of value on these pieces of functionality and want to ensure that people have actually purchased Rhino in order to get them.
This would probably require meshing of Breps which we also place a lot of value on and don’t give away for free in the Rhino3dmIo toolkit.
Thanks for the feedback. I fully support having to purchase Rhino for it’s utility and I believe that most are happy to do so if it provides the geometric tools you need (of course it does). I will play around with the ActiveX automation and see if it provides an alternative solution to python fully linking to the RhinoCommon libraries from an external interpreter.