Additional criteria must be added.

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

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!!!

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**”

1 Like

This algorithm has a problem if there is a hole or opening inside the closed polyline

there’s always a hole inside a closed polyline.

if not always then 99.99% since if you join two overlapping lines you get a closed polyline with hole very close to 0

Sure, it can’t work with a set of curves.

For example the extended point inclusion test is done with a single curve, to have a “holed shape” we have to use a different logic, such as “Boundary surface” first and closest distance to surface then.

Added a step where a set of parallel rays (lines) are made and try to intersect with other curves, if an intersection is found, the distance of current rectangle extrusion is lowered.

Fixed the other steps…

…

Code is more and more messy and nothing to be proud of, only work with flat/XY-planar and orthogonal shapes (external perimeters and holes).

I didn’t test it deeply…

rectangles_V3.gh (35.2 KB)

4 Likes

Thank you for the definition but a screenshot would be nice because it shows relay, subtraction and multiplication component missing. Please post a screenshot of your definition too.

Edit: I figured it out. Thanks for the definition and your outstanding work!!

For some reason in Rhino 5 it is not working even after plugging right. Kindly check and help. rectangles_V3-query.gh (37.0 KB)

1 Like