I wonder if anyone knows if there is any method to get back to the original Rhino geometry / input Guid after the ‘Aperture’ component has been run and its generated the Face3D object(s)?
is that original source geom reference / Guid stored anyplace on/with the Face3D object(s)? I wasn’t able to find it just looking through, but thought perhaps it might be getting squirreled away someplace I couldn’t find?
if I wanted to do something with / pull some data out of that original geometry but only after it’s gone through the ‘Aperture’, is there any way you can think to do that?
Once geometry is translated to Honeybee, it becomes the geometry that will go off to the simulation engine and so there’s not a 1-to-1 mapping of honeybee geometry and Rhino geometry. You’ll see that honeybee geometry follows rules that the Rhino geometry does not. For example, all Honeybee geometry is planar (since the engines only accept planar geometry) and you can see this when you view Honeybee objects with any of the components in the Honeybee “Visualize” tab. You’ll also see that Honeybee geometry has the “real” normal direction of faces as the simulation engines will interpret it (since the engines enforce the right-hand rule but Rhino does not).
All of this is to say that there’s no property to access the original Rhino geometry of a given honeybee geometry object. The link between Rhino geometry and Honeybee geometry is a translation relationship and not a parent/child relationship. With this said, you can translate the Honeybee geometry to a Rhino Brep using the “HB Visualize All” component:
If you look inside that component, you’ll see that the ladybug_rhino package has a from_face3d method that can be used to translate any Ladybug Face3D into a Rhino Brep.
Will this be suitable for your purpose or is there something specific about the original GUID that you need the original geometry for?
For my workflow, I’ve been hosting a lot of params in the UserText of the object back on the Rh side which is why I was trying to get back to that original object. I have some RH side tools I’ve been making to allow me to manage all that data back in the RH scene. For the kinds of work we do that seems to work better for us than having it all applied/managed inside the GH scene.
So for now I am just trying to pack those params away with the obj so that I can pull them all out again later on during the reporting/analysis phase after all the simulation and LBT model build is complete.
It’s ok though, I was able to push backwards through the component to find the original Guid ok and I think I can make this all work now using this method after the LBT ‘Aperture’ component:
import System
import Rhino
import rhinoscriptsyntax as rs
def aperture_sources():
''' Get the input source with the name "apertures" '''
for input in ghenv.Component.Params.Input:
if input.NickName == 'apertures':
return input.Sources[0]
return None
def window_rh_objects():
''' Work backwards to get the Guid of the original input geom '''
apertures = aperture_sources()
if apertures is None:
return None
hb_aperture_compo = apertures.Attributes.GetTopLevel.DocObject
rh_doc_window_guids = [input.ReferenceID.ToString()
for input in
hb_aperture_compo.Params.Input[0].VolatileData[0]]
for guid in rh_doc_window_guids:
print 'I found the original geom Guid: {}'.format(guid)
return rh_doc_window_guids
def rh_doc_usertext(_guid_str):
''' Get the UserText dictionary for the original window obj '''
guid = System.Guid(_guid_str)
window_obj = Rhino.RhinoDoc.ActiveDoc.Objects.Find( guid )
user_text = {k:rs.GetUserText(window_obj, k) for k in rs.GetUserText(window_obj)}
return user_text
guids = window_rh_objects()
for guid in guids:
window_user_text_dict = rh_doc_usertext(guid)
print( 'The original geom has a UserText dict of: {}'.format(window_user_text_dict) )
# now do some stuff with all that....
I think this will work for me now. I’m just trying to grab that UserText dict and file it away in the ‘user_data’ of the aperture for the time being.
anyway - thanks again for the input and help there! really appreciate it.
best, -e
For the record, I would be in favor of writing the Honeybee components write the Rhino GUID into the user_data dictionary by default if it would help for workflows like this. I think we are doing a version of this for the standalone Rhino plugin that Mingbo has been working on so that it’s possible to match Honeybee objects back to Rhino geometry. If this sounds useful, feel free to open a wish issue on the honeybee-grasshopper-core repo and I will get to it when I can.
awesome - thanks @chris
I’ve opened a new ‘wish’ Issue on the page. If that is possible to just grab that Guid during creation and log it away I think it would be great and certainly useful for the work we’re doing.