Inconsistent RH_OUT data structure from rhino compute

Rhino Developer compute.rhino3d
, ,
1

Hello!

I have a problem with the data structure that comes out from rhino compute. After it is formatted to JSON structure, I use the following code to fetch the base64 string representation of a mesh that is part of the response:

const meshString = JSON.parse(InnerTree['{0}'][0].data)

This works only sometimes, and I have found that when it fails to find the mesh string it is because it is instead on the path {0;0} on the inner tree, so the correct code to fetch it would be:

const meshString = JSON.parse(InnerTree['{0;0}'][0].data)

The strange thing is that I get this issue only sometimes, and I flatten all my output data before I put it into RH_OUT containers. Have you encountered something similar? What is it that decides the structure of the InnerTree object in response.json().values where response is the response of the fetch-request to rhino?

Thnak you!

4

The output tree structure is set by Grasshopper (even a single item is stored internally as a tree with a single branch). The branches are then converted to a dictionary for JSON serialisation. I’d recommend handling the output in such a way that doesn’t rely on the existence of specific paths (i.e. loop through all keys in the InnerTree dictionary). You could also try “simplifying” the output or using the graph mapper.

5

Hello @will!
Thanks for your reply. I think your idea with looping through the keys is the way to go so thank you for that.

Just a follow-up question: When you specify more than one RH_OUT-parameter, do you know what Grasshoppers convention is for dealing with this? Let’s say we have two outputs, A and B where a is an item and B is a flat list. Is the idea that grasshopper always should parse this to a tree structure with two branches, where {0} is an item and {1} is a list?

6

Each RH_OUT:* param should be a separate key with it’s own InnerTree in the JSON response from Compute.

7

Ok, perfect! I get it, thank you.

8

I have ran into a similar problem. My workflow depends on the path structure I have build in grasshopper {A;B;C} where they serve as identifiers for a flat list of “Planes” i am trying to export.
The planes are okay, but the paths I try to export are not.
I suspect it has to do with the way rhino compute solves a gh definition, against how grasshopper solves it…
I am wondering if anyone has some insights on this…

Here I attach a screenshot of the paths (as a string in gh) and as a string received in the json.dump.

image
image1920×540 214 KB