Clipping lines to keep only segments within a box

Replies to This Discussion

Permalink Reply by Hyungsoo Kim on November 18, 2015 at 12:10am

Hi.

Try to use "Trim with Brep" component.

Attachments:

• weave_clipping_question_re.gh, 21 KB

Permalink Reply by Bob Mackay on November 18, 2015 at 10:36pm

Hi There,

Thank you so much for pointing out the Trim with Brep - I had completely overlooked the Region subtab.  My Box Morph now works nicely and the pattern seems to join up from one box to the next reasonably well, although I seem to be having problems with getting the Absolute Tolerance units right to get things to join up correctly.

This is a huge plugin - I still find the discovery of components to be a problem and their help text to be insufficient!  Sigh!

On my way again though!

Best wishes,

Bob

Permalink Reply by Bob Mackay on November 20, 2015 at 9:10pm

Hi Again,

Just for the record, I attach the completed result of the sort of thing I was trying to achieve, making use of your Trim with Brep component.

The thing is a four-way weave pattern, with threads running in four different directions.  It is basically two normal weaves at an angle to one another, but with each thread occasionally diving through both meshes to form a loop on the opposite side, binding the whole thing together.

I am still having troubles: for some surfaces, the 'Morph and Join Lines' group in the attached .gh file generates lines perfectly, but the following 'Pipes' stage fails to make pipes out of all the lines, omitting a few.  This seems to be sensitive to the settings for Units >> Absolute Tolerance, which I was fiddling with in attempt to get lines to join up end-to-end better.  Strange.  It is OK in the attached file, but failed with other more steeply bent surfaces.

But enough for tonight!  Many thanks again.

Bob

Attachments:

• fourfoldweave3.5.jpg, 387 KB
• fourfoldweave3.5.gh, 28 KB

Permalink Reply by Pieter Segeren on November 21, 2015 at 4:38am

Hi Bob, I changed some order of operations to ensure your trimmed curves ends match up (well, at least with your example surface...)

Attachments:

• Bobweave.png, 1.2 MB
• fourfoldweave3.5_PSG.gh, 45 KB

Permalink Reply by Bob Mackay on November 21, 2015 at 10:00am

Hi Pieter,

Thank you so much for doing this.  As you can tell from the plaintive bleating above, I am still learning this stuff.  It is terrific to have people look at your work and to improve it.

I have been looking at exactly what you changed [I wish one could see two grasshopper windows at the same time].  I will try to explain what you have done back to you, so that you can see if I have understood!

When a pattern of lines is in a box and is to be used as a box morph to cover a surface, it is important that the lines hit the same point on the faces of the box on each side so that they will join up.  Without this they will not join at all. It is also important that the lines hit the faces at the same angle, so that they will join up smoothly.

What you have done is the fix the second of these problems: by delaying the Interpolate Curve until after the box morph you have arranged that the curves are continuous and smooth even across the different boxes.  This is a huge improvement!

I'm not sure whether I was also suffering from the first problem, i.e. that the ends of my lines were not close enough together to join up properly.  This would have happened if my (premature) Interpolate Curves had had the effect of also moving the end points of the curves, or perhaps altered the direction of the final segment of the curve so that it could not be joined with the curve in the next box.

I think that your moving the Interpolate Curve later should also have fixed this issue, if I had it.  Your Join Curves that follows the Box Morph is joining straight line curves, but perhaps the final segment of these lines are aligned at the point of joining.  Is there a maximal angle between line segments that would prevent Join Curves from working?

You also changed my Explode line segments to Discontinuity.  Presumably this halves the number of vertices fed into the Lines to Curves.  I see.

You used a PanelMinimal to document the constant '26', which reads very well.  How did you make this? I see nothing in the Panel configuration that allows a Minimal one to be made.

For background, this pattern was something I came up with back in 1985.  I attach pictures of an actual weaving done for a footstool.  Ten pieces of string!  It is wonderful to be able to replicate this graphically.

Many thanks again for your analysis and changes,

Bob

Attachments:

• DSCN2972.jpg, 202 KB
• DSCN2973.jpg, 201 KB

Permalink Reply by Pieter Segeren on November 22, 2015 at 3:02am

'Hi Bob, glad you like it. I didn't hear any bleating, in fact you showed that you were willing to get your hands dirty, and it brought you almost all the way to your goal. You also took time to explain your trouble clearly. Cudos for all that.

I think your translation to english is completely correct, you understood. And yes you had a case of non-tiling lines (ends not meeting). Could you rephrase "but perhaps the final segment of these lines are aligned at the point of joining", I didn't get that. There's no maximal angle for joining curves/lines.

The PanelMinimal actually is a regular Panel, of which I changed the colour and font, then made it as small as possible. This is than saved to a User Object, so it appears on my toolbar. It was meant to represent a single input value, and to be small and clear. But often it's too small (It trims "False" to "Fals " for instance).

In the attachment I put our versions in a comparison gh file  (and made another file where I put most of the definition up/in a tree, where I left the part of how you make the tile intact, because I don't quite understand that yet.)
I did notice some zigging/zagging going on in spots where there seems to be no 'need' to zig or zag...

Did you weave those stools Bob?

Kind regards, Pieter

Attachments:

• fourfoldweave3.5_PSG_compare.gh, 83 KB
• fourfoldweave3.5_Tree_PSG.gh, 36 KB

Permalink Reply by Bob Mackay on November 22, 2015 at 12:20pm

Hi Pieter,

Thanks for the explanations.  I now believe that the only problems with my line joining and curve making was doing it in the wrong order, which is what you fixed!

Putting both definitions into one file is a good poor-man's way to look at both at once.  Good thought.

I really like your approach to pushing the four separate colours of line into separate branches of a single tree and then sorting it out at the end with a tree of materials.  This is definitely the 'Grasshopper way'!  Nice.  I kept them separate because visualizing one at a time helped debugging and baking.

You are right about the three extra weave bumps.  This was deliberate, but technically wrong.  They are mostly invisible under the overpass thread.

I should explain the early stages.

I was initially not thinking at all about the box-morph thing, but was aiming to create a simple plane.  This was the cause of later problems, but more of that below.

The initial approach is to make a 6x6 grid of points and then to shift these points up and down in the z axis to define the different levels in the weave.  If you look at the Z-vector inputs to the weave, you will see that the values are actually an array of 36 values, between -5 and +5.  I should have 'extracted parameter' to make this more clear.  There are six possible levels: two for each basic weave and two more for the overpass threads.

The lines themselves run between pairs of points.  The magic here is also rather disguised.  In the 'lines' group, the Index input to the List Item sector is actually an array of 26 indexes.  Again, I should have 'extracted parameter' here.

These 26 lines are orthogonal to the axes, but I actually need four sets of threads all at angle to one another.  0.197396 is arctan 1/5, in radians.

The resulting pattern has a ragged edge, but working in a plane, this is fine; the pattern tiles properly.  I used the pattern to sweep out an ellipse and it printed nicely.  I attach a photo of a Shapeways print.

I then started to have ambitions to make a proper surface, using a Box Morph to distribute the tiles.  At this point the fact that my basic tile had ragged edges started to matter.  I wasted a lot of time trying to make the same tiling within a square boundary and then it dawned on me that if I simply doubled up the pattern to give a 2x2 shape and then clipped the middle out of it with a square boundary, that would be the pattern I needed.  I failed to spot the "Trim with Brep", which is where this thread began.

The trimmed pattern now reaches its bounding box faces correctly and can be used for the Box Morph.

As to the stool, yes, I did that myself.  It is the same weaving, but it had to be made by threading each string in from the ends, round the bar and back into the pattern again.  Because the threads go in four directions, you cannot use a traditional weaving technique - you need a needle to thread the string.  There are only 10 pieces of string. Tedious stuff!  I was stuck in Bruxelles for a year in 1985, working for SHAPE, and needed some mental relaxation in the evenings to keep my sanity!

Best wishes,

Bob

Attachments:

• DSCN2979.jpg, 203 KB
• DSCN2981.jpg, 200 KB

Permalink Reply by Pieter Segeren on November 23, 2015 at 4:05am

Shouldn'we then try to make it zig zag technically right Bob? (I thought the extra bumps were quite visible).
I had noticed your internalised lists, but I wanted to adjust it to make it more right-ish (eliminate the extra bumps).
The stool looks very nice and tightly woven. Looks to me like it's rather hard to make. I admire your craftsmanship Bob!

Kind regards, Pieter

Permalink Reply by Bob Mackay on November 24, 2015 at 10:40pm

Hi Pieter,

Sorry about the delay - I have a day job!

I changed the z-axis input to eliminate the unnecessary bumps... and it did not do what I expected at all!  It turns out that if you have three consecutive points at the same height then your 'Break at discontinuities' component eliminates the middle point completely and then the 'Interpolate Curve' component gives a much bigger bump in the wrong direction.  This was enough to get curves to meet from opposite sides.

I fixed this by changing the heights to 1.1 or 2.9, rather than 1.0 and 3.0, but it took a little while to work it out!  Sigh.

I attach a new version.  But I actually preferred it as it was before.  See what you think!

Bob

p.s. in the first list, elements 11, 12, 23 and 24 go from 1 to 3; elements 17 and 18 go from 3 to 1.  In the second list, elements 6, 17, 18 and 29 go from 1 to 3; elements 12 and 23 go from 3 to 1.  Given the above fix, these can be easily seen.

Attachments:

• fourfoldweave4.2.1.gh, 36 KB

Permalink Reply by Pieter Segeren on November 25, 2015 at 2:53am

Hi Bob, that's okay, we live about 11 hours apart... I think this is a step in the right direction, I like this a bit better (if I decrease the overal Z-Scale slider).
Thanks for the pointers. If I find some time I will try to adapt it a bit further (the long arches), not sure how soon I manage to get to it though~ Talk to you later.
Have a nice day:)

Permalink Reply by Bob Mackay on November 22, 2015 at 5:02pm

OK - I'm out!

Cleaned up a bit and checked against another surface!

Many thanks again to Hyungsoo and Pieter

Bob

Attachments:

• fourfoldweave4.2.gh, 28 KB