I’d like to understand why Rhino can’t execute a valid closed sweep2 based on these curves because I am not able to give a logical answer to those who are asking me where this unexpected behaviour comes from.
All curves used with Sweep 2 are Degree 2.
1 - 2 - 4 curves does not help.
Rhino for Mac - Version 6 (6.34.21034.07002, 2021-02-03)
Honestly, I don’t exactly now why this doesn’t work, but I’ve encountered it before in different scenarios. If I had to speculate, I’d guess that it’s probably not possible to create the exact surface that you desire and would be necessary for the precise seam placement with the Sweep2 command, since it creates ruled surfaces. The first section and intermediate curves set certain parameters that the algorithm needs to interpolate between, but for the last curve, it needs some leeway to even get it done as a ruled surface.
For your example, there is a simple workaround though! Simply explode the bottom polycurve, and split the top circular curve with the section curves.
Now, you can Sweep2 in sections, either from top to bottom (or vis versa), or from left to right (or vis versa). The resulting surfaces can then be joined into a polysurface (or brep).
Work around a problem is naturally always a possible option and what you suggest is what I already did.
But what is really questioning me is the WHY.
Without a good understanding of the logic ‘under the hood’, it is hard to explain that behaviour to people pointing that problem during a training, a demo or a course.
Bug or inaccuracy are the words they use.
I don’t like to hear it and would like to be able clarify things but I confess I am lost here.
i boldly guess it has to do with the parametrization of the surface. since sweep does not know that you want the isocurves to match up with all the joined kinks or creating a finished boarder there, trying to finish the sweep in one attempt. @pascal might have an idea why exactly, i believe i saw such a case being discussed at some point.
if you use a simple ellipse as below, the result will always be a closed sweep. anything diverging from that ideal situation will cause a mess.
Then, if Srf parametrization is the main reason, implementing a ‘Matching’ option for ‘kinky’ rails could help, this scenario is not a rare situation.
Being forced to do in several steps what could be done in one pass can be frustrating.
I played with a massive interpolation to check how is reacting the generated surface seam, the more the sampling is growing, the more the Srf seam becomes accurate ( but never valid ).
On the other hand, the complexity of the resulting Polysrf is stable.
Here’s a test with 3000 sample points placed on the ground rail.
It doesn’t seem to be a bug, since what you’re doing is probably only against the nature of a ruled, untrimmed surface, as I already explained above. This is also why improving the Sweep2 command - which is meant to produce ruled surfaces - just to make it work for your case, would probably only result in perverting the tool itself.
Only because you have a hammer - in this case the Sweep2 command - does not mean that everything should be regarded as a nail, or something like that.
As I also mentioned above, your desired geometry looks more like a polysurface, which would be composed of a set of surfaces, not a single, ruled one.
You simply need to chose your strategies or tools more carefully. Not everything is meant to be done in one go.
Thanks for the shared file.
Playing with the Add Slash option helps to improve the accuracy to the resulting PolySrf.
Sometimes it works and sometimes it does not works depending on the scenario ( Kink is a key point here )
At least, your inputs are helping me to accept that there are situations to avoid when using the Sweep 2 command.
I would also classify this as a bug, if you explode the resulting polysurface and then do a positional MatchSrf of the last surface edge to the first (where the gap is), you get a good result - Sweep2 should be able to do this automatically.