Hops version 9.0.0 is now available for Rhino 9

[AndyPayne]

Hops version 9.0.0 is now available for Rhino 9.

Hops and Rhino.Compute can now process any Grasshopper data type, including Model Objects and data types from third-party plugins. Read on for what changed and how it works.

Why 9.0.0?

Quick update. If you were expecting Hops 0.18.0, this is it under a new number. Hops version numbers now start with the version of Rhino they’re designed to work with, so the first release for Rhino 9 is 9.0.0. It comes straight after 0.17.1, and the new number doesn’t mean anything changed beyond what’s described below. Look for Hops 9.0.0 in the Package Manager in Rhino 9. Now, back to the story.

The problem with Model Objects

Until now, Hops and Rhino.Compute could only send a fixed list of data types: numbers, text, booleans, and common geometry such as points, curves, surfaces (breps) and meshes. Rhino 8 introduced a new kind of data: Model Objects. A Model Object bundles a piece of geometry with its attributes, such as the layer it’s on, its material, its display color, its name and its user text. It carries the context the geometry lives in, not just its shape.

Before Hops 9.0.0, Hops converted each value to JSON on its own and sent it in the values field of the request: numbers and text as plain values, and geometry in Rhino’s JSON format, which wraps it as a Base64 string. That works for geometry, but anything outside the list of types Hops and Rhino.Compute knew how to convert was left out. Model Objects need more than their geometry. Their layer, material and any other attributes have to travel with them.

What’s new in Hops 9.0.0

Hops 9.0.0 adds a second way to send data, in a new values-grasshopper field. Instead of converting values one at a time, Hops writes each input’s whole data tree into a GH_Archive, the same format Grasshopper uses to save data inside a definition, and Rhino.Compute sends its outputs back the same way. Because it’s Grasshopper’s own format:

• Any built-in Grasshopper data type can be sent, including Model Objects and other model content such as layers, materials and hatch patterns.
• Third-party data types work too, as long as they implement IGH_Goo (the interface behind every Grasshopper data type) and its Write and Read methods. If Grasshopper can save a type inside a definition, Hops can send it. The plugin has to be installed both on the computer running Hops and on the Rhino.Compute server.
• Data trees arrive exactly as they were sent, including empty branches and null items.
• Model Objects that reference objects in your Rhino document are sent as copies, since the server doesn’t have your document.

You don’t need to change anything to use it. When Hops connects to a Rhino.Compute server, the server says which formats it supports, and Hops uses the new one when it can. With a Rhino 7 or Rhino 8 server, Hops sends JSON as before. Other clients, such as the Python and JavaScript libraries, keep sending and receiving JSON.

Requirements

The new format needs Rhino 9 on both sides. Hops must be running in Rhino 9 and Rhino.Compute also needs Rhino 9, because it relies on changes to how Grasshopper in Rhino 9 saves data.

• Hops: install Hops 9.0.0 from the Package Manager in Rhino 9. Hops comes with its own copy of Rhino.Compute for running definitions on your local computer, so that’s updated too.
• Your own Rhino.Compute server: set up a server for Rhino 9 with the bootstrap script, or bring an existing Rhino 9 server up to date with the update script. See Deployment to Production Servers.

Examples:

1. Turning room outlines into a color-coded area plan (Model Objects in and out).

   This example sends Rhino objects to Rhino.Compute together with their attributes, and gets back new Rhino objects that already have their own layers, names and colors. It doesn’t need any plugins. Before Hops 9.0.0, the server could only have received the bare curves, without their names or layers, and could only have sent back plain geometry for you to bake and style yourself.

   The model, RoomPlan.3dm, has seven room outlines. Each room’s program is the sublayer it’s on (Rooms::Office, Rooms::Meeting, Rooms::Circulation or Rooms::Support), each sublayer has its own color, and each outline is named after its room, such as Office 1 or Corridor.

   
   
   (click to enlarge)

   The base definition, RoomPlan.gh, has one context Get Object parameter named Rooms and one Context Bake component named Plan. For each room, it:

   • reads the outline, the room’s name and its layer from the Model Object component. Then the program name and color are derived from that layer with the Model Layer component,
   • computes the floor area and its center with the Area component, then makes a hatch with the Model Hatch component and a label such as Office 1 / 48.0 m² with the Annotation Dot component,
   • creates a Program::<program> layer with a second Model Layer component, and puts the hatch and the label on it as new Model Objects,
   • groups the results into one branch per program with Create Set, Member Index and List Item components, so the Plan output is a data tree with a branch for each program
   
   
   (click to enlarge)

   In RoomPlanWithHops.gh, Query Model Objects collects the room outlines. Setting its Layer filter to Rooms::* keeps it to the objects on the Rooms sublayers. The Hops component sends them to Rhino.Compute, and its Plan output goes to a Content Cache component. Click Push Content to add the colored hatches and room labels to your Rhino document, already on their new correct layers.

   
   
   (click to enlarge)

   Try editing the room rectangles and pushing the Push Content button to see the room hatches and annotation dots update automatically.

   If you save the files somewhere else, keep RoomPlan.gh in the same folder as RoomPlanWithHops.gh. Hops looks for it there when the path it saved no longer exists.

   Files:

   • RoomPlan.3dm (40.5 KB)
   • RoomPlan.gh (15.2 KB)
   • RoomPlanWithHops.gh (10.7 KB)

---

2. Sampling a texture and returning a 2D bitmap (a third-party data type from the JAVID plugin). JAVID is an open-source graphic design and image-processing plugin for Grasshopper.

   This example needs JAVID 1.3.1, installed from the Package Manager on both the computer running Hops and the Rhino.Compute server. On a server set up with the bootstrap script, install it for the RhinoComputeUser account (see My plugin works on my computer but not on the server).

   
   
   (click to enlarge)

   The definition has three context Get components: a Get Integer parameter named Image Size, a Get Boolean parameter named Flip, and a Get Data parameter named Texture. It has one Context Bake component, named Bitmap.

   It creates a grid of points in the [0-1] domain, uses their coordinates to sample the texture in UV space, and builds a 2D bitmap from the sampled colors.

   
   
   (click to enlarge)

   Note: The Context Get Data and Get Object parameters are new in Rhino 9, added for this version of Hops and Rhino.Compute. Use Get Object for Model Objects, meaning geometry with its attributes. For other model content, such as layers, materials or hatch patterns, use Get Data.

   Files:

   • JavidTextureSampler.gh (19.7 KB)
   • JavidTextureSamplerWithHops.gh (26.9 KB)