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. 
On R5 some errors happens with the 0.001 extension; use 0.01 instead.
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.
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).
…
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…
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:
what kind of sorcery is this?? Tested some work great so far. Thanks Darth Vader!!!
Who knows? (and who cares?).
Not found the time for the next big thing (and I’m not sure if I can post the optimized stuff [is using some quite tricky internal things]) … so get a prelude (WIP indicates future stuff: work in progress, that is).
Poly_OrthoPartitions_EntryLevel_V1A.gh (135.6 KB)
BTW: Are you inetrested on queries as well in general ? (Find a face that … blah, blah)
Works great so far!! thanks
This definitions is very advanced than before. Still awesome though. If I have a problem with it I will contact you again. Thanks for this brilliant work!!
Other than that do you speak C#, don’t you? (for providing some classic query demos using Classes and some other freaky stuff).
Hello Peter,
I am very basic at C# basic than python
Also your algorithm doesnt work for multiple polylines. i.e if there is a hole within polylines
That’s why the def is labeled “EntryLevel”
