ShapeDiver <-> Rhino Compute

Often we receive questions like these:

Can I use Rhino Compute instead of ShapeDiver?
What is the difference between ShapeDiver and Rhino Compute?
Does ShapeDiver make use of Rhino Compute?

In this article, we provide a technical comparison between ShapeDiver and Rhino Compute. For a high-level comparison, please refer to this blog post.

The ecosystem around Rhino and Grasshopper is constantly evolving, and we strive to keep this article up-to-date and want to provide a transparent overview. Should you find any inaccuracies or have comments, please don’t hesitate to let us know. You can also contact us via the forum or write directly to alex at shapediver.com.

What are we comparing exactly?

In the following paragraphs, we introduce both Rhino Compute and ShapeDiver, and go through the pros and cons of using either of these solutions to solve real-life use cases. It is important to note, however, that Rhino Compute is a technology, while ShapeDiver is a SaaS (Software as a Service). Hence, most of the differences between the two are consequences of this fundamental distinction.

What is Rhino Compute?

Rhino is a powerful CAD software package. Most of Rhino’s functionality is available via SDKs like RhinoCommon, which allows applications to be built on top of Rhino. Since the release of Rhino 7, it has been possible to run Rhino within other 64-bit Windows applications using a technology called Rhino.Inside. An example of this is Rhino.Inside.Revit. Rhino.Inside also makes it possible to run Rhino headless, i.e., without a user interface.

Rhino Compute is an open-source project based on Rhino.Inside, which exposes the RhinoCommon SDK as a stateless REST API. In other words, Rhino Compute is an open-source web server that can perform geometry calculations using Rhino’s geometry library. Besides exposing this low-level core functionality of Rhino, Rhino Compute also allows calculating Grasshopper definitions and manipulating Rhino 3DM and other file types. Here you can find a complete list of features of Rhino Compute.

Examples of what you can do using Rhino Compute:

You can run Rhino Compute on your local computer.
For example, this allows you to start working with the Hops component in Grasshopper. Hops allows you to “outsource” parts of your Grasshopper definition to Rhino Compute. You can think of this like Grasshopper cluster objects that are solved remotely.
Note: Running Rhino Compute on your local computer uses your local Rhino license.
You can deploy Rhino Compute to a server, e.g. to an instance of AWS EC2. This uses Microsoft’s Internet Information Services web server (aka IIS).
For example, you can choose an EC2 instance type having lots of virtual CPUs and memory and parallelize computationally expensive geometry processing operations.
Note: Rhino Compute on Windows Server-based operating systems is licensed using Core-Hour billing.
You can develop applications that call Rhino Compute.
For example, you can remotely solve Grasshopper definitions or run complex geometric operations like mesh booleans, quad re-meshing, and mesh decimation, to name just a few. This is possible using any programming language that allows you to call REST APIs, but you will get a headstart when using Python, JavaScript, or .NET.
You can extend the functionality of Rhino Compute by implementing custom endpoints.
For example, you can develop an endpoint that executes a sequence of geometric operations and returns the final result. You can think of this like a hard-coded Grasshopper definition.

Rhino Compute Server

Documentation: https://developer.rhino3d.com/guides/compute/

Source code: https://github.com/mcneel/compute.rhino3d

Rhino Compute AppServer

Source code: https://github.com/mcneel/compute.rhino3d.appserver

This proof-of-concept web application written in node.js using the express framework bridges client applications and Rhino Compute servers. It allows the client applications to remotely solve Grasshopper definitions hosted on the server running the web application without exposing those Grasshopper definitions to the client applications.

What is ShapeDiver?

In a nutshell, ShapeDiver is a SaaS (software as a service) solution that allows you to upload and host Grasshopper definitions, expose them on a REST API called the Geometry Backend API, and build web and cloud applications on top of them. ShapeDiver’s mission is to deliver the most secure, reliable, scalable, and performant infrastructure for running Grasshopper in the cloud.

The ShapeDiver platform allows you to upload and manage models, securely share access to them in various ways, and plug them into desktop clients like Rhino, Adobe Illustrator, or Grasshopper. Models can be embedded into websites using iframes or our 3D viewer (in fact, any 3D viewer that can consume glTF can be used). They can be accessed from backend applications directly on the API or using one of the SDKs for JavaScript/TypeScript or .NET.

ShapeDiver’s Geometry Backend API significantly differs from the API that Rhino Compute exposes. It abstracts the concept of a parametric model and is independent of Rhino and Grasshopper. You can read about all the details and concepts behind this API in the Understanding the Geometry Backend API section.

Note that the Geometry Backend API is incompatible with Rhino Compute’s API, although building such an API layer on top of ShapeDiver would be possible. The reasons for this difference are:

The first version of the ShapeDiver Geometry Backend API was designed and developed during the first months of 2016, roughly 2 years before Rhino Compute was announced.
It was designed to provide an abstract representation of parametric models and to prioritize security, reliability, scalability, and performance.

You might ask whether ShapeDiver makes use of Rhino Compute. The short answer is no. The reasons for this will become apparent when reading the documentation on our Geometry Backend systems and the comparison table below.

Comparison Table

Below we have included a table that compares various aspects of Rhino Compute and ShapeDiver.

	Rhino Compute	ShapeDiver
Grasshopper plugins	Whether running Rhino Compute locally or on a server, when remotely solving Grasshopper definitions, you can use the plugins you deployed. Rhino Compute allows to run any available Grasshopper plugins, with the following caveats: Some plugins don’t work well (or don’t work at all) when running headless. Some plugins pose security risks. Commercial plugins like Karamba or GeometryGym IFC require a separate license when running in the cloud.	We manage a curated list of supported plugins for our shared systems. Our process addresses the issues that can happen in the context of Rhino Compute: ShapeDiver runs Rhino with UI, which means plugins that do not support headless Rhino still work. We only allow plugins developed with coding practices and functionalities that do not pose security threats. Selected commercial plugins like Karamba and GeometryGym IFC are fully configured and available as add-ons. Additionally, we provide fully automated deployment pipelines for custom plugins of Enterprise customers with access to a dedicated Geometry Backend system. Caveats: Further plugins need to pass a reviewing process before they can be deployed (flip side of the coin that come with high security standards).
Load balancing	Providing a load balancing mechanism for Rhino Compute is the responsibility of the application. We emphasize below some important details and advice to face the load balancing challenge. When running Rhino Compute using IIS, multiple child processes get spawned that serve requests, typically in a simple round-robin manner. This provides a minimum level of load balancing without redundancy and scalability above the limited capacity of a single web server instance. For public-facing web applications, we highly recommend configuring an auto-scaling group for the web server instances and putting them behind an application load balancer. This also is a requirement for continuous deployments. See separate item below. A CDN in front of your load balancer should be considered as a further optimization. Caveats: The setup using Rhino Compute directly behind a load balancer does not solve issues related to rate limiting, caching, long-running requests, and in general the danger of maxing out your web servers. Similar products exist for cloud providers other than AWS.	ShapeDiver uses a load-balancing algorithm made explicitly for the application of running parametric models in the cloud. In a nutshell, this algorithm decouples the client applications sending requests from the instances of Rhino and Grasshopper fulfilling these requests. You can imagine this like a billboard that mediates the communication between the client applications and the Rhino/Grasshopper workers fleet. This allows to address various challenges that arise with the use of parametric models for cloud applications, which can’t be solved using round-robin or other simple scheduling algorithms: Rate limiting and prioritization of requests Caching of results on a fine-grained level Fluctuating resource usage of models like computation time and memory usage Fault tolerance ShapeDiver runs on AWS and uses auto-scaling groups, application load balancers, CDNs, in-memory Redis caches, NoSQL databases, object storage, etc. These components are configured to be fully redundant and managed as infrastructure-as-code.
Rate limiting	Imagine requests are coming from two client applications. The first one sends computation requests for a relatively simple Grasshopper definition that computes quickly. The second one sends requests for a model which needs much more resources. How can you prevent requests from the second client to slow down or even prevent the processing of requests from the first client? Unfortunately, it is impossible to reliably solve this and related issues when running the parametric models on the same instances that serve the HTTP requests due to the strong coupling this creates.	The billboard load-balancing algorithm allows imposing rate limits at different levels. They may apply to individual models, user accounts, or groups. Rate limits may be based on resource usage like computation time, account priority, type of client application, etc. The load-balancing algorithm also provides the metrics required for auto-scaling the fleet of Rhino/Grasshopper workers while minimizing their cost. Rate limits are communicated to the requesting clients via HTTP’s standard mechanism for this, the 429 status code and Retry-After header. Our SDKs transparently handle rate limiting, simplifying the implementation of client applications.
Caching	Rhino Compute comes with an in-memory cache. As an example, calls for solving a Grasshopper definition with given input data are cached using a cache key computed based on the Grasshopper definition and the input data. The in-memory cache is limited by design to a single instance of Rhino Compute. When running multiple instances of Rhino Compute behind a load balancer, the cache will only be hit if the request by chance, arrives at the same instance. In case Rhino Compute gets restarted, as an example due to the deployment of an update, the cached data is gone.	ShapeDiver uses a multi-tiered caching system, based on in-memory Redis caches, NoSQL databases, and object storage. The information in this caching system is accessible independent of individual instances, and survives deployments and restarts. Input and output data are cached individually, broken down into metadata and binary data. The caching system also considers the computational graph of the parametric models. When a client requests the computation results of a model for given input data, the response might be split into an immediate response containing partial results that are already cached and a final result once the computation of the remaining results is finished. This allows client applications to immediately start the download of cached partial results, resulting in significant performance gains. All resulting assets are delivered via CDNs.
Maximum computation time	Rhino Compute does not impose a limit on the computation time used for processing the request. This provides flexibility but can also cause trouble related to load balancing.	ShapeDiver imposes a maximum computation time depending on the type of account of the user owning the model. This allows us to ensure the availability of shared systems. Dedicated Geometry Backend system are available to Enterprise customers, which allows them to increase the maximum computation time limit.
Long running requests	Computation requests which require very long computation time may interfere with network communication timeouts or instability. Imagine a client application requests the computation of a model which takes a few minutes to compute, and shortly before the computation ends the HTTP connection breaks. The computation results would be lost in this case.	ShapeDiver’s load-balancing and caching system decouples the API communication from the computations in Rhino and Grasshopper. Computations will be completed and results will be cached even if the network connection of the client application breaks. The API and SDK allows to send separate requests which file a computation, check for the computation results, and download them.
License cost	Running Rhino Compute on your local computer uses your local Rhino license. Rhino Compute on Windows Server-based operating systems, which is used for cloud applications, is licensed using Core-Hour billing. Example: Imagine you are running Rhino Compute on AWS EC2. You use an auto-scaling group with two instances, to ensure a minimum level of redundancy. The instance type you choose is t3.small, providing 2GB of RAM, and one or two virtual CPUs (configurable). For this example we choose one virtual CPU, resulting in two cores in total. The application is available 24x7. Core-hour billing cost for 30 days: USD 144 EC2 cost for 30 days, roughly: USD 15 to 30* * depends on region and reservation	Subscriptions are available from EUR 49 per month. Please see pricing.
Access control	Providing an access control mechanism for Rhino Compute is the responsibility of the application. We emphasize below some important details and advice to face the access control challenge. Rhino Compute allows to configure an API key, which serves as the shared secret between client applications and the Rhino Compute server. This isn’t a problem per se because the compute server does not host sensitive data. (Note: When solving Grasshopper definitions, the definition is part of the request to the Rhino Compute server, it doesn’t get stored there. This may lead to issues related to cyber security.) Sharing a single secret with multiple client applications can quickly become problematic. Considerations related to the Rhino Compute AppServer, which is a proof-of-concept example: When using Rhino Compute AppServer, the secret needs to be shared between the AppServer and the Compute server. AppServer does not include a mechanism for access control out of the box, this needs to be implemented depending on the application’s requirements.	Models running on Geometry Backend systems are protected by an authorization mechanism using JWTs and so-called tickets (API keys) which allow fine-grained access control. The authorization requirements can be configured individually for each model according to the requirements of the application. The ShapeDiver Platform acts as the authority that provides JWTs for models on Geometry Backend systems based on the user’s authorization level. Access to models can be shared with individual users and organizations, made available for public access for website embedding, etc. If a customer uses a dedicated Geometry Backend system, we can provide access to a JWT generator that provides total flexibility.
Continuous deployments	Continuous deployments can be set up when using an auto-scaling group and application load balancer. This requires in-depth know-how of AWS, or another cloud provider.	ShapeDiver uses continuous deployments for rolling out any kind of update. We warrant a yearly uptime of 98% for our shared Geometry Backend systems, while practically we have achieved an uptime of >99.9% in the past two years. SLAs are available to our Enterprise customers.
Cyber security	Providing cyber security measures for Rhino Compute is the responsibility of the application. Typical weaknesses and pitfalls of a system architecture such as one based on Rhino Compute and Rhino Compute AppServer need to be addressed as part of the implementation of your application.	We have built solid processes for managing information security and data privacy. We are in the process of preparing for an ISO 27001 certification.
Scripted components	It is the responsibility of the user to decide how to handle scripted components. Note that scripted components in Grasshopper definitions can be severe issue for cyber security and provide a perfect attack vector. Currently, Rhino Compute does not provide a mechanism to protect the server from related threats.	ShapeDiver reviews scripts before the Grasshopper models containing them are allowed to execute. Scripts that have previously been accepted or denied will be immediately accepted or denied upon subsequent model uploads, speeding up the process for users.
Remote computations from within Grasshopper	Please see Hops.	ShapeDiver ships a Grasshopper client plugin since version 1.15 of the ShapeDiver plugin, which allows remote computations of models, working with saved states, etc.
APIs and SDKs	SDKs for calling Rhino Compute from Python, JavaScript, or .NET are available.	SDKs for using ShapeDiver using JavaScript/TypeScript and .NET are available.

Conclusion

When building web and cloud applications driven by Grasshopper definitions, Rhino Compute is a great starting point if you want to build and manage the infrastructure yourself, while ShapeDiver provides a service that solves most of the complexities involved out of the box.

Should you find any inaccuracies or have comments about this article, please don’t hesitate to let us know. You can also contact us via the ShapeDiver forum or write directly to alex at shapediver.com. Please post questions related to Rhino Compute in the Rhino Compute forum.

Adobe and Illustrator are either registered trademarks or trademarks of Adobe in the United States and/or other countries.

Autodesk and Revit are registered trademarks or trademarks of Autodesk, Inc., and/or its subsidiaries and/or affiliates in the USA and/or other countries.

Rhinoceros, Rhino, Grasshopper, RhinoCompute, and RhinoInside are registered trademarks of Robert McNeel & Associates.