The default result in this case I get is this result (fig.2). It doesn’t seem to matter if I flip the surfaces & curves, etc. (my guess is that Rhino is generating the resulting surface in the direction towards the centre of the bounding box of the rail curves?)
What if I’d like to get the result on the other side (fig.3)? To get this result I use the SplitEdge command on the surface edge at the base point of the cross section curve, and used the split edge as one of the rails:
What if I want the result on both sides? I used the right hand edge of the resulting swept surface from fig.3 above as a cross section curve and used the two original surface edges from fig.1:
It seems like there should be an option the tool for picking which side of the swept cross section curve the resulting surface is created on (forward, backwards, or both) and being able to preview the results. It’s a bit of a mystery to me in any given case as to which side resulting surface will be generated. Over time the mouse miles are adding up.
Did I miss something basic in the tool? Any thoughts on a faster workflow?
This does not appear to be the case when one is using ChainEdges. When using ChainEdges it does not matter where one clicks, which is the issue I’m running into. As well, why can’t the final surface be on both sides of the cross section curve?
@pascal Thanks! Do you know if the not being able to pick the resulting surface direction when using the ChainEdges option (like you can when using a single edge) is a bug or is that the default behaviour?
I think it is a ‘limitation’ rather than by design or a bug - Lowell pointed out that you can control the direction if you do not AutoChain the edges for the rail - pick one by one starting at one end. Does that get you anything useful?
@pascal I haven’t been using Autochain and as far as I can see, it doesn’t matter where I click, the direction of the resultant surface is always the same:
Here is the example file as well: sweep1rail.3dm (733.7 KB)
Of course, there are many ways to work around the problem, but the original question is about efficiency. I was hoping like in so many cases with Rhino, there are hidden gems of workflows that I have yet to learn. I fabricated the above example as an absolute simplest, most basic case. But in situations where the set up is more complex, the lack of predictability in the results makes the tool less than efficient than it could be.
For example, what if in the case there are many possible edges on a polysurface and the profile curve is at an odd orientation? It’s a far more laborious case. Because the results from ChainEdges are not predictable, it becomes let’s see what happens and hope it works. If the results aren’t as expected, find a work around. It’s a core tool, and it often takes multiple times the effort to get the desired results as it probably should.
Perhaps by using _Dir you can analyze the direction(s) of surfaces and know the U or V direction and use the UReverse or VReverse option to change a direction to suit your needs and diminish guess work?
Thanks for taking the time to answer, but unfortunately flipping surface direction or reversing U/V directions doesn’t work. The direction of the surface edges for the rails has no bearing on the resultant surfaces.
