Hello everyone,
I am encountering an odd error when I try to split a footprint into perimeter and core zones. The component runs smoothly in converting the geometry into a Dragonfly building, however, if I apply a perimeter offset I get the error that you see in the picture.
The strange thing is that I am getting this error only for that particular geometry on the left, can someone explain why this shape is not working?
Offset_issue.gh (30.4 KB)
Thanks in advance,
Cheers
Hi @Mateo,
I think you found a bug. It looks like the script is not able to cope with this specific geometry.
Hi @Erikbeeren,
I think you might be right. I have tried out another shape (the left one in the picture) and the same problem occurs (however the reported error is a different one).
I have also tried out another approach to build the building starting from a solid instead but again is not working!
Anyone knows a way around the problem of should I wait for a component update?
Thanks for bringing this up, @Matteo and for looping me in, @Erikbeeren .
I should note that not all shapes have a straight skeleton that is compatible with core/perimeter zoning if the skeleton intersects itself. You can usually get a visual of the straight skeleton by using the HB Straight Skeleton component, which might be helpful here.
But, whatever the case, you should not be getting an error and the component should still proceed without the core/perimeter zoning if the straight skeleton intersects itself. I will have a look now.
Thank you @chris for checking it out.
However, it is not clear why the error is happening in this specific case. The skeleton does not intersect itself here since I am asking for an offset of 3m when the width of the “wings” sticking out from the main square area is 12m. I notice that the same error occurs when using the HB Straight Skeleton component you suggested for the shape with “two wings” while it works (without creating the perimeter and core zones) in the case of the more complex geometry apparently.
Curious to see if you find out what the problem is!
Hey @Matteo ,
As you see on the left, the straight sekeleton is self-intersecting. Thisis also the case for your other geometry:
You are right that, with a shallow enough offset, the rooms would not intersect even though the straight skeleton as a whole intersects. I have plans to add support for still generating the core/perimeter rooms with these shallow offsets and you’ll know that they have been implemented when this issue is closed:
For now, I just added some code to catch the exception so that the component is still usable with these geometries (it just won’t generate any core/perimeter Rooms):
I see, it’s clear now @chris, and great that you’ve opened the issue to address the other problem.
I will keep an eye on it! Thanks for your time and help,
Best,
Matteo
Hey @Matteo ,
I am just letting you know that this was quicker to address than expected. I just merged the ability to generate core/perimeter Rooms for any shape with a shallow enough offset:
You should be able to get the improvement with the versioner in a hour or so:
Hey @chris, sorry again for writing,
I was trying just now to get the update through the version component but, despite the new version 1.5.55 seems now installed correctly, the core/perimeter zones are not being created for the two shapes I was testing out (the error in the component however disappeared! I am also checking the HB Straight Skeleton component but the offset is not created there as well).
Am I doing the right passages? Should I just wait some more hours and try to re-update or something is now working as it should?
Sorry. The deployment of the fix hit a snag. I just verified it’s now in the latest version of the plugin that you can get with the Versioner.
Just tested it, works well now!
Hi @chris,
I encountered a relatively simple surface that acts unexpectedly in 2 ways regarding the perimeter offset:
When using DF Building from Footprint, it offsets the perimeter outwards as opposed to inwards and generates overlapping solids.
When using DF Building from Solid, it ignores the perimeter offset, probably as per the error handling.
Any idea why this seemingly simple surface doesn’t work?
Kind regards,
Marc
perimeter offset bugs.gh (18.2 KB)
Thanks for reporting the bug, @marctavenier , and I’ll try to push a fix shortly.
In the meantime, you can correct this in your script by flipping the input surface:
FYI, I just pushed a fix for this case, which should be available with the LB Versioner within the hour:
With that, the core/perimeter rooms are generated correctly for this case:
Hi @chris,
That works better indeed! Only thing is it doesn’t generate the core/perimeter rooms when the offset is 2.75 m or higher. Probably as per the error handling, but is this due to a limitation in the algorithm?
Kind regards,
Marc
Sorry for such a late response, @marctavenier . I can say pretty confidently that it’s a limitation of the current algorithm. Honestly, all of the code for the core/perimeter methods are in need of a refactor because I’ve found that the open source project that we based it on is more reliable than what we currently have implemented. Hopefully, I’ll get to this refactor at some point this year but my current answer is just to watch the perimeter offset depth you are using and drop it down if you find that you’re not getting core/perimeter rooms in your results.
Thanks for the reply. Looking forward to the solution for it. For now I will set the perimeter offset as per your suggestion.
Kind regards,
Marc
I just wanted to post an update here a year later that the refactor that I mentioned has been completed. It is now available via the LB Versioner component and it is included in the latest pollination installers.
In addition to switching the straight skeleton part back to the original open source project that the code is based on (which I realized is only slightly more reliable and still far from perfect), the new routines have a lot of extra checks in the stage of extracting core/perimeter polygons from the straight skeleton. This should ensure that you always get at least some result and you can use it on fairly complex geometry:
The worst-case scenario that I can find is one where you might miss a perimeter polygon or two:
… and this should be very rare (maybe ~1-2% of cases)
