/f/92524/1200x630/dcc445470b/rhino-compute-shapediver-explained-cover.png)
Introduction
As 3D modeling and design become increasingly complex, many designers and engineers turn to cloud-based solutions to streamline their workflows and collaborate more effectively with colleagues, clients, and other stakeholders.
Such modern workflows are increasingly adopting parametric models, with Rhino and Grasshopper being particularly popular choices. These models embed logic directly into the CAD design, making it accessible via user-friendly parameters. When these models are shared online, it opens up fresh collaboration opportunities, speeding up design iterations and decision-making processes.
Two popular options for solving geometric operations remotely using Rhino and Grasshopper in the cloud are Rhino Compute and ShapeDiver. Many teams and companies relying on parametric design come to wonder which of these solutions is right for them, considering various factors such as costs, performance, security, and various key aspects they should consider during the implementation of their applications.
This blog article explores the differences between relying on Rhino Compute and ShapeDiver for your applications and help you determine which solution best fits your needs. We attempt here to give an exhaustive but high-level overview of the two solutions; in case you’d like to get into more technical details, we have prepared a separate article in our help center.
Whether you are a startup looking to create online configurators based on your Grasshopper files, or a company looking to share proprietary Grasshopper plugins and scripts with whole teams of designers, architects, and engineers, understanding the differences between these two approaches is essential to making informed decisions about your cloud-based workflow.
What is Rhino Compute?
Rhino Compute is a solution powered by McNeel’s Rhino.Inside technology, which essentially allows you to run Rhino and Grasshopper in headless mode, in other words, without a graphical user interface. It provides an API for geometry calculations using Rhino’s geometry library instead of launching a desktop application. This makes Rhino usable as a remote computation endpoint on a web server.
Rhino Compute can be configured to run locally for testing and development purposes. However, as a project eventually becomes more mature, users may need to deploy Rhino Compute in a production environment, for example, using a cloud service provider (AWS, Azure, Google Cloud, etc.).
This also means that users are responsible for managing their own cyber security measures, including setting up firewalls, securing data transfers and storage, and protecting their cloud resources against unauthorized access. While Rhino Compute provides guidance and resources for securing cloud infrastructure, the responsibility ultimately falls on the user to ensure their setup is secure. We will expand in a section below on some details of what is needed within such a setup.
What is ShapeDiver?
ShapeDiver, on the other hand, is a fully managed and secure cloud-based platform specifically designed for hosting and sharing parametric 3D models. With this solution, the infrastructure is completely taken care of, with not only a set of secure web servers (AWS), but also a load balancing mechanism and caching system: in other words, a powerful, secure backend ready for productive use.
Additionally, ShapeDiver provides a range of features such as an online platform for managing your Grasshopper library, a WebGL viewer, a set of well-documented APIs, and built-in security features, including SSL encryption, data backup and recovery, and access controls for managing user permissions.
Last, ShapeDiver also regularly updates its security protocols to ensure its platform remains secure against the latest threats.
Apples & Oranges: What are we comparing exactly?
As introduced in the above paragraphs, Rhino Compute and ShapeDiver are not equivalent and live in very different contexts: Rhino Compute is a technology, while ShapeDiver is a SaaS (Software as a Service). In some cases, Rhino Compute and ShapeDiver both provide an adequate way to implement cloud applications based on parametric design, but they are not really comparable at a fundamental level.
As a consequence, the comparisons we make in the following section of this article should be understood in the context of building an application. For each key aspect of a professional cloud application, we describe the following:
- On the one hand, which technical and practical challenges one must solve when using Rhino Compute to build a cloud application.
- On the other hand, in which way many of those challenges are already solved in the context of ShapeDiver, as part of the services included in the ShapeDiver SaaS platform.
Comparison Through 5 Common Use Cases
Let's explore some scenarios where Grasshopper definitions are solved in the cloud. For each, we'll outline the key steps and considerations with Rhino Compute and see how they stack up against ShapeDiver's built-in features.
Case 1: Calling a single Rhino/Grasshopper functionality as part of a wider web application.
Remote solving a geometrical operation (or even a full Grasshopper definition) might not be the core of your project but rather a small link in a broader web application involving other technologies.
If such an application is meant to be used internally by your team, and if it is not meant for intensive usage (resulting in a few remote calls to Rhino/Grasshopper per day), the required infrastructure is limited. Still, there are a few things to consider, as we cover in the comparison table below: at the very minimum, your team will need to know how to set up and maintain a web server and provide a minimal level of security measures. Depending on the usage, some load balancing to ensure the performance of the setup might be needed as well.
Case 2: Self-contained Model-as-a-Service
Your targeted application might entirely rely on the expertise of your parametric design team and consist of a single Grasshopper file: a set of inputs (which might include file inputs) are processed and result in visualized geometry and possibly file exports as well, such as geometry to be further used in the team, technical drawings or presentation PDFs.
This is essentially the basic use case for ShapeDiver: upload a Grasshopper file, including some of the ShapeDiver plugin components, and get an autonomous 3d web application on the ShapeDiver platform, which you can share with your team and beyond in a secure manner.
To set this use case up with Rhino Compute, on top of the points mentioned for case 1 above, a 3d viewer to display results is necessary. Additionally, a secure infrastructure to control who can access the application and eventually export files from it will need to be in place.
Case 3: Building Online Product Configurators
There is a wide range of applications for product configurators, from internal tools with limited audiences to full-blown marketplaces. We distinguish between the 3 following categories:
3.1 Technical configurators, which are only used internally by a limited number of people in your team.
3.2 Public-facing configurator (e-Commerce, optioneering tool) based on one or a few Grasshopper definitions.
3.3 Marketplace including an ever-growing number of configurators and, therefore, new Grasshopper definitions over time.
The first category of configurators (3.1) is similar to case 2 above. However, with category 3.2, questions of availability and performance arise when many users need to access the application simultaneously. Your web server will likely need to be interfaced through a load-balancing mechanism and possibly a caching layer. In case 3.3, an entirely new set of issues will arise from the need to frequently update the set of parametric definitions as well as regularly upload and include new ones to the online system: such a system will involve an administration dashboard for the content creators in the team, similar to the ShapeDiver dashboard.
Case 4: Sharing Grasshopper Applications
The goal of a cloud application based on Grasshopper is not always the development of a web application. Storing and managing parametric definitions online is a good way to share functionalities with a team of architects, engineers, and designers who do not have any Grasshopper knowledge or a limited one. Such a setup helps eliminate insecure and cumbersome file exchanges in favor of a centralized system.
Grasshopper now includes the Hops component, which allows triggering computations of remote definitions, which can, for example, be stored in the cloud. One question (introduced with case 3.3 above) remains: how do the Grasshopper experts in your team securely and conveniently deploy, manage and update the definitions which are accessed throughout the team? Furthermore, how to control which members of the team have access to which tools, potentially including external partners and clients for periods of time?
Finally, how do team leads and managers track the usage of the tools in place in order to make further decisions? Depending on the usage and security requirements of the company, permission systems and tracking processes might need to be developed along with the core centralized Rhino Compute server storing and granting access to the Grasshopper definitions.
Case 5: Building a software service on top of Grasshopper definitions
Building a public online service that includes letting users upload, manage, update, and access their own Grasshopper files, is, of course, always possible using Rhino Compute. It involves all of the points mentioned in the cases above in the most critical way possible if the goal is to scale the service to many users and offer features up to industry standards. In such cases, the Rhino Compute interface ends up being a small part of a much larger infrastructure, answering questions of security, scalability, and performance.