Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Wish: Automatically add reference geom. Guid into an Aperture's 'user_data' lib on creation #154

Open
ed-p-may opened this issue Oct 29, 2020 · 4 comments
Labels
enhancement New feature or request wish New feature or request which is not critical to continued development at this point

Comments

@ed-p-may
Copy link

Wish:
For apertures: automatically add the original referenced surface's Rhino-Guid into the aperture's 'user_data' when creating the aperture object(s). By logging this data, later components can then 'get back to' that original geometry if they need to for some reason.

Alternately, if preserving the Guid itself is not preferred: Just pull the ObjectName and UserText data from the original referenced Rhino geom and add that into the aperture's 'user_data' library for later use / access.

@mostaphaRoudsari
Copy link
Member

Hi @IDF2PH, The GUID can get lost when the geometry is imported to Grasshopper and gets copied. I think what you really need is to set the user_data yourself with this information. We can probably add a component to expose that to users. What are your thoughts on this @chriswmackey?

@mostaphaRoudsari mostaphaRoudsari added enhancement New feature or request wish New feature or request which is not critical to continued development at this point labels Oct 29, 2020
@chriswmackey
Copy link
Member

Hey @mostaphaRoudsari ,
We should have linked to the forum discussion here:
https://discourse.ladybug.tools/t/get-back-to-rhino-geom-after-aperture/11659/4?u=chris

I am ok with just including the GUID of the object in user_data if it exists but I can see that Mostapha raises a good point. Passing the Rhino geometry through any Grasshopper component is going to strip out the GUID:
image

Though, if the original geometry is referenced in the rhino scene, you can get the GUIDs:
image

Is this still going to be useful for your purposes @PH-Tools , if the GUID won't always be there?

@ed-p-may
Copy link
Author

ed-p-may commented Nov 5, 2020

Hi @chriswmackey , @mostaphaRoudsari

Ah - that's a good point - it does seem like saving the Guid might cause trouble in that case? As I noted in the thread on the forum, the goal I'm trying to achieve is to pull all the data from the Rhino Object's Attribute UserText (and Rhino ObjectName) and pack it into the 'user_data' for the aperture so that I can reference it / use it later. For my purposes, I think that either:

  • Just having the 'Aperture' component automatically do this Rhino data get / pack operation itself during creation
  • Allow the Guid to come through just the one time, if I can grab it right after the Aperture component that works fine for me. I can do the packing at that point.

For what I'm trying to do, I think either of those would work just fine. As I noted in the thread though, I was able to work backwards using the component input references as a workaround. So not a huge issue if this can't be accommodated.

thanks!
Ed May / @PH-Tools

@mostaphaRoudsari
Copy link
Member

I think the best implementation here is to give user the freedom to set the user-data as needed and in this case it can be the GUID's from Rhino objects. It is something similar to how we let the user overwrite the identifier for each Honeybee object.

It's a bit ambitious to automate the process of finding the real ID for an aperture depending on how they have been modeled but users can handle that on their side by assigning the userdata as needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request wish New feature or request which is not critical to continued development at this point
Projects
None yet
Development

No branches or pull requests

3 participants