Modeling high rise buildings in HB

Hello everyone,

I am not sure if this is a question or a request, might be both.

Okay let's imagine we want to model a high-rise building with something like 50+ floors.

We always start simple, so we model a typical floor. We pass the Rhino model to HB, create our zones, add our glazing, shading surfaces, and we run our first simulations.

Next step, we want to model a few different floors, that might represent the building's performance better (e.g. lower floor, middle floor, penthouse). How can we go from the typical floor (which probably took a couple of days to model surface by surface) to multiple floors without re-doing the whole process? It would be great if there was a way to simply copy paste everything and new zones would be created, since they are the same. I understand that this might be a grasshopper limitation, as breps are location specific in Rhino (I think?).

Still a way to quickly set up any number of clones of our typical floor withn HB would save countless hours. Also, if this is already there in some kind of way I apologize, and cool!

Kind regards,

Theodore.

Replies are closed for this discussion.

Replies to This Discussion

Permalink Reply by Theodoros Galanos on September 8, 2015 at 3:59am

I may be answering my own question here but would native transformation GH components work here?

Could I copy the group of components defining a zone and then move it vertically to position it at the second floor? Would that even work? I'll try it once a simulation I have running is over.

Kind regards,

Theodore.

Permalink Reply by Mostapha Sadeghipour Roudsari on September 8, 2015 at 4:43pm

Hi Theodore! That's exactly what I wanted to say. Would it work to copy your input surfaces before creating the zones? Moving HBZones won't work for you at this point (I would say it's a bug on our side!) but can be added if moving the original geometries are not helpful.

Permalink Reply by Chris Mackey on September 8, 2015 at 11:12pm

Theodore,

I know and feel your pain very deeply in my own workflow. Mostapha, you describe my current process very accurately but, while it gets the job done, it inevitably ends up blowing up my GH file into a huge spaghetti mess. This is because we have to perform the geometry transformation BEFORE turning the geometry into HBZones, which means that all of the properties that you change/assign to your original zones have to be done again to the new transformed zones as well. Oftentimes, I have repeating floors and I just want to keep these same zone properties through the geometric transformation.

Things get particularly out of hand if you have to do such transformations more than 2 times (I had to do it for a 5-story building once).

To address this issue, I have had it on my agenda for a while to make a component that re-evaluates HBZone geometry and adds any zones transformed with native GH components to the HB hive as new HBZones. This way, you could perform any of the common transforms to zone geometry (translation, scale, rotation, reflection) and have Honeybee able to understand these zones as geometrically-altered versions of the original zones.

I forgot to make this agenda item into a githib issue but now that you have reminded me...

https://github.com/mostaphaRoudsari/Honeybee/issues/373

I will try to get to this sometime soon.

-Chris

Permalink Reply by Theodoros Galanos on September 9, 2015 at 8:55pm

Ho Mostapha and Chris,

Thanks for the input.

I agree with all of your comments. Copying is the only way I'm doing it now but as Chris mentioned that requires us to re-set all the material information. This actually works like a charm in Daylighting studies mainly due to no limitation from radiance side to closed zones and so on. All I need to do for daylighting is make sure that all surfaces are divided in layers and then copy paste as many floors I want and input each layer in a brep afterwards.

I think if we can use native components to add zones to HB that would have an immense impact to our models (or maybe just mine :) ). So it's good news this is added on the list.

Kind regards,

Theodore.

Permalink Reply by Mostapha Sadeghipour Roudsari on September 10, 2015 at 8:25pm

I agree that we need to address this issue however I suggest a different approach. User may have created several transforms to the original geometry which will be very hard to track. Also what would you do for several copies of the same object with the same HBID?

I think we need to create a number of components for moveHoneybeeObjects, rotateHoneybeeObjects, and scaleHonebeeObjects. In this way we can keep track of changes without so much headache. otherwise it can be so tricky.

Thoughts?

Permalink Reply by Chris Mackey on September 13, 2015 at 3:25pm

Mostapha,

I can see a workflow in which we have 4 components that each perform one of the 4 key types of transforms (translation, rotation, reflection and scale) and I can see how this might make things a bit easier on our end rather than a single "re-read geometry" component.

However, I am not sure if the way that you are proposing it would really solve this issue that Theodore and I are bringing up. This is mainly that we don't want to simply take a HBZone and transform it (which we can do before creating the HBZone anyway) but that we want to take an existing HBzone and both transform it and turn it into a completely new zone with a new HBID. This way, we can take both the non-transformed zone that - let's say - represents one floor of a building and the transformed zone representing another floor, run them both through solve adjacencies, and plug them into the Run Simulation component to be run as one model.

So, regardless of our implementation method (be it with 1 component or 4), we would need a function that copies all of the properties of a zone and copies all of the surfaces and child surfaces to create a new transformed zone. Correct me if I am wrong but this is what you are describing as causing a big headache. If so, leave it to me to investigate how to do this and just met me know if you have a preference for having one "re-read geometry" component or one component for each of the 4 major types of transforms.

-Chris

Permalink Reply by Mostapha Sadeghipour Roudsari on September 13, 2015 at 11:04pm

Hi Chris, We may talk about the same approach. We already have a method that copies a HBZone (callFromHive). We only need to apply a transform function for geometries and update geometry related data for HBZone and HBSurfaces. At the same time there are properties that cannot be copied along such as adjacency. User needs to be notified about that after each transformation. I will create a prototype and upload it here so you and Theodore can check and give me your feedback.

Mostapha

Permalink Reply by Chris Mackey on September 14, 2015 at 4:50pm

Mostapha,

Oh man. I must have had a total lapse of memory. I can't believe that I am just realizing now that the reason why callFromHBHive takes so long is that it makes a copy of the zone. I have written 20 different ways of getting around this time consuming and yet I somehow never questioned why it was so time consuming.
I'm glad that you chimed in here or else I might have taken a long time to write this thing. I guess the only thing we need to do for this capability is change the name and HBID of the zone before adding the transformed zone back to the hive, right?
-Chris

Permalink Reply by Mostapha Sadeghipour Roudsari on September 22, 2015 at 4:37pm

I guess the only thing we need to do for this capability is change the name and HBID of the zone before adding the transformed zone back to the hive, right?

Yes. That should be all we need next to changing geometry related properties. I'm still trying to find a time to make an example.

Permalink Reply by Mostapha Sadeghipour Roudsari on November 4, 2015 at 12:43pm

Theodore and Chris, I added Move, Mirror and Rotate for Honeybee objects. You can find them under WIP. Let me know your thoughts. Keep in mind that all boundary condition will be set to Outdoors once you move, copy or mirror a zone and you need to recalculate adjacency.