Divide surface based on corners

Very Impressive work. Thank you.

I’m late…

Here a possible iterative solution with the good old Anemone

rectangles_V2.gh (16.5 KB)

Works only with orthogonal profile, counterclockwise orientation.

It move the shortest segment by X towards the inside the profile, where X is the shortest length of the 2 adjacent segments.
The shortest segment must be an “external” one, I’ve used some extended point inclusion test to determine this.
That’s it, looping the iteration up to the end (increase iteration count if needed).

Surprisingly neat!


Looks interesting but can’t see it in R5:


rectangles_R5.gh (17.8 KB)
You’ll need to manually add multiplication component as I can’t use the old one. It’s marked where with a group.

Just if needed, old component GH 0.9 still exists in GH1.0 !

1 Like

At first it appeared to work but now it seems broken? Sorry, any idea why? I tried but failed to understand it, especially the Extr component?

rectangles_R5_crv1.gh (25.0 KB)

I wanted to compare it to my version and noticed, in the process, that we worked on different planes (so to speak). So in my version, I replaced a XZ component with a PlFit (Plane Fit) component to fix that. I also re-oriented my examples to match yours (‘World XY’ top view) and added yours as Crv5:.

div_srf_2019Jun17a.gh (21.4 KB)

The direction of the extrusion must be inside (so, subtracting area to the main shape)
I did “found” direction by doing cross product vector from segment vector and Z vector, so yes, it have to work with only planar XY curves.
The curve then must be oriented counterclockwise (if you make a surface out of it, the normal must be equal to Z vector).
Explode and join at start was to preserve the direction during fast edits of original curve.

Maybe on Rhino5 it is working differently. Just check that every segment is oriented counterclockwise or make it so.

Edit: new version without direction problems
rectangles_V2.gh (16.5 KB)

I haven’t looked at yours yet but fixed my version of yours by adding this white group to sort the segments of the curve around a circle (might not always work?):
rectangles_R5_crv2.gh (23.8 KB)

P.S. Tried your ‘rectangles_V2.gh’ in R5 and it oddly works with my Crv1 (derived by hand from this thread’s original post) but fails using your Crv5. My white group sorting the segment doesn’t fix it this time. Weird R5/R6 defects again. :frowning:

On R5 some errors happens with the 0.001 extension; use 0.01 instead.

1 Like

That seems to have fixed it! Different pattern than I saw earlier but looks more optimal for biggest boxes? There isn’t much to your code but how it works eludes me so far…? Looks cool, works well (except for the annoying R5/R6 incompatibilities).

It just moves “inside” the shortest segment.
Instead of using the simple length of the segments to find the shortest, I added to every length a “big” number multiplied by the count of extended endpoints that fall inside of the initial shape.
(so a short segment that is a “gulf” is automatically discarded… and the same for a hybrid gulf/penisula)
That’s why i’m using point-in-curve component: to “fake” the segment lengths and pick only the shortest that is also a “convex penisula” of the shape.
I did naturally in the moment but it could have been done in a better way, indeed.

Looking at the ‘D0’ output of the loop (“Record data” enabled), I see the step-wise process but haven’t yet grasped the inner workings. Will study it though, very cool!

OH! I get it. Brilliant!!! You shift the perimeter in the direction and distance of the [weighted] shortest edge… [no, not quite], then use RDiff to subtract the new position from the old position to shrink the perimeter? Will certainly explore this further as I don’t fully understand what you’re doing yet, but I’m getting it. Very clever, well done.

1 Like

Your description seems perfect to me.
(a “crucial” step is also using discontinuity points, to remove aligned segments…)

Additional criteria must be added.

By trying to make the inner rectangle as big as possible you increase the number of rectangles produced.

Are you referring to my solution?
I didn’t try to make the inner rectangle as big as possible, i started from the outside… and I also think no lesser count of rectangles is possible.
I can be wrong.

No, I meant this one from @Joseph_Oster:


Regarding your solution:
it’s just one of many variants.

Nevertheless, it’s great solution.

Since you are a man attempting to walk the walk (I do hope the correct one: C#) get the attached:

Poly_OrthoPartitions_EntryLevel_V1.gh (122.6 KB)

Next update: holes, straighten (LOL) non ortho polylines, connectivity (FF, EF, FE), queries, cats, dogs and one alligator (a Polyline that looks like an alligator in fact).

1 Like


That image was produced with @Riccardo’s unmodified code. I studied it very carefully and produced a variation (below) that uses the same idea (and much of his code) with a slightly different result. The great insight I got from @Riccardo is to identify “convex peninsulas” and chop them off, one at a time. His method of “weighting” and ranking them is delightfully elegant and simple, if obscure. Inspecting the results made me wonder why it didn’t always choose the smallest (or largest) “peninsula” to remove?

So my variant (below) identifies peninsulas as those edge segments where both ends extend outside the perimeter (Dispatch). Then it chooses the shorter of the segment’s two adjacent edges to compute the area and find the smallest peninsula. Instead of extruding one edge as @Riccardo did, I avoided the issue of extrude/move direction by using a PFrame and Mirror. The result is similar but slightly different, proving the point that there are many ways to do this without additional criteria to choose which is “best”. See the difference in the upper right corner? @Riccardo’s is pink/purple.

The difference below is at the bottom:


rectangles_V2_2019Jun17a.gh (26.3 KB)

As food for thought, here is a variation created with GIMP that looks reasonable if this were a building, but lopping off peninsulas won’t get there.

P.S. I added the ability to choose ‘Edge Length’ instead of ‘Area’ as the basis for choosing which peninsula to remove. For Crv5, the result now matches @Riccardo’s:

But with Crv1, we get something different:

By reversing the Sort ‘A’ output (see yellow arrow below), the largest instead of the smallest peninsula gets lopped off each time. This doesn’t work properly with ‘Edge Length’ though, as there is a flaw…

rectangles_V2_2019Jun18a.gh (42.6 KB)

P.P.S. The flaw I mentioned with largest ‘Edge Length’ also exists with largest ‘Area’ (instead of smallest), as it depends on the remaining perimeter shape. This example demonstrates the flawed assumption that the largest “peninsula” (by Area or Edge Link) doesn’t encompass a “gulf” on the opposite side, when in fact, it can:

1 Like

what kind of sorcery is this?? Tested some work great so far. Thanks Darth Vader!!!