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.
@encephalon
Thank you for your answer, interesting.
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.
Sweep2 only creates a ruled surface if the section curve or curves are straight lines, ie degree 1 curves with 2 points. The surface in this thread is not a ruled surface.
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.
It is not about me, it is about learners that are experiencing this situation and are asking me to clarify things regarding one of the most used Rhino command.
The definition provided by McNeel for Sweep 2 is : The Sweep2 command fits a surface through a series of profile curves that define the surface shape and two curves that define the surface edges.
The ruled concept you mention is not included in that definition. This is exactly why I am asking here if someone can help understand better the WHY.
Regarding perverting the tool, I understand the POV but I do not totally agree.
When a tool is not well understood or explained, complementary informations or extra options may sometimes help to improve its use or contribute to choose relevant strategies ( as you wrote ).
I am not able to open your file because I use RH6 but I observed that you probably moved the Curve Seam of the bottom rail to the middle and rotated the top rail Perp to that location, correct ?
I tried that approach on my side and indeed, the resulting PolySrf still contains deviated IsoCurves but is closed.
May I ask you what is your perception of the underlying logic behind that behaviour ?
I’m not obsessed by creating such a surface at once with Sweep 2, I’m trying to understand how this command works internally to teach it the right way and provide clear answers.
The rails were unchanged (except for being moved. V6 version of my file: PolysweepDC01V6.3dm (1.4 MB)
Are you asking why there is a gap with the section at the kink? My guess is the developer did not envision that situation, or made a mistake in the coding. That is why I called it a bug.
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.
