GH applicationId and location (point, line, curve)

[alex-d-richards (Alex Richards)]

Hi Specklers,

applicationId and location (point, line, curve) are possible to read from the Deconstruct Node but there is no way to add/ modify them through GH.

the docs cover some good ways to mutate existing objects to ensure a consistent applicationID is assigned to GH objects:

I have a few questions, ideas on this:

1. in v2 i would often define the application ID from the logic within the scripts data structure, Hash of a unique_obj_type + path which would often be fairly consistent across iterations and where it isn’t probably not concerned about diffing?

3. Loading the last published model in and using the passthrough nodes is a good approach. a few issues i see is that you still need a way to re associate the new geometry with the previous loaded, probably via a closest point match or something similar. depending on the changes this could be simple or not.

4. There are likely scenarios where you want to take revit geometry and say split it into parts for analysis. This would create 3 new/ random application_ids for the new objects each time through GH. however there is a consistent logic to how these could be calculated if they could be set through GH. original_application_id + 1,2,3…

On the location data. I’m happy that we can create dataobjects constructed from multiple geometry (Brep and the base line geometry) to so they are both stored and accessible.

However there could well be times when you don’t really want the baseCurve etc rendered in the viewer but stored for future interoperability/ use but not presented.

Geometry can’t be added to properties so arn’t suitable.

A higher level object that exposes this i expect is the solution. which leads on to in v2 there was quite an extensive array of Object Kits for GH. Is there any intention currently to develop this for V3/ any developer guidance on how this could be implemented.

Sorry possible a bit stuck in my ways from v2 but hopefully some useful items for discussion.

[bjoern (Björn Steinhagen)]

Hey @alex-d-richards,

Thanks for your patience on this! We’ve just released v3.14.0 which includes an enhancement to have access to the applicationId on the passthrough components. Now, you will be able to mutate and assign as you see fit.

• By zooming in on the components and hitting the “+”, you will have the ability to expand hidden properties, applicationId being one of those
• Initially, the applicationId shown on the output is the host assigned application id and in the case of grasshopper-generated geometry, a random guid
• You can pipe in your new application id to assign it to the object(s)
• Please note, that when new application id’s are assigned, the responsibility will be on you to make sure that the id’s are unique etc.

[alex-d-richards (Alex Richards)]

This is great @bjoern,

A side effect I’m seeing though is that due to the input parameters name/order changes components are lost when opening an older version of a grasshopper script which means we have to run through and wire every thing back up. is there anyway to avoid this?

Thanks

[bjoern (Björn Steinhagen)]

Hey @alex-d-richards,

Thanks for the feedback and noted. Apologies on the frustration of re-wiring things up each time. We have been moving quite quickly with feature enhancements and additions over the past couple of months and haven’t been deprecating every component change / update to avoid polluting the codebase. BUT, having said that with new additions and enhancements now stabilising, we will have stricter bookkeeping moving forward.

Cheers for the feedback!