# Issue creating floors from Bldg Geo (2)

This is related to my other post Issue creating floors from Bldg Geo but it’s a slightly different scenario, which might make a difference, hence the new post.

I have this scenario:

unnamed2.gh (15.2 KB)

I want to keep within the bounds of the input geometry, i.e. my expected outcome is this:

But here is what I’m actually getting:

I’m having trouble making sense of this. In particular:

1. I specified 4m floor heights so I would expect DF to take that at face value instead of extending the floor height of the top floor to match the input geometry height. Is there a way to change this?
2. Why is the middle floor not visible? If it is because it is considering it identical to the ground floor and applying a multiplier, is that a fair simplification? The ground floor has a different boundary condition (in contact with ground); I would expect this to have a significant impact.
3. The 2nd floor extends across the entire footprint, meaning that the resulting building exceeds the boundary onf the input geometry. Is there a way to change this, i.e. force it to stay strictly within the given brep (while maintaining the specified floor height)?

Here’s what I recommend doing for your case:

Dragonfly_Building.gh (20.2 KB)

I know that the way the tolerance works may be a little counter-intuitive when you try to hit the story height exactly. If you search the forum, you will see that you’re not the first to ask about this and maybe I can think of a way to guess what you actually mean to input for cases like this where you want the first floor to be intersected within the tolerance but you want the other stories to be intersected above the tolerance.

The middle floor was not visible because you were previewing the individual unique Story objects and not the whole Building as you see in my screenshot above. Dragonfly has a concept of “Story Multiplier” which really comes in handy when trying to run energy simulations of large urban districts. So the middle story is represented by a multiplier by default.

I really recommend that you watch this Youtube tutorial series as it will answer a lot of your questions:

This video in particular explains how a lot of the logic behind the “Building from Solids” component works:

Hi @chris, and thanks for your quick response (as usual).

In my case, I’m building a tool so I need to automate this without having to manually add/subtract tolerances. I think I’ve landed on a solution to create floors where I want them to be, with my specified consistent floor height, and without ever exceeding the bounds of the input brep. This appears to work both for input geometries that exceed `floorheight*x`:

…as well as for input geometries with ceilings that are exactly `floorheight*x`:

unnamed3.gh (38.9 KB)

In both cases, I am using the logic from your video to create multipliers for identical floors. (I think there is an edge case that I’m not catching, where I don’t recognise identical floors if their vertices happen to be ordered differently. Also not worrying about curved input geometry right now.)

The one thing I’m still missing is that super helpful `_perim_offset` function of the DF Building from Solid component. If I build the building floor-by-floor as above, is there still a way in which I can autogenerate perimeter/core zones?

You inspired me to look into this again. In full honesty, it’s possible that I may need to revert the change I just made if I find that it creates more issues than it solves. It’s hard to know for sure because this issue is all in the somewhat nebulous realm of how Rhinocommon interprets the intersection tolerance, which we have had long discussion with the McNeel team about before. But I have implemented something that gives you what you expect for your case and it does not seem to disrupt the existing behavior so I’m hopeful that I should not need to revert it:

You can get the updated component now by running the LB Versioner.

1 Like