Killer Product — A Rhino3D Product Analysis

What makes Rhino3D a Killer Product? The first in a series of killer product teardowns

Darrel Ronald
Published in
25 min readApr 29, 2020


I ❤️ Rhino, but there’s more…

I’m a Rhino user since January 2003, Rhinoceros version 3 which was released November 2002. (Note: Rhino = Rhino3D = Rhinoceros.) It was an illegal crack since I was a student and had no money and my university didn’t have any licenses. Luckily it was a stable copy and I was able to produce all our Master’s Architecture work in Rhino as well as do 5 competitions on the side. Since then I’ve designed architecture, public spaces and urban design projects (many for construction) as well as for projects using computer aided manufacturing (CAM) and robotic machining.

I love Rhino… so much in fact that it has been my main 3D modelling software for over 17 years. Sure, I’ve had some years where I used it less than others (not by choice), but it has been a constant in my workflow since I’ve discovered it. I have taught over 100 people how to use Rhino and I’ve taught over 50 people to use Grasshopper, mostly to my university students and coworkers. I really should apply to get my certified trainer status. I have promoted Rhino use within all the offices I’ve collaborated with, leading to well over 100 licenses being purchased, so I no longer regret using an illegal copy!

Over the years I’ve used Rhino and Grasshopper across the offices I’ve worked in. To speed up my workflow, I use many Rhino and Grasshopper plugins, both paid and free. I have developed CAD Standards, project templates, and macros in RhinoScripts that have been implemented in multiple offices. I’ve developed around 175 custom Rhino alias shortcuts (open source on GitHub) that align with the fantastic Maxwan AutoCAD shortcuts (open source on GitHub). At my own firm, Open Form Architecture (2008–2012) we produced all design, visualization and construction documentation within Rhino and Grasshopper, including renderings and CAM work. At KCAP architects&planners (2013–2019) I founded and lead the computational design team and trained employees in Rhino and Grasshopper.

Somebody in the Rhino community should setup a database of tech stacks to see how we all use the software, plugins and workflows differently.

Going even further, in the past years I’ve spent much more time on programming (for both inside and outside the Rhino context), especially Python for general software programming and data science. Because of Rhino I’ve also had to learn some C# and object-oriented design. I’ve also spent time learning JavaScript for web applications to supplement my previous experience with HTML and CSS that goes back to 1996. I explain my developer experience below. The reason I started learning programming and product development is first, to build my tools and second, so that I can explore business and product ideas.

This leads to two important conclusions. First, computational design is now recognised as an intrinsic aspect of design creativity so that the mark of the accomplished designer is that he [sic] can move effortlessly between intuition and logic. Second, the distinction between the role of the professional software developer and the designer (as an end-user programmer) has been blurred. Now we can all create that final layer of scripting that represents our unique design logic, so that we can all say: ‘Before I design I will first build my tools.’

— Robert Aish in “First build your tools”, 2013

The logo for McNeel’s new Rhino Compute service, source: McNeel

What is the article about?

This article is an extension of my shift towards product leadership as explained here. What I want to discuss here is Rhino as a Product. I consider Rhino a killer product, a fantastic product that users love, even though it’s not perfect. I’m sure the Rhino Net Promoter Score is very high. In this article I want to look at the software from different perspectives: Market Offering, User Experience, User Community, Developer Experience and Platform Ecosystem. This article could be of interest to a number of readers: new or existing users wanting to know more about the product, managers needing business context for decision-making, developers considering joining the Rhino developer community, or other product developers looking at the AEC market. Some open questions I want to answer are:

  • Who is McNeel? What is Rhino? What products does it offer?
  • What role does it play in our lives, technically but also culturally?
  • Why do people love it? What are its pros and cons?
  • What are the user and developer experiences?
  • What is the market offering, licensing and pricing models?
  • Where is it headed and what could Rhino do next?

Note: I have no affiliation to McNeel and receive no compensation for this article; it is entirely my own initiative. I have made a request to McNeel for private information but have not yet received any.

Who is McNeel?

Not a lot of company information is explicitly written online, so I have pulled together different sources and interpreted data where necessary. I compare statistics from 2016 and 2019 where possible (making assumptions where needed). Robert McNeel & Associates started in 1980, and I believe that Robert McNeel developed custom plugins for software like AutoCAD beforehand. This evolved into further collaborations that in turn evolved into Rhino with its first release in 1993 as Sculptura and then released for the first time as Rhino version 1 in 1998.

McNeel is currently ~100 employees split between two private companies, Robert McNeel and Associates serving the Americas and Australia (~75 people, founded 1980) and McNeel Europe serving EMEA (~25 people, founded 1998). To get a perspective on size and impact on the AEC community: Dassault Systèmes has ~17.000 employees, Autodesk has ~12.000 employees, Trimble has ~6.000 employees and the Nemetschek Group has ~3.000 employees. Whereas these comparison companies are publicly traded, McNeel is privately owned which will have a large impact on the capacity for McNeel to grow.

In the latest company statistics presented at a shipbuilding conference in October 2019, there are currently 450.000 users worldwide, up from 350.000 users in 2016, which represents an average annual growth of 8.7%. (Likely this will include duplicate users that are using new emails for free trials.) This is good annual user growth for a product already 22 years old. McNeel also states that 10.000 schools use Rhino products and there are 100's of third party developers using the Rhino and Grasshopper platforms. There are currently over 500 Rhino and Grasshopper apps available on the Food4Rhino website which also has roughly 160.000 downloads/month and over 4 million downloads in total. McNeel states that Food4Rhino is experiencing exponential growth, but they don’t say for what metric. Since annual revenues are not publicly reported, I estimate that McNeel could have annual revenue for 2019 in excess of €20 million (details below).

Rhino serves diverse industries with a principle breakdown of: Design (Industrial and Furniture Design, Jewelry, Fashion and Footwear, Art); AEC (Architecture, Engineering and Construction, currently accounting for over 50% of new license purchases); naval and automotive design and manufacturing; as well as computer aided manufacturing (CAM) and robotic manufacturing.

McNeel writes that their mission is “To enrich its clients, employees, suppliers, community, and stockholders — in that order.” Their business strategy is to “Manage resources by focusing on client satisfaction.” Doing this they focus on three priorities: “ — deliver beyond client expectations; — continuously improve products, processes, people and client profitability; — innovate, providing creative solutions to old problems using new methods and technology.”

How does McNeel score against these ambitions?

In the following paragraphs I will assess how Rhino does or does not meet these goals. Clearly, McNeel is doing an incredible job with only 100 employees, but there are improvements that could be made in different areas, some of which are discussed below. As I user myself, I do feel that they care deeply about the community they serve, shown through their active interaction with users. In terms of product presentation and documentation, their online content strategy needs a radical overhaul. They also appear to be a good collaborator to their partners (distributors, trainers, developers); but I see missed opportunities in holding regular user/developer events. Importantly, for such a powerful software platform, the price is unbeatable, both for education and professional licenses as well as for generous upgrade pricing; they could be more aggressive in pricing. All of these points I discuss further in detail below.

Rhino3D interface with Python editor and Grasshopper interface
Rhino3D interface with the Python editor (left) and Grasshopper editor (right)

Product 1 — Rhino3D, the main McNeel product

Above you see the typical Rhino interface with its distinct 4 views, compact tools, properties tabs and the powerful command-line panel on the bottom that runs RhinoScript commands. If you’ve ever used AutoCAD, you see how Rhino in its early life took cues from the AutoCAD interface — this is something that I really love about Rhino, the ability to use a command line. Today it is so rare to have a command line but it is incredibly powerful! The two pop-up windows are the Python editor and Grasshopper editor interface.

Rhino offers advanced tooling with lots of possibilities, commands and operations, which often makes people nervous in the learning process, especially for architects that are used to SketchUp. In general, the software offers you a lot of workflow options since it isn’t designed for one industry or specific task. For this reason, some functionality is missing that would otherwise be common in other software; one example of this in architecture and urban design is the need to do shadow impact studies of a new building, which is necessary on a regular basis, but requires workarounds in Rhino. Rhino does offer data management linked to geometry, but it isn’t a BIM software; however you can use plugins or even Rhino.Inside for this.

Rhino is great for interoperability with other software, especially for architects. I often describe Rhino as a Swiss army knife for the AEC industry. Since I mostly do urban design projects, I regularly run into the weaknesses of Rhino in terms of working with geodata, but it’s not the prime market for Rhino. However, it will be extremely interesting to see how Rhino.Inside can adapt to ArcGIS and even better for QGIS. Interoperability with other AEC software is established and smooth, and still improving regularly.

Rhino offers fantastic accuracy which makes it great for detailed CAD/CAM, engineering, jewellery and boat design. Since it currently uses McNeel’s openNurbs and will introduce SubD surfaces in v7 (Subdivision surfaces are high-precision spline surfaces), it is also one of the best solutions for free form geometry design. There are great plugins for both Rhino and Grasshopper to prepare drawing sets and document CAM products. With Rhino v7 there will be improved sheet set management which was always a weakness of Rhino.

Rhino and Grasshopper has an incredible user community that is open and helpful. On the McNeel Discourse Forum you will find lots of great help. Before the new forums, the Grasshopper 3D website served the community for a number of years and is still a great archive of content. On Facebook there are many groups that share projects, scripts and helpful discussions.

Rhino and Grasshopper have a strong plugin ecosystem including geographic analysis, environmental analysis, BIM, manufacturing, robotics and especially visualization. Great geo-environmental plugins include Rhino Terrain (paid), Lands Design (paid) and Ladybug (free). Great CAM plugins include RhinoNest (paid), Open Nest (free), Elefront (free). Great BIM plugins include VisualArq (paid), Conveyor (paid), Tabl (free), Rhino.Inside for Revit (v7) and Konstru (paid). Great rendering, animation and AR/VR plugins include V-Ray, Maxwell, Twinmotion, Lumion and Enscape (all paid).

McNeel has not exploited the potential of the Rhino platform and there are lots of very interesting business models to prototype and implement.

Grasshopper3D definition screenshot
Screenshot of a Grasshopper definition

Product 2 — Grasshopper, the Killer Platform

Grasshopper is McNeel’s hit product that changed the course of design software in the AEC market. It is a pop-up application window from within Rhino that allows for non-destructive visual programming. It liberated many designers to start building parametric models without having to code themselves. It was hugely liberating for design creativity and exploration on top of being an incredible time-saver for employees around the world that could quickly and effortlessly explore design solutions. The impact that Grasshopper has had on design culture — within architecture especially — should not be underestimated. Notwithstanding, a lot of meaningless ‘parametric’ shit was designed over the years.

Visual programming is the gateway drug to textual programming.

Grasshopper emerged in late 2007 and evolved slowly ever since, with version 1 being released in spring 2014. We’re all still waiting excitedly for version 2, and almost nothing about it has been made public outside of some YouTube videos. Back in November 2013 David Rutten recounts some conclusions following a 4-week session at McNeel Seattle and the future of v2, it’s interesting reading and unfortunately many things are not implemented over 6 years later. In 2018 Scott Davidson of McNeel told me that there could be some breaking changes coming. I’m as curious (and as frustrated) as everyone else to see what will emerge from all these years of secrecy.

I think that the secrecy around Grasshopper v2 is the one major break of user trust in McNeel. It is a key source of frustration.

Grasshopper quickly grew into a large, active and open community of users that shared questions, answers and code samples on the Grasshopper3D social website (starting in 2009). Sadly this website is now closed and the Grasshopper community was redirected to both Food4Rhino (for plugin distribution) and McNeel Forums (for discussions). While Grasshopper3D outgrew its capabilities, I still find that Grasshopper needs a better ‘home’ to be represented online since the social exchange that was embedded in the previous social website has fallen away in the two new websites. In the meantime, a lot of users have moved to different Facebook Groups to have the same intimacy of dialogue and sharing of images, scripts and questions. McNeel keeps referencing the old and closed Grasshopper3D website, which just shows that they don’t yet have a good idea of how to replace it.

The community of design users has consistently outruns the speed of Grasshopper development. Many of the plugins created by users could have or should have been core components within Grasshopper itself. There is a lot of room to expand the core functionality of Grasshopper based upon the work of users.

From this active community, a sea of plugins emerged that added functionality to Grasshopper. So much so that Grasshopper has evolved into a very powerful platform for design tooling. It’s so important for the design community that other companies have tried to replicate its functionality, such as Dynamo for Revit (open source) and more recently Marionette for Vectorworks. Neither has reached the scale of Grasshopper.

But with all this embedded potential, McNeel has not exploited the business potential and development offerings from Grasshopper as a platform. Users and developers could use more support from McNeel to develop and monetize their plugins. One example is to improve the development process and packaging of scripts for distribution. Another example is to create a universal purchasing and license management tool so that plugins can be distributed while developers are rewarded for their work. Many developers would be better served by remuneration for their efforts, while it would simultaneously encourage developers to keep developing their plugins.


Food4Rhino is the (new) place to share Grasshopper plugins created by the community. While it is good for distribution of plugin releases, it isn’t good for discussions. There is an opportunity, not yet taken, for McNeel to introduce purchasing options to plugins and scripts, allowing creators to monetize their development work through an app store. Swarm has emerged from CoreLab at Thornton Tomasetti to fill some of this gap. Food4Rhino also doesn’t integrate automated plugin management, so that is where the new Yak package manager for Rhino v7comes in.


Yak is a new Package Manager for Rhino v7 WIP and makes it much easier to install Grasshopper plugins. You can see this as similar to other package managers like NuGet, NPM and PyPi. It confirms that Grasshopper really is a platform that requires its own distribution system. For example, if you work on a .gh file and don’t have the necessary plugins, it will help you download and install from the Rhino interface, without having to go to Food4Rhino. You can see it in action here.

Rhino.Inside Revit
Rhino.Inside Revit, source: Geometry Gym

Product 3 — Rhino.Inside, the new Parasitic Platform

The new product offerings from McNeel are really exciting and I group the different versions of them here as a new product offering. I think that a lot of the innovation comes from rethinking what the Rhino product could be as a standalone .dll file which can be run anywhere, literally: inside other software as a plugin, inside a JavaScript/WASM webpage, inside a console/terminal, insider a web server instance, and more. Many of these features are still WIP experiments, but hopefully on the path to production. With some services, such as Rhino Compute, McNeel openly seeks to understand what us users will do with it before a pricing model is set.

Rhino.Inside is a new type of computing platform that I call a parasitic computing platform. Rhino.Inside will hunt down other software and eat it from the inside. Why develop plugins for Autodesk, Nemetschek, Trimble or other software when you can develop one Rhino/Grasshopper plugin and run it everywhere?


Rhino.Inside is an open source project which allows Rhino and Grasshopper to run as a plugin within other software. It really is magical, but still a WIP which only works with the new Rhino v7 which is still a WIP. All users with a Rhino v6 license can use the beta version. What still needs to be done is prepare the Rhino and Grasshopper plugins to work with the other software API — see the ongoing builds in Github. The most advanced plugin is for Rhino.Inside Revit (see it in action). Other experiments include running Rhino natively within: AutoCAD, ArcGIS, Unity, Unreal Engine and JavaScript such as Node.js or Electron.

Rhino Compute

Rhino Compute is a new open source project from McNeel that allows you to run Rhino.Inside on a local server or in the McNeel Rhino Compute cloud. Essentially you can access Rhino and Grasshopper through a web API to run the program. Here is a getting started tutorial and read the Rhino Compute API Docs.

Rhino3dm running inside Electron, source: Luis Fraguada


Rhino3dm is another very interesting project which is a set of libraries using OpenNURBS with a RhinoCommon style. You can access Rhino3dm from within .NET, Python or JavaScript without using Rhino itself. You can link it to a Rhino Compute cloud service and you can read/write Rhino .3dm files.

I find the Rhino3dm.js library the most interesting which means you can run Rhino on Node.js, inside Electron and embed Rhino files into web interfaces. Samples and Docs.

Lesser-known Rhino Plugins

There are multiple lesser-known products from McNeel, most of which I’ve also never used in production. They are both current and legacy products, many of which I really wonder why McNeel doesn’t either kill the product or invest seriously.

The most interesting Rhino plugin is probably Bongo for doing animations. Rhino has begun to use the open source Cycles renderer, so it is possible that the below rendering plugins disappear following the development of the core functionality of Rhino. Since Rhino v6 many improvements were made to the visualization functionality which was always a weak spot of the software. Still though, most designers rely on 3rd party products/plugins such as VRay or Maxwell for still-image renderings. But a bigger transition in the AEC industry is towards creating immersive, animated and virtual reality renderings using Enscape, Lumion or Twinmotion or other products. For this functionality, McNeel cannot compete and should rather support workflow processes.


Bongo is an animation plugin for Rhino 5 and 6. It’s at version 2 and they just released version 3 as a very early WIP (work in progress). It should be available for Rhino v7 when released, but I haven’t confirmed. I think that this could be a core feature built into Rhino and Grasshopper.


Flamingo rendering plugin was ‘developed for designers’ and works with Rhino v5 and v6. The latest version is Flamingo nXt 5 (for Windows) released in December 2018. In the latest version they also integrated FlamingoRT which was a viewport renderer similar to Neon.


Brazil is another rendering plugin for ‘top CG artists and designers’. The latest release is Brazil v2 SR 4a from September 2018. I tested this once many years back but didn’t find it better than Maxwell render which we were using back then.


Neon is another rendering plugin for Rhino version 5. It is free and was developed to produce real-time raytraced in the Rhino viewport. I used it a few years back, it was okay. It’s basically deprecated.


Penguin is a non-photorealistic rendering plugin that produces sketch design. The latest release is Penguin version 2 SR 5 (Service Release) back in march 2018. I never needed to test it and Rhino 6 does include a similar sketch-style visualization if you need it.


The iRhino iOS app runs on both the iPhone and iPad and allows you to share Rhino .3dm files for viewing. I’ve also never used this service. I see that it is now free, but I think it used to cost money. The latest version 2.2.4 is from roughly 2 years ago (according to the iOS app store).


McNeel has a unique marketing strategy where their primary goal is continued connection with users, distributors and developers. They eschew advertising through paid channels and rather invest this money into diverse activities such as free technical support, competitive product pricing and active engagement with users. In addition, as a developer you can spend time for free at a McNeel office in order to have direct access to McNeel developers to assist with your own product development.

McNeel relies heavily on word-of-mouth advertising by dedicated users and they aim to embed McNeel products in universities which in turn leads to these students bringing McNeel products into the workplace. They hold Rhino events within their regional offices to support users, developers and trainers (especially Barcelona) and they hold the odd developer day in different cities with local partners (ex. London, Amsterdam, New York). McNeel staff sometimes participate in hackathons (ex. AEC Tech) as well as diverse industry conferences (ex. Acadia, SSI). They send out monthly newsletters and different people within McNeel are active on social media, especially Twitter. You can likewise subscribe to the active Rhino Blog which is McNeel official news feed.

Overall, the McNeel marketing strategy is one of continued two-way dialogue rather than one-way advertising. Marketing investments are made into user and developer support, periodic events and direct conversations through channels such as forums, social media and direct communication. McNeel relies upon users, distributors, trainers and developers to serve as advocates for the company and the Rhino platform. This also implies a high net promoter score.

Partners, Distributors and Developers

McNeel relies on a large network of partners for sales and training. McNeel states that they work with over “700 dealers, distributors, OEMs and training centers around the world”. Some resellers are highly involved in the Rhino community such as Simply Rhino in the UK. The only official software partnership that I know of is with Graphisoft Archicad. The partnership’s press release in 2015 highlights the new Rhino — Archicad Connection which is still alive and actively developed today.

McNeel also relies on third party developers to build on the Rhino, Grasshopper and Rhino.Inside platform. There are companies such as Asuni that have built VisualARQ and Lands Design to add entirely new layers of functionality to Rhino. (Note: Asuni is somehow part of the McNeel family). Likewise, many developers contribute free plugins to Grasshopper, well over 450 at this point. People like Mostapha Sadeghipour Roudsari from have had a major impact on the design community through their Rhino plugins, but originally did this out of their own efforts and costs. Ladybug has been downloaded close to 290.000 times from Food4Rhino. Another big supporter of Rhino and Grasshopper is Nathan Miller from Proving Ground whose Lunchbox plugin for Grasshopper has over 345.000 downloads from Food4Rhino. There are countless plugin developers who have made massive contributions to the design community, some of whom got their start in programming by developing grasshopper scripts, then going further to develop plugins. Together these 1.000s of people push Rhino further into their industries because they extend the tooling to meet specific unaddressed but shared needs.

Pricing and Promotions

In the product pricing table you see an overview of the McNeel pricing strategy. In essence, the pricing is very competitive and comes with free technical support and free service releases (regular updates) and there are no maintenance fees. In addition, all licenses are perpetual and floating, working with the Zoo or Zoo Cloud license server.

The McNeel pricing strategy is incredible with comparison to competitors.

Also important is that the McNeel products are not versioned every year, the major release cycle (ex. from version 5 to 6) took ~5 years. This means that your annual software costs are extremely low. This doesn’t mean that your software isn’t updated either since McNeel updates Rhino with regular Service Releases. For example, at the time of this article Rhino v6 has already received 24 service releases since it was first sold in February 2018 — an average of one service update per month.

A Full license costs €995 which is an incredible price for what you get. There are great upgrade promotions (ex. from v5 to v6) at a 50% discount. The Educational license costs 20% of the full license and are full functionality licenses without watermarks; they too are eligible for 50% discount upgrades.

McNeel Product Pricing 2020
McNeel Product Pricing 2020, source: author

AEC Software Pricing Comparison

I recently compiled an overview of per user, per year software cost comparisons in order to assess expensive cost leaks in the workflow and to aid with the decision of large strategic investments in IT infrastructure. Note that most AEC companies would have a similar set of financial decisions here. Rhino stands out as the absolute best value for investment of money, time and energy. The Software Costs table provides an overview of comparative costs; the latest data are for European customers in 2019.

The key takeaway is that Rhino is cheaper than every other major software used by a design office, even a typical video conferencing software! It is also shocking to see how Esri and Autodesk can exploit their positions in their respective markets.

Software pricing comparison, source: author
Typical AEC software pricing comparison using 2018/2019 prices, source: author

A note on the terminology and methodology of the above table:

  • First, these prices are actual costs paid by a typical AEC design office in Europe.
  • Prices are mostly 2019, but some from 2018 — but this is irrelevant.
  • Some prices include lots of different software, especially the Autodesk AEC and Adobe CC license costs, however in practice most of the software is unused by a firm.
  • Floating licenses are far superior than fixed licenses — if it is floating, any staff member can use the available license(s).
  • Licensing payment structures vary greatly per company. There can be any combination of: Initial Cost, Upgrade Cost, Maintenance Fees, Subscription Costs.
  • The costs above do not include additional Training or Technical Support if necessary, however most software include basic free training material online.
  • All costs are adjusted to the Upgrade Rate (see table) which is the number of years you can amortize the full cost of the software — example for Rhino is that you pay €995 every 5 years for a new version = annual cost of €199. In the case of Rhino, since the upgrade costs are very low, every time you upgrade, the annual per user per year costs drops in comparison to the others. So after 10 years, Rhino will cost only €149 per user per year.

McNeel Annual Revenues Estimate

Since McNeel is privately held, I can only estimate what their annual revenues are for 2019. I have requested information but have not yet received detailed internal information. There are so many factors at play here that a number of assumptions need to be made. Based on different inputs, the range of potential annual revenues is between €12 — €25 million (which is not accurate enough).

Based upon the user growth numbers which were publicly stated, I calculate this could amount to an annual turnover in excess of € 20 million per year based on 25.000 new users (33.000 new users minus 25% trials), split into different license categories (75% Full, 24% Student and 1% Student Lab) and small percentages (only 5%) that purchase addition Rhino plugins. This assumes that the 25.000 new users are not upgrading, which McNeel sells at a generous discount. Another factor ignored is what % of total sales are paid to the software selling distribution channels since McNeel relies heavily on roughly 500 external partners to sell McNeel products, this could reduce total McNeel revenues another 10–15%. Based on these other factors, you could also revise the annual revenues downwards, which would mean that the estimated annual revenues of ~€17 million. That would equate to a per employee revenue stream of roughly €170.000, based on 100 employees.

User Documentation & Learning Experience

The software UX is great, but where McNeel needs to really improve is the touch points for users across their web sites and how content is published to users and developers. There is so much non-standardized, scattered, out-of-date, incomplete documentation, resources and training material that it is really a mess of content and interface. There is really good content, but it can be very hard to find and difficult to re-find. In place of this messy reality, many users over the years have created fantastic learning material, but it is scattered all over the internet with often no links from McNeel. One of the most common questions and biggest frustrations for new users is how to navigate this mess and how to effectively learn the McNeel products.

To get a sense of the vast selection of often conflicting, duplicate or hidden touch points for McNeel products and user experience, this is a fairly comprehensive list. It seems great, but beware the maze you need to navigate to find what you’re looking for.

Developer Experience

It should be said that the McNeel staff are really first-class in their support, openness and willingness to help the user and developer community. I’ve only heard great things for other software developers, and have also had the chance to attend the Rhino Developer Day in Amsterdam 2018, meeting some of the core McNeel staff that I have seen online for many years. My first face-to-face experience with McNeel was at a workshop in Chicago for ACADIA 2009 Reform where David Rutten gave training for the then new Grasshopper3D interface.

One thing that is particularly confusing with Rhino3D is the many languages you can use to develop software and scripts within the Rhino and Grasshopper platform. Sadly each one has it’s pros, cons and trade-offs. To a new or non-programmer, you hit the first wall of difficulty or confusion learning about these technologies and where to start. But probably Rhino isn’t the only legacy software with this challenge.

  • C# — the main language for .NET and the cross-platform RhinoCommon API. It is the most useful for developing Rhino software but not the easiest to learn
  • IronPython — a .NET implementation limited to Python 2. RhinoPython has all the goodness of Python, plus you can execute within Rhino and Grasshopper
  • RhinoScript — the main language for the Rhino command line, Rhino macros and Grasshopper component. RhinoScript is based on Microsoft’s VB Script.
  • VB Script —executable in a Grasshopper3D component
  • JavaScript — new for use with the RhinoCompute service and Rhino3DM.js
  • C++ SDK — the language of the openNURBS created by McNeel and the Windows Rhino software and plugins

Once you start to digest these diverse entry points, you might hit a second wall. In particular, when learning Python for Rhino3D development, you will find another set of sub-choices for writing your scripts. Again, each one has it’s pros, cons and trade-offs. There are a set of main APIs that you should learn:

  1. RhinoCommon — the complete Rhino API for cross-platform development, but more difficult to use.
  2. RhinoScriptSyntax — an easy-to-use wrapper around some RhinoCommon API modules, however it doesn’t include all RhinoCommon modules.
  3. Scriptcontext —controls code execution in Grasshopper or Rhino. I still haven’t found an API reference or learning material online, but its role is important.
  4. NodeInCode — while not technically an API, it is the magical ability to call Grasshopper components from within Rhino or Grasshopper scripts.

In the McNeel training material online, there are many gaps of knowledge not discussed for non-programmers. This would be a very useful set of training material, or at least links to good resources. Some of the example topics, which a computer scientist would be well aware of are:

There are however very good discussions online on both the original (now closed) Grasshopper3D website as well as the newer McNeel Discourse forums. But sadly, some of the best forum posts/discussions that answer questions we all face don’t get extracted out into clear summary articles in the Rhino Developer Documents.

Further frustrating is that there are many different systems and locations for API documentation. Some API docs are found on Github Pages while others are found on ReadTheDocs. Worse is that some of these links, like Rhino Compute on ReadTheDocs isn’t linked from the official RhinoCompute page. This is a messy situation and a missed opportunity to support the Rhino Developer community with first-class documentation.

There are some very good resources from McNeel that discuss important topics, especially in mathematics and programming. Two documents by Rajaa Issa are great: (1) Essential Mathematics for Computational Design and (2) Essential Algorithms and Data Structures. Unfortunately, they are difficult to find and sometimes other documents like these are only available as PDF while some are on the Dev Doc Guides. A new PDF in this series by Rajaa, (3) Essential Guide to C# Scripting for Grasshopper is found on Food4Rhino instead of the Dev Doc Guides.

As part of my developer learning process, specifically for Python using RhinoCommon, RhinoScriptSyntax and RhinoScript, I dive into the many challenges that non-programmers face when starting to learn and develop scripts for the Rhino3D platform. I recently started a GitHub repository RhinoPythonScripts where I include scripts and tips that try to pull apart the confusing aspects of developing for Rhino.

The scripts start with utilities or learning scripts which show learning tips, gotchas or highlight things which are challenging or frustrating with regards to the entry points for coding within the Rhino3D platform. They sometimes pick apart the Rhino Developer Samples (fork on GitHub) in order to see what code is necessary, how it compares in the different methods of writing scripts.

Where can McNeel take the Rhino platform?

I have a lot of ideas where the Rhino products could or should develop towards, some of which are mentioned above. Maybe McNeel will ask me about these? Some ideas I will test and develop as plugins for Rhino and Grasshopper, perhaps even launch on Food4Rhino. Here are some important horizon 1 improvements that I believe could be made:

  • Radically improve the online presence: websites, user documentation, developer documentation, training, external resources and so forth.
  • Be much more transparent concerning the software development cycles, especially for Grasshopper which is so vital to all of our work. While we’re on it, why not prioritize the evolution of Grasshopper and speed up its development cycle?
  • Treat Grasshopper like the full platform it is: (1) create a universal purchasing system and licensing for plugins to support developers; (2) improve the developer documentation and process to simplify and speed up the creation of new plugins.
  • Create a new set of interactive interface components for developers to use to make better interfaces, from within both Rhino and Grasshopper.
  • Speed up the development of Rhino.Inside. It is the most interesting inverted Parasitic Computing Platform that I’ve seen in a really long time. But it was announced years ago and it seems that McNeel has relied too much on the developer community to develop out the use cases.
  • It would be amazing to get a version of Rhino.Inside where you can embed a complete Rhino interface within a WASM wrapper, to embed online or within Electron.

Wow, if you’ve made it until here, you’re a devoted Rhino user! I hope you have enjoyed this article and can share it with ❤️! Thanks!



Darrel Ronald

Founder of Spatiomatics. Creator of the SIMO App for Urban Development. Architect, Urban Designer, Technologist, Entrepreneur.