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.
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)’?
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:
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?
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.
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.
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.
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.
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.