<<With over 400 plugins available, the Rhinoceros 3D and Grasshopper community has plenty to choose from to get their work done. From AEC to Furniture makers, there’s definitely something for everyone. But can these plugins be used in online platforms like ShapeDiver as easily as they can be used locally in your machine? >>

There’s no denying that one of the biggest advantages of the Rhinoceros 3D ecosystem is its community of users and developers. Additionally, Food4Rhino has proven to be an invaluable resource when it comes to finding useful plugins for almost any type of industry.

Since ShapeDiver is a cloud platform for publishing and sharing Grasshopper files online, it’s only obvious that many of our users rely on third-party (or even custom) plugins to efficiently do their work.

In this article we will explain why there are some instances where we can not support a third party plugin and others where we can. Additionally, if you are a plugin developer, we’ll explain how you can make sure your plugin is “ShapeDiver Ready” so it can be supported without any problems. Let’s dive in!

How ShapeDiver Works

The ShapeDiver platform works using ‘headless’ cloud instances of Grasshopper running on AWS servers. In order to ensure that there are no security issues, errors or unexpected behaviour, we must be careful in selecting the plugins we allow on the platform.

We currently support over 20 (and counting) third party plugins including:

• Karamba 3D

• Pufferfish

• Kangaroo 2

• OpenNest

• Rooster

• Squid

• GeometryGym

We're constantly adding new plugins so make sure you follow us on social media to learn when we add new ones to our ever-growing list.

Click HERE to check out the full list of supported third-party plugins.

Do's & Don'ts

Plugins that allow interoperability with 3rd party software, network functionality, export/import tools, file system access, etc. cannot be supported out of the box for this reason. Nonetheless, we may allow some of these plugins after a thorough reviewing process, resulting in a list of disallowed components.

Recursive plugins like Hoopsnake or Anemone are not currently supported, as API client applications like the ShapeDiver 3D Viewer are not provided with dedicated Grasshopper instances, so the data from previous computations will not necessarily carry forward to the current solution.

UI-dependent plugins such as Human UI or MeerkatGIS cannot be (fully) supported either, as the Grasshopper interface is not exposed to the users in any way while running on the cloud.

Did You Know..?
Our Enterprise accounts, which provide dedicated/private servers, allow more flexibility for the deployment of plugins, even custom ones!

If the plugin is a collection of UserObjects, it is already supported by the ShapeDiver platform, as long as the contents of each included cluster are supported as well. C#, VB and ghPython script will need to be reviewed on upload.

When a plugin is ‘supported’ on the ShapeDiver platform, a copy of all the plugin files (.gha, .dll and any other required files) will be kept on all of ShapeDiver’s cloud instances running Grasshopper.

For any uploaded script, it is first checked for compatibility. Learn more about this process here. During this process, if any component is found to belong to an unsupported library / library version or to a list of disallowed components, the script will not be accepted and an error mentioning the problematic component will be shown to the user.

For Grasshopper Developers:

If you'd like us to support your plugin, make sure you pay attention to these points below:

• If you are updating your plugin, please pay attention to backwards compatibility - Especially the component GUIDs: 

• • If you are updating a component, ensure that it’s Input/Output parameters, GUID and general function do not change.

  • If changes to those are required, please make the older version ‘Obsolete’ or ‘Hidden’ and create a new component with a different GUID.

  • Do not remove components entirely, as any scripts created with older versions will not work.

  • If you must make a change that may break backward compatibility, please discuss with us before continuing to do so.

• If there are a lot of major changes required, simply change the library’s GUID in the GH_AssemblyInfo inheriting class. This will ensure that the newer version can be loaded along with the older version.

• 
  The following JSON snippet is an example of how a typical plugin would be added to the allowed libraries list on the ShapeDiver platform:

{
  "AllowedLibraries": [
    {
      "Id": "08bdcae0-d034-48dd-a145-24a2fcf3d4ff",
      "Name": "MyPlugin",
      "Author": "MyName",
      "MinVersion": "0.1.0.5",
      "MaxVersion": "3.5.2.0",
      "DisallowedComponents": [
        {
          "Id": "0eb20130-8ee6-4b24-8a5a-163c68c0f31a",
          "Name": "Android UDP listener"
        },
        {
          "Id": "196fc676-6935-4443-bfe6-9c0c3fbddf04",
          "Name": "Quick Baker"
        },
        {
          "Id": "46f0586c-9cde-4dd9-a8f2-6797716ec2ea",
          "Name": "Camera Position"
        }
      ]
    }
  ]
}

General Guidelines For Developing

• The plugin must support at least Grasshopper/Rhino SDK version 6.17. To ensure wider use of your plugin, we recommend supporting version 6.12 and above. To control this, simply add the Grasshopper NuGet Package of the desired minimum version to your project.

• Ensure that you override the Version string property with a formatted version number (eg. “1.2.0.5” or “1.14.0”) in the class that inherits from GH_AssemblyInfo. We recommend overriding the AssemblyVersion string with the same value. Remember to increment these version strings every time before you release a new version of your plugin.

• Avoid the need to bake geometry or reference baked geometry from the Rhino document. Any referenced geometry should be internalized.

• Avoid using Rhino-specific functions such as Camera pose, Viewport capture, etc.

• If your plugin depends on data from previous computations for the current computation (i.e. recursive computations), unfortunately it will not work as expected on ShapeDiver and hence cannot be supported. For each recomputation request from a ShapeDiver web interface, a new cloud instance of Grasshopper may be assigned. To learn more about how ShapeDiver runs Grasshopper instances on the cloud, check out this blog post.

• Avoid any network interactions, unless absolutely necessary. Any network interactions (eg. license checks) will have to be reviewed in-depth by ShapeDiver.

• Avoid any file system interactions in components by default. If necessary, you may use the following methods:

• • If you wish to save a file locally, make sure you add a button for it in the right-click menu of the component. Do not create components that save files locally at every recompute.

  • If you need to open a local file, add an item in the right-click menu and internalise the file data in a serialised variable. Check out the Grasshopper SDK Documentation to learn how to do this.

  • Alternatively, you can create a custom Parameter and Data type for internalizing the file data. For an example, check out ShapeDiver’s Bitmap Parameter and PDF Document Parameter. Check out the Grasshopper SDK Documentation to learn how to create custom data types and parameters.

• File system interactions must be reviewed in-depth by ShapeDiver.

• Automated forced recomputation of components or the solution cannot be allowed on the ShapeDiver platform.

• Any use of System Information (MAC Address, IP Address, etc) must be reviewed in-depth by ShapeDiver.

Additional Notes

• Feel free to use custom Component Attributes to improve your plugin’s UI. This does not have any effect on ShapeDiver.

• If you are adding right-click menu entries or windows/dialogs for UI or input purposes, keep in mind that these will only be accessible to users running your model locally and not on the ShapeDiver platform.

• If you still wish to add components that do not meet the requirements to run on ShapeDiver, we can selectively forbid components from the plugin, so that users may use them on their local systems but cannot upload scripts using them to ShapeDiver.

• If you wish to integrate your plugin with ShapeDiver functionality (such as Bitmap/PDF parameters, ShapeDiver Materials or API), feel free to reach out to us for assistance.

Bottom Line

There’s no doubt that we want to make ShapeDiver a very flexible platform, and giving our users the ability of using almost any plugin they want is part of this goal. But as mentioned above, there are some limitations that are hard to overcome. Having said that, we are open to support any developer who wants his or her plugin supported on our platform. Simply let us know via our Forum so our developers can get in touch with you!

<< Would you like your plugin to be supported on ShapeDiver? Make sure to contact us via our Forum and let us know! >>