Rhino development tools provides the ability to customize and extend Rhino with direct access to its database structures, geometry, graphics system, and command definitions, and much more.
Rhino development tools are free, royalty free, and include free support!
Latest Activity: Dec 14, 2016
Rhino C++ SDK
The Rhino C++ Software Development Kit (SDK) provides C++ developers the tools needed to develop plug-ins for Rhino. Details...
RhinoCommon .NET SDK
The RhinoCommon .NET SDK allows you to customize and extend Rhino 5 using any .NET 4.0 language including Microsoft Visual C# and Visual Basic. Details...
Rhino .NET SDK
The Rhino .NET SDK allows you to customize and extend Rhino 4 and Rhino 5 using any .NET 2.0 language including Microsoft Visual C# and Visual Basic. Details...
Rhino Renderer Development Kit (RDK)
The Rhino RDK, included with the Rhino SDK is a collection of tools that extend the Rhino SDK with rendering specific capabilities, including material, environment and texture editors, a frame buffer, displacement mapping, procedural textures, and many rendering u/i widgets. Details...
Rhino Application Platform (RAP)
The Rhino Application Platform (RAP) provides the tools for developers to wrap their application around Rhino by creating a custom Skin. Details...
Questions and Answers
Ask questions on Stack Overflow using the tags rhino3d, grasshopper, opennurbs, and any other appropriate tags.
Don't have a specific question, but want to discuss things with us? Join the SDK Developer Support Forum.
Hello all, I recently was trying to select some parallel objects along all my document that were close to others.
So what I did was use a window selection, I zoomed in to make sure to select just the virtual rectangle my objects were in, then I zoomed out to be able to move faster across the document (as my objects are very far apart).
What happened is that the markee created changed width and possibly start point.
Anyone experiencing the same issue?
Thanks in advance.
Have an intern do nothing other than brew espresso and keep everyone juiced
the coffee they brew at mcneel is pretty good iirc.
so keeping well caffeinated is already happening there.
usertext records on the imported objects
A usertext field would most certainly be useful for many things. Very useful.
Problem here is that it would not solve the problem of "remembering" part/assemblies of different kinds (like Polysurfaces, Blocks nor Groups, same conceptual problem applies for all of them). As soon as you explode any of those, the irreversable happens - the parent is lost, and thus it's joined name, One can no longer answer the question which of the exploded parts or splinters should be considered the "parent"? (if one would like to re-join the parts/splinters again).
For this reason I imagine that you could not get away with anything less than creating an extra "ghost parent", or "pseudo parent" as I called it, before exploding Polysurfaces, Blocks or Groups, and set all the parts / splinters to point at that "ghost parent" as a last step in the Explode command. Then it would be possible to reconstruct any exploded parts/splinters back to it's former "joined name", provided that they are not joined into some other constellation (then the "ghost parent" would change on next explode, aso).
But a usertext field would really be useful for many dirty tricks by scripters. A field of unlimited size at that.
In v6 with picture material:
Or if you want to do a custom material, in advanced settings:
I don't know of such a way, so I added it to the list: