Feature/workflow question: manually specifying the “key Story” used for duplication in DF Process Alleys

[Sophie]

Hi Chris @chris ,

I have a workflow question about DF Process Alleys, specifically regarding how Dragonfly chooses the Story that is used as a template for duplication when resolving adjacency between buildings with different floor-to-floor heights.

I’m processing adjacency between two neighboring buildings:

• Building A: floor-to-floor height = 4.5 m
• Building B: floor-to-floor height = 3.0 m

They are adjacent horizontally and overlap only for the lower portion of the taller building. Conceptually, only the overlapping floors should be treated as adiabatic, while the upper floors should remain exterior.

Observed behavior

After running DF Process Alleys, Dragonfly appears to:

• Select an already-processed Story (often a lower Story with adiabatic walls) as a template Story
• Duplicate that Story upward in the taller building
• This causes adiabatic conditions to propagate higher than the actual vertical overlap

I noticed that if I slightly perturb the floor-to-floor height of the overlapping part (e.g. using 2.95 m instead of 3.0 m), that floor is treated as a distinct Story and the adjacency is resolved as expected. This suggests that the duplication logic may depend on how Stories are grouped or identified internally.

Main question

Is it currently possible to manually specify which Story should be treated as the “key Story” used for duplication after running DF Process Alleys?

Conceptually, I’m wondering whether a workflow like this is supported (or planned):

• lower floors are normal,
• one specific Story is treated as the key adjacency-resolving Story,
• all higher Stories copy the configuration of that key Story,

instead of relying on small geometric differences (e.g. slightly changing floor-to-floor heights) to force Dragonfly to recognize a special Story.

Here is my gh sample file.
building adjacency.gh (38.8 KB)

Additional observation (possible adjacency detection threshold?)

I’d like to add one more small observation related to DF Process Alleys adjacency detection.

From my tests, it seems that adjacency is only successfully detected and converted to adiabatic interior walls when the overlapping interface between two buildings reaches (or exceeds) roughly ~50% of the wall area.

In cases where:

• the two buildings intersect horizontally, but
• the overlapping interface is relatively small (clearly less than half of the wall area),

the adjacency does not get recognized, and the walls remain exterior, even though there is still a geometric intersection.

Environment

• OS: Windows 10
• Rhino / Grasshopper: Rhino 8
• Ladybug Tools: 1.9.0

Thanks a lot!

[chris]

Hi @Sophie ,

Sorry for the late reply here and thanks for the question.

What you are observing here is the interaction of dragonfly story multipliers with the “Process Alleyways” logic. The DF Building from Solid component works by taking any story floor plate that is perfectly equal to the one above it and representing it as a multiplier of the story below. So it discards the full geometry of this story in favor of a more compact representation of it with just an integer multiplier, which improves performance and helps the dragonfly plugin scale for large urban models. If you want to see the “real” geometry that is stored on each Building, you can use the DF Visualize Quick component like so:

So, when you run the “Process Alleyways” component on something like this, it is only editing those stories of “real” geometry and then all of those stories represented with multipliers get the same adiabatic boundary condition as that story.

To work around this in special cases, you can always get rid of the multipliers altogether and represent the Dragonfly Building with fully-explicit geometry. The way to do this is to deconstruct the dragonfly Building with DF Deconstruct All Object and then reassemble the explicit story objects without multipliers into a new Building like so:

Then, you will see that the alleyways are more like what you were originally imagining:

Here is the sample file:
building adjacency_no_multiplier.gh (49.5 KB)

@Sophie

From my tests, it seems that adjacency is only successfully detected and converted to adiabatic interior walls when the overlapping interface between two buildings reaches (or exceeds) roughly ~50% of the wall area.

This is correct and is, again, the result of dragonfly’s abstraction to enable better performance by default.

If you have a lot of cases like this in your urban area and you are worried about getting the adjacencies of buildings perfectly , I have an alternative suggestion to the one above. Just use the HB Intersect Solids component on your building breps before you use them to make DF Building from Solid. That will ensure that you have matching intersected geometries that will get (mostly) carried through the alleyway creation process:

And, in this case, you’ll find that you don’t even need to get rid of the story multipliers because the intersection of the starting geometries has helped differentiate the story floor plate geometry at the places of intersection. Here is the sample file:
building adjacency_intersect_solids.gh (47.5 KB)

Hope that helps.

[Sophie]

Hi Chris,

Thank you so much for the detailed explanation. The clarification about story multipliers and how Process Alleyways edits only explicit geometry was extremely helpful.

Really appreciate the clear explanation and sample files!

Best,
Sophie