Attached series of images are highlighting a problem that we have suffered during preparing an energy model of a hotel building. The images show the building layout and the offsets that we created to have a (core + perimeter) setup but as you see when we tried to rotate or relocate the building fingers, the definition stuck to find correct zones.
After quick research, we found that the best way of creating (core + perimeter) zones for quite complex shapes is the idea of straight skeleton subdivision, something like attached GIF by LiquidSo https://discourse.mcneel.com/u/liquidso/summary.
Your first gif is really small… cannot see what is going on there.
Also, you are talking about “energy model”… is that a roof?
Can you give more details on your problem?
Thank you @maje90 for your interest. I’m sorry for this confusion. I just updated the post with more clear images and quite detailed description.
It’s a typical floor of the building and this is its top view.
What do you think?
I’m sorry that the problem is still not that clear for you. Here you are the problem in different words:
In conceptual phase when you’re creating your first computational sketches in your design process, you build a quick parametric 3D model that help you to test all your design variations in an easy way compared to conventional and traditional ways.
So, for example, if your goal is to test your generated mass energy efficiency, you should first divide it into ZONES. This process got automated by the guys of Hoenybee through a component called “Honeybee_SplitFloor2ThermalZones”. This component is able to automate the process of subdividing the building mass into (Core + Perimeter). However this component get stuck usually for non-convex shapes “quite complicated network of curves”.
Then we tried to override this problem and create small definition to be able to deal with those non-convex geometries to create this offset easily “Check attached image”.
This way succeeded but with many limitations as you see in the series of images in our top post. If you are trying to reconfigure the building layout, offsets get intersected and creating a mess.
We searched to find another way of creating building zones with no problems and we found what Timur Dogan, Christoph Reinhart, and Panagiotis Michalatos mentioned about using “straight-skeleton subdivision” is a perfect clue for this problem.
Now, to sum up, we are searching to find a definition or a plugin that can do this job using the concept of, or something similar to, “straight-skeleton subdivision”.
I wish you find this helpful to understand the problem clearly.
The problem is that I need to clean up this flat surface from those small lines, something like collapsing those useless lines and then merge those faces together to have a clean face.
Hello @m.nagy.eg,
here is a little trick to “merge” coplanar faces. As faces have not the same direction (my fault in my script) I fits join breps in order to orient then then explode them them group by direction then extract naked edges. I hope it is useful.
@laurent_delrieu@PeterFotiadis
There’s another thing that I want your cool participation in.
In the script, can we control those highlighted inclination distances “in yellow” to be equal, then we can create a flat surface after we reached its length threshold?
Could you kindly advice?
Er … hmm … that’s toooooooo far: I just added a single line meaning that the accolade for that C# belongs 1000% to Laurent.
BTW: After the MergeCoplanarFaces Method - and provided that yields a correct result - the brep (i.e. the whole roof) edges are either naked (adjacent to one BrepFace) or clothed (adjacent to two). Kinda like the edges in a Mesh. Forgot the name but GH has a native component that inquires a brep.
