Rhino software architecture


#1

Hi,
I wonder if there any resources where somehow detail the internal architecture of Rhinoceros. I mean the layers system: openNURBS, RhinoCommon, RhinoScript, plugins, grasshopper, grasshopper add-ons… all.

If not, an expert could tell the layers to understand the whole software engineering globally? What exactly is the core? how the parts are relate?
This is something more than curiosity, I wanted to make a graphic explaining this as a didactic element for a course, if worthwhile.

Thanks!


How was/is Rhino created?
(Wim Dekeyser) #2

David Rutten (@DavidRutten) made a nice illustration for this that you can find both in the RhinoScript 101 and the Rhino Python Primer.

You can download the former from the following link:
http://www.rhino3d.com/download/rhino/5.0/rhinoscript101


#3

Thank you wim.
"Rhinoceros offers various ways of programmatic access. We’ve already met macros and scripts, but the plot thickens. Please invest a few moments of your life into looking at the diagram below, which you will never be asked to reproduce:

The above is a complete breakdown of all developer tools that Rhino has to offer. I’ll give you a brief introduction as to what this diagram actually represents and although that is not vital information for our primary goal here (“learning how to script” in case you were wondering), you might as well familiarize yourself with it so you have something to talk about on a first date.
At the very core of Rhino are the code libraries. These are essentially collections of procedures and objects which are used to make life easier for the programs that link to them. The most famous one is the openNURBS library which was developed by Robert McNeel & Associates but is competely open source and has been ported by 3rd party programmers to other operating systems such as Unix and Linux. OpenNURBS provides all the required file writing and reading methods as well the basic geometry library. Practically all the 3D applications that support the 3dm file format use the openNURBS library. These code libraries have no knowledge of Rhino at all, they are ‘upstream’ so to speak.
Rhino itself (the red blob) is tightly wrapped around these core libraries, it both implements and extends them. Apart from this obvious behaviour, Rhino also adds the possibility of plugins. Whereas most companies provide plugin support for 3rd party developers, McNeel has taken a rather exotic approach which elimates several big problems. The technical term for this approach is “eating your own dogfood” and it essentially boils down to McNeel programmers using the same tools as 3rd party programmers. Rather than adding code to Rhino itself, McNeel programmers prefer writing a plugin instead. For one, if they screw up the collateral damage is usually fairly minor. It also means that the SDK (Software Development Kit, that which is used to build plugins) is rigorously tested internally and there is no need to maintain and support a separate product. Unfortunately the result of this policy has made plugins so powerful that it is very easy for ill-informed programmers to crash Rhino. This is slightly less true for those developers that use the dotNET SDK to write plugins and it doesn’t apply at all to us, scripters. A common proverb in the software industry states that you can easily shoot yourself in the foot with programming, but you can take your whole leg off with C++. Scripters rarely have to deal with anymore more severe than a paper-cut.
The orange pimples on Rhino’s smooth surface are plugins. These days plugins can be written in C++ and all languages that support the DotNET framework (VB.NET, CSharp, Delphi, J#, IronPython etc. etc.). One of these plugins is the RhinoScript plugin and it implements and extends the basic Microsoft Visual Basic Scripting language at the front end, while tapping into all the core Rhino resources at the back end. Scripts thus gain access to Rhino, the core libraries and even other plugins through the RhinoScript plugin."

This, rigth? It’s a good one… but Troutlake? RMAMFCUI? how GH could implement on it? RhinoCommon existed at that time?


(Steve Baer) #4

Here’s another pretty high level image of the “stack” from a presentation I gave a couple years ago


(Wim Dekeyser) #5

All valid questions :smile:
I can only answer the Troutlake one - AFAIK, that’s the name of McNeel’s own 3D geometry kernel.


(David Rutten) #6

That’s a pretty old diagram, a newer one would include python and Eto at the very least, and also have some Win/Mac info.


#7

Thanks for the replies,

Does anyone could write in one or more columns the most important parts?

I do not need to have much detail, what I would like is to start teaching grasshopper from a point generalizing all Rhino software + plugins, mainly to make the difference between “modeling on the object” of plugins for rhino and “algorithmic modeling” of grasshopper. Above all these layers, rhino plugins end in direct interaction with the user, while gh has a different level of abstraction where the instructions are given.

What could I put on lower layers to explain to my students the software architecture?

Again, it does not take much detail, what I want is to open the mind to a deeper understanding of 3D modeling with Rhino.
Any information will help.


#8

In what way is the NURBS library ‘open’. Does this simply mean ‘open source’ or can be accessed by script editors? Why is the Troutlake library not ‘open’. Also roughly how many tool libraries are there in total and are they grouped together in the GUI menus?

Thanks


(David Rutten) #9

Yes, it is fully open source. You may download the source code for free and use it as you see fit. For further details, see the opennurbs main page.

Troutlake is not open because it is the result of a huge amount of investment and it forms the basis of our software, meaning it is integral to your business model (because we primarily do business by selling that software).

I don’t know how many external libraries we use, there’s quite a few by necessity, but we try to limit ourselves to only those libraries that do not require license renewal and that come with source code.


#10

Thanks.

Im trying to find out the way in which the software architecture might be ‘projected’ to the GUI and when might a user be evoking a function in a particular library. Are the options categorised in the Rhino GUI window specific to different tool libraries? ie do the options in the visibility toolbar (such as ‘show selected objects’) operate a function inside a particular library (the same for the rest of visibility options)? or another example, Boolean Tools. Or are they not categorised in the same way as the GUI. Could you perhaps give an example of a tool which is from the Troutlake library?


(David Rutten) #11

Maybe. Sort of depends on the specific UI you’re talking about. If we use an external library to write a specific file format, then the options we provide with the exporter probably mirror the options the library provides. For things like geometry creation/editing commands, the options tend to reflect the command code itself, TL being too low level to have meaningful options like this.

I can’t. Troutlake functionality is typically exposed via the Rhino SDK. Whenever you intersect surfaces, or fillet curves, or offset something, you end up using a whole bunch of Troutlake stuff, but you’d never know because it’s all abstracted by Rhino.


#12

I see.

So are the tool libraries for commands effectively just formulations of algorithms with parameters/options which can be set by the user(or defaults) and Rhino enables these tools or makes them ‘work’ on the relevant/specified piece of data?

Thanks


(David Rutten) #13

I’m not entirely certain what it is you’re asking, but I can tell you that we’re trying hard to remove as much functionality from Commands as possible. In earlier versions of Rhino command could be really complicated classes that did a lot of work behind the scenes. Because all this functionality was inside command classes, the only way for anyone to ‘get’ at it was to run the commands. Now we’re moving as much generic functionality into the public SDK as possible, so that plug-in developers and scripters can also access that stuff directly.

Ideally all Rhino commands would only be very thin wrapper classes that call into SDK functions while providing some nice UI for them. Whether these SDK functions are pure Rhino, or require OpenNURBS, or require TroutLake is not interesting to anyone except our SDK developers, because it all looks exactly the same from the outside.


#14

Sorry, I’m not making my self very clear. I want to find out more about the process of using a tool on existing geometry in Rhino. If I use ‘trim surface’ using an existing curve and surface in my document what happens behind the scene. Where is the data for the existing geometry? How does rhino call on a specific function in a library to operate on that piece of geometry?
Am I making sense? I am an architecture student writing a thesis on Rhino (mainly because its a program used throughout the industry yet not many people know much about the software beyond user level) I can find no writing about how software creates geometry/a model in Rhino. What is happening behind the GUI when I am building and editing model (in brief)?

Thank you, this is a big help. I will be referencing this conversation as primary research in the essay.


(David Rutten) #15

We’re rapidly approaching the limits of my own understanding here, I don’t write code in C++, either as a core developer or acting as a third-party developer.

Since TL, OpenNurbs and Rhino are all McNeel products, pumping data such as Curves from one to the other is fully under our control. We can set up the data structures in such a way that no needless copying or conversion need take place.

Whereas OpenNurbs can be best thought of as a geometry/object database, TL can be best thought of as a purely functional library. OpenNurbs handles things like layers, object names, properties, documents, 3dm (de)serialization, and so on, whereas if you want to measure the length of a curve you’d use TL*. Rhino combines the two and adds a bit of magic of its own to turn the whole bundle into a usable end product.

These kinds of nitty-gritty details are usually well beyond the interest of even plug-in developers. There are good reasons (I assume anyway, I’m not privy to them) for the way Rhino is put together, but it’s just implementation.

* Though always through Rhino as an intermediary.


#16

I feel I understand a lot more, thanks.

Who might be a good person at core development level to ask/contact?


(Steve Baer) #18

The core Rhino.Exe is the database that stores and manages all geometry during a session of Rhino. This geometry is defined using C++ classes written in OpenNURBS. Every module in the Rhino process (OpenNURBS, TL, Rhino, RhinoCommon, Grasshopper, …) has code that performs calculations on this geometry.


#19

Great thanks.

When you say the rhino process, is that the same as what Rhino is ‘doing’ when you use a tool? So Rhino effectively just invokes the correct commands or functions (using wrappers) from any of the libraries in the sequence required to achieve a specific task like ‘explode’?


(Steve Baer) #20