# Problem with Sweep2

Very interesting. It seems pretty clear that there are some differences between our GH versions, as well some quirks in the Rhino 6 version of GH that don’t exist in the Rhino 5 version.

What I’m trying to make is a nice even rounded top edge for my vase shapes. Right now the top edge is simply flat. This works ok for 3D printing but is just not very pretty.

I’ll check your latest post and see what I can discover.

When I use t instead of P I get this:

I really have no idea at all what’s going on here.

We made a lot of changes to the original code you posted. Several had to do with how the midpoint of the arc is defined and moved vertically, and they aren’t all consistent. I started making changes in version ‘c’, where I defined that midpoint as the Avr of the two start points and moved it in ‘Z’ as a function of the distance between the points instead of an absolute ‘Z’ value. This change, along with moving the seam on one or both rails, makes dramatic differences in Rhino 5 alone.

What does my version ‘d’ look like in Rhino 6 with point on curve set to ‘0.0 (start)’?

Here are images from your “d” version - I’l describe them as best I can.

This is the result with “Point on Curve” set to zero:

The arc should create the curved lip I’m trying to make, provided it stays perpendicular to the rail curves as it sweeps. However, this is what Sweep2 creates with this arc:

Changing the “factor” to a higher value raises the arc’s center point and makes a larger arc as expected:

I would never want a top lip shaped like this, but the big arc does produce results consistent with the little arc:

Changing the “Point on Curve” value to non-zero moves the arc’s endpoint as expected:

With this arc the results are very weird, but do make sense (sort of) based on the previous results:

It seems to me that Rhino6 has some sort of bug that loses or totally misconstrues the rail curve definitions. I certainly don’t understand why your “d” method produces results so different from my “bb2” approach; the only real difference is how the arc is constructed, and an arc is an arc, yes?

I can get a shape similar to that if I create many station curves and fail to flatten them… Reduce the division count to ten and disable ‘Flatten’ on the Swp2 ‘S’ input to see what I mean. How does this work when flattened?

Sweep2Bug_2018Feb26a.gh (34.0 KB)

This might be a clue to what Rhino 6 is doing wrong?

Here are results from your 26a file.

With Count = 100 (i. e., no changes to your code) this is the uncapped Sweep2 results:

With Count = 10, this is the uncapped geometry:

Why there is such a dramatic change of shape is puzzling indeed.

With Count = 10 this is the Capped geometry:

This is even more wrong that the uncapped version, which again suggests to me that the rail curves are being badly botched somehow.

I do understand the necessity that STL files have for closed Breps, and I take precautions to make sure that’s what I export from Rhino. But in the case of this lip geometry what I do (just to avoid extra computation time) is simply bury the uncapped lip edges slightly (0.1 mm) below the top surface to the vase geometry. So for my purposes capping is not required.

I had no such problems with Rhino5, which is where I developed the entire top lip concept. In Rhino5 my biggest problem was finding the inside and outside top edge curves. But whatever those curves turned out to be, Sweep2 always produced a nice top edge surface, assuming of course I had a reasonably shaped arc curve. I’d bet money on the fact that something in Rhino6 got FUBARed (Fouled Up Beyond All Recognition), but I guess we’ll just have to wait and see.

Sweep2Bug_2018Feb27a.gh (35.5 KB)

Oh my! That’s a new one on me - never heard of/saw/used that component before. Thanks for pointing it out.

How do you become aware of all these neat tricks anyway?

Does NetSurf work for you? I can get the ‘Count (N)’ input on Divide up to 312, then something breaks higher than that (Later: intermittent at higher and lower values). Otherwise, a clean surface, between the rails, Cap holes to “Closed Brep”.

This one divides a TweenCrv to try and smooth the bumpy transition points.

Sweep2Bug_2018Feb27b.gh (36.8 KB)

Divide ‘Count’ = 505:

when something fails what i do is looking at the help page, in the lower part are they are commands listet that do similar actions.

Joseph’s use of a Tween curve triggered some old memories of my work in an aerospace Loft Lines dept. So I came up with this solution which is even simpler than the one I posted in the new thread.

Sweep2Bugbb4.gh (22.6 KB)

And thanks to Baris for suggesting using the Help pages to learn about alternative methods. That is excellent advice.

Lifting and lofting the tween curve?

Sorry about that Joseph - it’s obviously something in the new version of GH.

Plus, upon close inspection I can see that the FitLoft does not actually adhere to its control curves:

Regular Loft works better but has nasty looking kinks at the corners:

Taking out the Seam adjustment fixes the Loft corners, but the resulting shape is looks like it has uneven thickness - even though the Loft matches the control curves.

This one divides a TweenCrv to try and smooth the bumpy transition points.

It’s not a great solution(not your fault). Tweens in general have issues with fillet curves (degree 2 curves with weighted control points). Zoom into the tween to see what I mean. The dividing smooths it but I think fitting both curves before the tween will let you not have to divide at all.

Interesting point Michael, but my Tween looks pretty good even at high zoom levels:

However, when I include the Loft surface I can see how it doesn’t fit the Control curves as well at it should:

Perhaps this is just a limitation of the software resulting from truncation/roundoff errors. I’ve dealt with that before and if that’s the case I know it’s not anything that I can do anything about. Practically speaking I think the errors in the Loft surface are so small compared to the size of the 3D printed filament I’d use to make the actual geometry that the mismatch would not be noticed.

But I’m glad I’m not building airplanes any longer.

From that image, you can’t tell where the surface really is. You are comparing a mesh derived from the surface with the input curves. Change the mesh settings and you will see something else.

OK, but what mesh settings do you mean? All the geometry is created in GH and none of it has been transformed to meshes. Plus the only mesh settings I know about are in Rhino, which I only use for exporting geometry baked from GH as an STL file.

What I am describing is not that. Degree 2 curves and fillets often do not tween nice because tween does not account for control point weights. Look at some other corners and the result tween control points (unless you are not using the same curve or have already fit / rebuilt it). It is not a display issue, it is an arc issue.

wim: Got it, thanks. I did not know “mesh” was the name used to refer to those parameters. I always set mine to High Quality, but never bothered to look at the actual values or try tweaking them. I am a bit surprised at how much detail there is there - and I’ll def. take some time to check them out. Some preliminary fussing suggests that the Loft surface really is OK in terms of meeting the control curves. So that is good news.

Michael - I see your point now, thanks. I understand the limitations of degree 2 curves (I call them conic curves), so I’ll see what I can do to make a better fit.