[WEBINAR] Day 2 Challenge (07/05/2020)

Feel free to discuss and ask questions about this morning’s session and the Day 2 challenge in this topic!

You can work on the challenge by using the same file as yesterday and check the red groups with a title starting with the number 2:

We will give answers to the challenge tomorrow morning, and we will share the final model ready to be uploaded and used in a cloud application at the end of the last session.


Additionally, find here the models Edwin used during the webinar, as well as the JSON demo model:


See you tomorrow!

Thank you for demonstrating the JSON components this morning (and the shout out for the Pathmapper Help, I shall always be known as “The Pathmapper Guy”).

Here is my first attempt at JSON String manipulation:


JSON_Points_DB.gh (17.7 KB)

I do have one question though for the ShapeDiver developers. What is the rationale behind the [JSONAccess] component’s Data Tree Structure on the output side? It seems to lose the proceeding Tree Structure and causes a continuity issue, hence the use of pathmapper when introducing the Position Object into the panel.

3 Likes

Hi Mathieu, unfortunately I was getting really bad/slow audio feedback, so it was impossible to follow. Will you be uploading the 3 sessions? Really interested in working on the challenges. Thanks!

Hey guys! Thank you again for the webinar, it’s awesome!
Here is my attempt… in case it helps anyone!
(Danny’s post has been of great help so I figured…)
RibsTable_day2_iv.gh (132.5 KB)

3 Likes

Hello! This is how I would do it (after getting to know your JSON components).
JSON.gh (13.9 KB)

3 Likes

hi @Andres_Roppa, we will be releasing the videos in our YouTube channel in mid May. Additionally, we are posting all the information we use in each session in the forum posts so you can work on the challenges :slight_smile:

Can you point more precisely a behaviour where the tree structure is lost? It is possible that some implementation decisions break it in order to create a coherent behaviour regarding the JSON data structure. This is especially true because a JSON field can always contain either a single item or a list, so it is always difficult to map a JSON object to a Grasshopper data tree in a satisfying way.

Hi Mathieu,

Please by no means take this as negative criticism. I just wish to be helpful.

Using the dfeinitin above:

It appears (and this may not be the case and I have misinterpreted what’s happening) that [Parse] maintains the Tree Structure, then [Access] takes the last branch and makes it the first branch and grafts an additional branch after that.
This is evident in the second [Access] where a Native GH component would produce {A;B} --> {A;B;C} allowing for the multiple objects to sit on a branch of their own downstream, but the results are more like {A;B} --> {B;C} where the significant branch number resides at the front of the Tree Structure.
i.e. {0;0} -> {0;0}, {1;0}, {2;0}
where I would have expected
{0;0} --> {0;0;0], {0;0;1}, {0;0;2}

Below I layout, with the help of smoke and mirrors, what I would expect the Data Trees to look like at each step compared to the ShapeDiver components:

As you can see from the example above the x values 0 and 6 should not logically be on the same branch. Where as they should be the first index of different branches.

Hope this helps in some way.

Going further with Tree complexity:


JSON_DataTreeStructures_DB.gh (22.0 KB)

[MODIFIED] In hindsight the graft in the last component would not be necessary… I have adjusted to reflect this.

Excelente, thanks … this is awesome work … i´d hate to miss it.

1 Like

Hey Mathieu, I’m bumping into the same issue (i think)… I have made a simple example here:
It seems like the branch information is lost when going for a specific AddressString?

1 Like

@dannyboyesiom @maximbroos Thank you for pointing this out, it seems that the Access component could indeed be improved to preserve the input tree structure. I added this to our roadmap, I will let you know when this update is released.

1 Like

@dannyboyesiom @maximbroos as Mathieu replied, we will look into ways to improve the behaviour of the JSON components. However, each case of JSON structure may require a different tree structure and that is why in the webinar I showed two ways of accesing JSON objects.

The first option is to access the JSON by simply adding the address that you are looking for:


However, when your JSON structure is more complex and goes deeper and deeper, I recommend to look for the exact item you require by giving the exact address:

In this example we have an array/list of curves which contain an array/list of points. In Grasshopper terms we have a tree, because we have a list of lists. To access the final coordinates of this JSON I actually count how many curves and points there are, and then I create the exact addresses where my coordinates are stored. For example, curves[2]points[0]x which means I am accesing the coordinate x in the point in the index 0 and in the curve in index 2. This is basically how a web developer also access a JSON structure.

I hope this helps.

Thanks, I’m glad you are going to be fixing the tree issue with the Access component. As it stands the component would not return what is expected at the address specified.

I updated this topic, which was used for the Day 2 challenge last week. Find all the files in the initial post and feel free to discuss the topics of today and the challenge below!

1 Like

Hi Mathieu! @edsahergom Edwin presented a definition that replaced Region Difference with a C# cluster. It was option C in the example he showed. I didn’t find him here. Could you share?

Hi! I isolated some of the code to create curves with HoverDragEffect controls. I would like to create 3 curves that will form a loft. @edsahergom showed a way to create multiple curves through an array in json, but how can I create control points for each curve in grasshopper and jason? Would it be creating different Keys “ControlPnts”? Can anyone create something like this?

This Codepen shows the code https://codepen.io/pvilarim/pen/gOaoVWp


JSON CONTROL POINTS.gh (25.1 KB)

api.scene.get({name:"ControlPnts",format:"glb"},'CommPlugin_1').data[0].id,
        interactionGroup: controlPntsGroup.id,
        interactionMode: "sub",
        dragPlaneNormal: { x: 0, y: 1, z: 0 }
      }
    ],'CommPlugin_1'
  );

Hi @pvilarim,

Regarding the model with the cluster for Region Difference, here is the updated GH file of yesterday’s session: Second Day_Notes.gh (79.7 KB)

Regarding the control points for several curves, firstable you need to create a JSON format which supports several curves. This was the last JSON we reviewed in yesterday’s session and it is in the “Second Day_Notes” definition file I just shared with you.

After you have this JSON format, then you can send all the control points meshes as a grafted tree to be able to control each point independently, and additionally a ShapeDiverDataOutput (Something we will talk about in today’s session) which contains the addresses of these control points in the JSON.

Finally, when you drag a point, you can get what is the index of the dragged point and correlate this index with the address of the ShapeDiverDataOutput which will give you the exact position in the JSON where you should update with the new coordinates.

I have added to your definition this example I just explained: JSON CONTROL POINTS.gh (41.8 KB)

I hope this helps and see you soon in today’s session.

1 Like

jswan is a pretty useful tool if you wish to simplify your JSON generation process. Utilizes DataTree structures too :wink:

Andrew has a detailed explanation of how to us the components: https://github.com/andrewheumann/jswan

1 Like

Might be interesting for you to check the two ways to achieve this with the jswan approach:


JSON_DataTreeStructures_DB_with_jswan.gh (24.6 KB)

1 Like