Is there any documentation or write-up explaining in detail the different capabilities of the full Rhino Common library and the rhino3dm.py library?
I understand at a high-level the rhino3dm.py library is used for simple geometry tasks, and that Rhino.Compute is meant to be used for more complex tasks, but would like to understand what that division of tasks looks like. Is the github repo the only place where I can find the relevant methods: https://github.com/mcneel/rhino3dm/tree/master/src/bindings ?
And for background, I’ve used Rhino.Common (with the GHPython) for years, now, but am now looking for a geometry library that gives me the option of working outside of Rhino, with Cython.
I’ve considered the following:
- pyeuclid - pure python geometry library for 2d, 3d shapes. Not maintained recently, and is a bit slow
- shapely - python geometry library for 2d shapes. Maintained regularly, and faster than pyeuclid because it uses numpy under the hood
- sympy - can be used as a 2d, 3d geometry library, but I think it represents it’s numbers inefficiently so ends up being very slow
Right now I’m using shapely, and writing my own 3d geometry transformations using numpy when I need something in 3d, but want to test out rhino3dm as well.
I’m going to do the same for the python library which I hope won’t take too long.
The libraries are still pretty light on functionality since we just got started, but that tends to change fast. There are a couple ways to see what these libraries will be capable of.
- Look at the header files for OpenNURBS (https://github.com/mcneel/opennurbs). OpenNURBS is the C++ geometry toolkit that we’ve been continuously updating for 20+ years. This is the library that all of the
rhino3dm libraries run on top of. his may give you an idea of what will become available.
- Look at the old V5 RhinoCommon repository (https://github.com/mcneel/rhinocommon/tree/master/dotnet/opennurbs). This is V5 source code, so there will be new things in V6. All of the areas of code that ARE NOT inside of
#if RHINO_SDK blocks will eventually become available
Sweet thanks @stevebaer
(Same post author here, I just accidentally started this topic logged into our generic office account, and then was subsequently unable to delete the post).
Would you also mind explaining the conceptual difference between the OpenNURBS/rhino3dm geometry methods and the rest of the Rhino geometry library in rhino.compute and why these are split into two libraries?
For example, why can we manually define a mesh in rhino3dm using lists of vertices, faces, but can’t convert a surface into a mesh, (and presumably only do this in rhino.compute)?
There’s a lot of functionality in OpenNURBS that we are willing to give away for free and there is a lot of additional functionality in Rhino/Grasshopper that we charge for. That’s about as complicated as it gets.
The first version of the python API docs are now available at
Following up on @saeranv 's question, I just wanted to confirm that the plan is to not expose capabilities like meshing of breps (I see that those methods appear to be within
#if RHINO_SDK blocks of the C# API at the github links you posted).
I think both @saeranv and I have asked about those methods specifically since meshing functions are probably the most commonly-called Rhinocomon methods within all of Ladybug.
These functions will be available from compute.rhino3d through the compute_rhino3d python package available at
If you look at that web page, you’ll see a sample that uses both
compute_rhino3d to get meshes from a Brep.
FYI, I just published version 0.0.7 of
rhino3dm.py to PyPi and updated the API documentation pages to match. There are a ton of new functions in this version.
That is good to know that the compute-rhino3d web service will have a python interface.
Thanks for the clarification!