Inconsistent RH_OUT data structure from rhino compute


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!

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.

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?

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

Ok, perfect! I get it, thank you.