You can also use other criteria, for example, a) you can look for largest possible rectangle with straight lines for other segments; b) rectangles closer to an attractor point and strips (long thin rectangles) further away,c) a rectangular tile packing after Laurent, and others.

Back to the straight line case, there is also another component, “geometric regions” which takes curve inputs and will give you closed curve regions (part of ‘Heteroptera’ plugin )

# Divide surface based on corners

Or look for minimal number of rectangles that will produce the input contour.

have done this before using heteroptera… its ok for now

div_srf_2019Jun16a.gh (19.3 KB)

Arbitrary perimeter shape:

Even curved edges! Wow.

P.S. Later… Re-posting the same code *(below)* only to add the two other internalized examples of perimeter curves, shown above, and to illustrate an interesting way of working with them “live”:

div_srf_2019Jun16b.gh (17.5 KB)

I baked `Crv3` *(the perimeter with curvey edges)* and exploded it in Rhino to seven segment curves that are imported to GH via the `Crvs Rhino` param and `Join`, before their control points are turned on to make them drag-able. So dragging control points to reshape the seven perimeter curve segments is (not quite immediately) reflected in the GH model as a new internal division pattern.

This is some legendary work that too on a weekend. Thank you very much for the definition.

Gilbert Tessellation could also be a way

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 !

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.

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.