I have a bit of a chicken-and-egg problem. I’m modeling a multistory office building (basic massing in Revit and will push into Rhino for refinement and GH/HB analysis). I modelled the office floor-to-ceiling spaces as their own breps, and ceiling plenums as their own breps. Unless I’m mistaken, I must first run all of the building mass breps simultaneously through the HB Intersect Solids component before running them through HB Room From Solid. Both of those components flatten the data, erasing the ability to sort tree branches, and making it much harder to sort out the breps that I’d like to pass through the HB Plenum component (which doesn’t take breps…only takes HB Rooms). I thought that maybe the HB Rooms By Floor Height component might be a way to manage this but the native GH Sort List component gets angry because of mismatched length of data and keys. Is there another way of sorting the rooms? Is my workflow just completely wrong?
I tried Andrew Heumann’s Filter Layer component after HB Intersect Solids but I think the HB component strips the layer names. Woulda been a nice workaround.
Would there be a way to maintain that metadata for just this purpose?
Thanks but I couldn’t get that to work. I know I can build some code that sorts the rooms by height but the more that I think about it, it seems silly to be sorting them this way and to be applying constructions so far into the code instead of at the beginning. Maybe I’m wrong but I would guess that for the purposes of energy modelling, most people organize their Rhino information by layer for each program type. If the HB Intersect Solids component maintained that layer information, one would be able to very clearly assign constructions at the beginning of the algo. I wonder if Chris could consider that suggestion?
Charlie I went back to 2014 … Chris’s 2014 TB on the subject
…and realized that Chris just used the Explode Tree component to separate things at different layers.
Boy I still do wish that I could assign constructions earlier in the algo as I wrote above.
If you want to avoid the woes of list management and data trees when building large Honeybee Models, you are best off buying a license of the Pollination Rhino plugin and using that to build your Honeybee model. The Pollination Rhino plugin has a Solve Adjacency command that can perform this operation without loosing any of the original Rhino layer structure. Then, when you have your Honeybee model complete in Rhino, you can import it into Grasshopper to run whatever simulations you like and postprocess the results with Ladybug Tools
Granted, if you’re motivated enough, you can always develop workarounds in Grasshopper (the Tree Frog suggestion is a good one, @charlie.brooker ). But, if you’re just looking for a convenient shortcut, then this is why we built the Pollination Rhino plugin and why we made it paid.
FYI, if your interested in learning some of these workflows between Pollination Rhino <> Ladybug Tools for Grasshopper. I’ll be covering them in a user meetup at the end of May. See the Pollination forum for an announcement about this soon.
Thankfully your HB Intersect Solids maintains the order of input breps when outputting, so I was able to rig up some standard GH code that can keep individual Rhino layer information separate if each is flowing through its own Geo component. Although Large Office program is assigned to everything in the screenshot below, when I’m ready to get into more detail; this will allow me to very specifically assign Program Types and Construction Sets to each layer.
