# How many curves do you see?

Does it look like 2? It does to me. But noooooo…it’s only 1!

Do my eyes deceive me? Apparently yes is the answer!!

Geo1 is my base geometry; it is a nice Closed Brep that looks like this:

I want to cut off the top points so it’s top is a simple flat surface. I’ve done this many times with no problem like this:

1. Split the base geometry into 2 parts. One of them will be what I want - in this case it’s the bottom part.
2. Get the top 2 naked edge curves from the bottom part and use them to make a ruled surface.
3. Join the ruled and bottom surfaces to make a closed Brep.

But for this base geometry that does not work.

Yes, I understand the Join Curves component adds an extra piece to the process, but it seems to do the right thing - it outputs the 2 edge planar curves I want. Except - GH says there is only 1 curve.

Boom! An IED just blew me out of the water.

Yes, I tried rebuilding the curves. And I tried SDiff instead of Split. Results are exactly the same.

Is there another method I can use to trim off the top and get to a closed Brep?

PS: I’d like to do the same to the bottom.

why1.gh (7.8 MB)

1 Like

The curve has a self intersection.

Your closed brep is overlapping on the seam.

1 Like

Aha! Thanks Martine - I just never zoomed in enough to see that. And you are 100% correct - I had to gimmick the seam because I used SrfMorph to wrap the rectangular array of cells around the base loft surface. When I used the default values for U, V, W there was a large gap, so I tweaked the upper V value to close it. Obviously I closed it a tad too much.

I thought of another way to deal with this problem, and that is to trim the initial hex array of Truchet tiles before morphing them. I’ve managed to do this, so I’ve got a nice closed Brep with smooth top & bottom edges to wrap around the Loft:

But when I do that SrfMorph “remembers” the original, untrimmed array, and the result is the same as morphing the original array and not the trimmed one.

I vaguely recall an old post here that talked about GH somehow retaining the original definition of trimmed or split geometry, even though on screen it looks like one would expect. If that is in fact true I wonder if there is a way to get around, or a way to force SrfMorph to use the trimmed version and not the original one.

The story continues…

Some time ago someone here was nice enough to create a very simple GH C script named Shrink that shrinks a trimmed Brep down to it’s actual trimmed shape, and not the original untrimmed one. It does this with only 2 lines of code:

S.Faces.ShrinkFaces();
T = S;

I put this into my GH file and this is the result:

Note that the left and right edges end up as the top and bottom edges of the morphed array. I need a flat bottom edge to be able to 3D print the final geometry. (The image I posted in my previous post is wrong - in that one I trimmed off the 2 edges that make the morph’s vertical seam because I didn’t know SrfMorph would reverse the alignments. This time I trimmed off the left and right edges.)

This is what the top and bottom edges of the morphed array look like after running the trimmed array through the C module and morphing it onto the base geometry:

Compare this with the top edge:

Those little points on the bottom edge are enough to cause this slicer error:

I have no idea why the bottom edge isn’t smooth/flat, considering the trimmed Brep is. But the problem is easily fixed by using the slicer’s Cut feature to simply cut off a tiny portion of the STL file bottom to make it flat. The result prints just fine.