The attached GH file makesa Sweep2 operation using 2 closed curves:
For some reason the sweep is not where the 2 rail curves are. I tried rebuilding the curves, but the rebuilt ones don’t match the originals closely enough, even with 200 control points. I used the rail curve ends as ends for the sweep arc, so that can’t be the problem. Or can it?
Sweep2Bug.gh (22.8 KB)
Seems to be a rhino6 + GH1 issue. @DavidRutten @pascal is something going on with sweep 2 in Rhino6 or GH1?
In Rhino 5 works fine:
In Rhino 6 I get the results you got:
Thanks for confirming it’s not something I did wrong or some bug unique to my system.
Looks fine to me in Rhino 5. Aligning the seam of one to match the start point of the other (Crv CP) might help? The arc station curve is angled between the two rails instead of perpendicular, Top view on left.
Obviously doesn’t explain the Rhino 6 scale issue, but still…
Gosh Joseph, I’m not sure what to make of this result:
I appreciate your thoughts about the seam, and I noticed how the arc is not perpendicular to the rails curves too, but the net result of your updates is really weird.
I don’t have Rhino 6.
I see this if I push the ‘Z’ factor to 10 on the Arc ‘B’ input:
Scale of your Rhino file units vs. mine?
Impressive results for sure - not that I understand how or why they are occurring.
All my geometry comes from GH - I never use Rhino to initialize anything. So I don’t think my Rhino units play a part in this - but they are set to mm and I did set the default Rhino template to Large mm objects (or whatever it’s called.)
I could sort of begin to understand the problem if the Sweep2 object were centered, but it is offset in some strange way that makes no sense to me at all. What I posted was just a part of a larger GH layout, but all of it is centered on the 0,0,0 origin.
Here is another data point… accidental discovery. Looks similar to yours? Good when point on curve is at or near the start point (“0”) but gets weird at higher values, further away.
Maybe better doing it the first way, adjusting the seam only on the ‘Inside’ rail (1) and leaving ‘Outside’ direct as rail 2. Wow, again “interesting” when away from zero even on just one curve…
That is interesting. Here’s what your last definition looks like on my system:
Close to yours but not quite the same. Plus it does have some wrinkles that shouldn’t be there. I’ll fuss with it and see what I can figure out.
Thanks (again) for your help.
This is better, but still not quite correct:
Attached are my tweaks to your last file. It looks like the sweep arc behaves more or less OK when it is perpendicular to the rail curves. “More” means it does follow both curves all the way round, and the resulting sweep surface is in the right place. But “less” means the sweep arc does not remain perpendicular to the rail curves as it sweeps. Consequently the resulting sweep surface is fat in some places and very thin in others. This makes it unusable since the shape is supposed to be the top surface of a vase shape.
Your last post did show me a great feature that I was totally unaware of - and that is that the List Item component can be zoomed in and have additional outputs added on the right side. Now that I know about this I can replace a bunch of duplicate List Items with one in quite a few of my GH files. I wonder how many other people are unaware of this clever capability.
Sweep2Bug-bb2.gh (28.6 KB)
When I open your ‘bb2’ version, I see a pinched sweep:
That goes away when I use the Crv CP ‘t’ (instead of ‘P’) output for the Seam ‘t’ input, as intended.
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)’?
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?
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.
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.
Divide ‘Count’ = 505:
