Making picture frames with custom profiles and randomly positioned reactangles

Hello forum,

Here is the thing, some area is populated with randomly generated rectangles that are sometimes rotated 90 degrees (this is important, keep that in mind, because it will cause a specific problem later) to fit more shapes that are otherwise won't fit in.

On the example below horizontal rectangle couldn't fit in but its rotated analog could and thus was placed in.

Later, when placed shapes are used to generate frames, because of this rotation, the position of the starting points changes and because of the approach I use to generate the frames some angle values are attached to the wrong corners, this brakes the frame shape and looks like this (on the left the frame of sick shape and on the right the frame of the healthy shape):

Again, this happens because the angle values are assigned to the specific corners (points) and previously rotated shapes get these all messed up:

Easy fix, don't rotate the shapes, problem is, I've already baked a good number of them for later use. I'd like to avoid regeneration because it takes a lot of time and without rotation I constrict the algorithm even more.

Better fix, use a different approach, this is where I'd like to hear suggestions and kicks in a right direction. Please take a look at my definition. It works but I have a feeling like giving an amputee a job of sweeping the floor.

Attachments:

Clumsy definition.gh, 25 KB

Replies to This Discussion

Permalink Reply by Joseph Oster on December 9, 2015 at 9:46am

Well... It would be nice if you didn't use Kangaroo ('removeDuplicatePts'). I replaced where I guess it was used with the native GH 'CullPt' (Cull Duplicate Points) which appears to allow the code to function:

I was able to see the mis-placed miter curves causing the twists in some frames and, re-reading your post, was able to see that untwisted frames all had their start/end point at the bottom right corner of the rectangle. Those that did not were twisted.

So I thought about reconstructing your rectangles so they would all have the same relative start/end points... And while looking at that, realized what 'removeDuplicatePts' was doing - the 'Explode V' (Vertices) output gives duplicate points for start/end.

So instead of that, I used 'Disc' (Discontinuity) which returns four points instead of five for rectangles. And lo and behold, connecting 'Disc' directly to 'Item' fixed your problem!

Voila!

Attachments:

Clumsydefinition_2015Dec9a.gh, 23 KB

Permalink Reply by Tim on December 10, 2015 at 1:17am

Hey Joseph,

So I thought about reconstructing your rectangles so they would all have the same relative start/end points...

Yes, this is what I had in mind but didn't know how to implement (like how to tell the machine to forget everything and treat rectangles equally, no matter how rotated they are XD)

Thank you for introducing two new components, have never stumbled upon them in my practice, nice.

However it doesn't fix the problem for me, yes it does find just 4 discontinuities, yet it still uses original rectangle's seam as a starting position. After the rotation, machine keeps the original seam position in memory instead of moving it to top left corner.

I know that I need to make the rectangles have their seems moved to one specific position after the rotation is done, but how, machine has no idea where is top left corner or what do top or left or corner words mean. When it does we should start worrying about our future XD.

Permalink Reply by Joseph Oster on December 10, 2015 at 6:32am

The frames look perfect to me using the code I posted. I don't understand the problem? Maybe I'll look at this again later, after coffee - or maybe not. If you're happy with Peter's "Dark Side" approach using C# then maybe you're done? I have absolutely ZERO interest in even looking at Peter's code because as far as I'm concerned, it has NOTHING to do with Grasshopper and you won't learn a damn thing from using it.

Permalink Reply by Tim on December 10, 2015 at 6:50am

Hi Joseph,

I used your definition, but it didn't work for me:

I understand, at this point it is only up to you if you help me or not with this one, everybody has their own everyday life after all.

I'm slowly inclining to the regeneration solution that I wanted to avoid so hard in the beginning, I can cheat there and still get away with OK results, it is just not my stile.

Have a good day.

Permalink Reply by Joseph Oster on December 10, 2015 at 7:37am

OK, sorry, guess I didn't look closely enough. It fixed some and broke others.

Here's some code that sorts the points by 'Z', then by 'X', then swaps the last two points in each rectangle. Seems to work for me:

Attachments:

Clumsydefinition_2015Dec10a.gh, 22 KB

Permalink Reply by Tim on December 11, 2015 at 12:42am

Hey Joseph,

Thank you for the help, yet again, sort points is a new component for me. This is what I like about GH so much, multiple ways around.

Speaking of which, I had an idea when I've got home yesterday. If you are interested, check it out, also works beautifully.

Well, guess regeneration threat is officially averted, wohoooo!

Thank you all for your time.

Attachments:

Clumsy definition returns.gh, 29 KB

Permalink Reply by Joseph Oster on December 11, 2015 at 6:35am

Glad you figured something out, though your method looks a little indeterminate to me? I'm surprised it always works.

I was aware that my sorting method will fail if the frames are in or parallel to the 'YZ' plane because all the 'X' values will be the same (warning!). So spent some time trying to think of other ways similar to yours, including creating the plane the points are in. I'm sure there's a better method that won't ever fail but I didn't find it in the limited time I had.

But whatever works, eh? Cheers.

Permalink Reply by Joseph Oster on December 11, 2015 at 7:33am

P.S. Looking at the code you posted with both your version and mine, I see a difference between the two. Mine are inside out! They weren't that way in the code I posted... But that is easily fixed by removing the 'Reverse' from the 'Item' output after 'Sort Pt'. You must have changed something somewhere?

So many ways to get the job done.

Permalink Reply by Joseph Oster on December 11, 2015 at 10:37am

By the way, it must be remembered that because these are rectangles, the four points for each are not in random order - so strictly speaking, it would be more appropriate to SHIFT these points instead of SORT them. And even that might not be necessary if the rest of your code were written differently...

I believe the problem here is caused by the assumption implied by the sequence of four 'Orient' and 'Rot3D' components, each with a fixed angle input. Can't help wondering if there is a better way to do that? Like using just width and height of each rectangle to create the lofted frames, then orienting them to all those points in space (a requirement I still don't quite understand...).

But hey, it works now so it's academic. When faced with similar problems, I have often found it effective to create scaled copies all in one place before moving them to their final location.

Permalink Reply by Tim on December 15, 2015 at 9:39am

Hi Joseph,

Sorry for late reply, had unexpected something. So let me go one by one.

Glad you figured something out, though your method looks a little indeterminate to me? I'm surprised it always works.

So do I, I found the flaw and it fails on a big scale XD.

I was aware that my sorting method will fail if the frames are in or parallel to the 'YZ' plane because all the 'X' values will be the same (warning!)

And it did.

I'm sure there's a better method that won't ever fail but I didn't find it in the limited time I had.

Yeah, I figure it out, so far all 9600 frames were baked properly.

You must have changed something somewhere?

Yeah, I must have tweaked it and saved it as it was. Sorry, my bad.

I believe the problem here is caused by the assumption implied by the sequence of four 'Orient' and 'Rot3D' components, each with a fixed angle input. Can't help wondering if there is a better way to do that?

Yeah, I wish there was a better and more parametric way of doing that, guess this is where some coding would be really helpful. So far I made it work flawlessly. Maybe I will try to improve the whole definition later on.

But hey, it works now so it's academic.

Totally, Peter helped me realise why such approach and methods I used may cause hypothetical clients spend gazillions on realizing it. The project was very interesting to work with and I've learned a lot. And thank you and this forum for incredible help. I'm going to keep my work on it, it is not finished yet, maybe you will hear from me soon XD

Method I used works like a clock (literally)). I build an arc from the rectangle's centroid and the first point it encompass becomes THE first point in the list, then second point becomes #2 etc, so it should work with any polygon. And all the points get rearranged sequentially.