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,


1 Like

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,


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.


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…

I will try to get to this sometime soon.


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 :slight_smile: ). So it’s good news this is added on the list.

Kind regards,


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.



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.


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.



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?

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.

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.

1 Like

So cool Mostapha!!

I’ll check this also after tomorrow, but looks great.


That is amazing Mostapha, thanks!

Will give them a try as soon as I can.

As a side thought, could link something like this with exporting .stl files through Gh as well? :slight_smile:

It would do wonders for pedestrian comfort and wind driven rain studies.



Thanks Theodore and Abraham. Theodore, are you asking for an stl exporter? I think I don’t get the relationship between stl and these components.


I will try it out shortly. All of the rules regarding adjacency make sense and I was imagining always using this component before solving any adjacencies anyway. Icons are awesome, BTW.


Hi Chris, Mostapha, Theodore,

Thanks for the interesting discussion and development. I have been testing the components since yesterday since I wanted to have something like that for some time now and is of great help. I was wondering though which component in the workflow is the one that assigns first the attribute ‘transform’ to the HB zones, since the components do not work in existing scripts without this attribute assigned to the zones. Thanks again for this is a great addition for extended projects!


It’s happening when you initially create the honeybee zone/surface. If you get an error that transform is not available then the HBObject is created with an older version of Honeybee which is missing this method. Recalculate the file with the new version of Honeybee and it should work with no issues.

Hi Mostapha,

Started to check the transformations components and i have to say (again) that i am impresed. Really cool.

Saying that, so far, i’ve found two potential issues:

  1. Naming of zones. I get the following (connecting the red arrow in the attached to the solveAdjc):

  2. There are duplicate names in input zones. Zone names cannot be duplicate.
    Rename the zones and try again!

I overcome this renaming one of the zones, but i believe that in a large case this can be a major issue.

  1. Normal direction pointing inwards on mirrored zones. In the rotated zone i get normals pointing inwards and outwards (weird).

See attached for these issues.

-A. (501 KB)

Hi Abraham,

  1. I spent an hour or so to get normal direction fixed but couldn’t figure it out. For some reason normal direction check doesn’t catch the changes. I will keep trying and will report back if I figure it out.


Thanks Mostapha,

Do you think this is a potential trouble maker (i’m afraid it is, but want to be sure).