Sweep1 Roadlike Top?

David, can you please post an example file and the steps you follow to get something different than what the docs say?

@lowell, can you chime in on this? The documentation in question is Sweep1 | Rhino 3-D modeling

The binary is the rail.
Ciao Vittorio

Hi David
Roadlike top has always worked well since 1997. I do not see why suddenly this command is confusing to you as it has never caused confusion to someone
Ciao Vittorio

Hi Vittorio-
Actually, this is not true- it’s been asked about a number of times and it is always hard to describe. Not that it is not useful but it is not very clear exactly what the constraint is.

-Pascal

Brian, here is an example, using ArrayCrv, which presumably does the same thing as Sweep1 with Roadlike (?)

RoadlikeTop.3dm (216.3 KB)

The line starts out in the Top CPlane and does not stay parallel to it; Help says

The shape curve maintains its angle to the Top construction plane throughout the sweep.

-Pascal

Interesting. That does look like a bug - either in the implementation or the documentation. Lowell did write the command, but the low-level sweep code was written eons ago by @dalelear.

Hi Brian and Pascal
This example shows why Sweep1 Roadlike top is Ok.
Ciao Vittorio
Roadlike_Top_5.3dm (2.5 MB)

David, can you please post an example file and the steps you follow to get something different than what the docs say?

@brian I included an example in my initial post.

Sweep1RT.3dm (170.9 KB)

The attached example has a simple shape curve/section curve and a simple rail curve. The surface in layer Sweep1RT (white) was created using Sweep1 with the Roadlike Top option. The section curves (V isocurves) do not have the same angle to the Top construction plane.

The results of Sweep1 with the Roadlike Top option should look like the surface in layer Surface2 (green). The V isocurves are identical in shape to the section curve and they all have the same angle to the Top construction plane. This surface was not created using Sweep1.

@brian Repeat of an earlier post with two modified versions of the initial example.

Sweep1RT Example B.3dm (255.4 KB)
I modified my original example by rotating the rail curve so that it is not tangent to the Top CPlane but the profile curve is still normal to the rail in Top view with the top part of the profile curve still horizontal and normal to the rail. The top portion of the sections are horizontal when Roadlike Top is used.

Sweep1RT Example C.3dm (174.8 KB)
Then I modified the example by rotating the profile curve so that it was no longer normal to the rail but with the top portion of the profile still horizontal. The top portion of the sections are not longer horizontal when Roadlike Top is used.

So it appears that when Roadlike top is used horizontal portions of the profile curve which are also normal to the rail remain horizontal. This may not hold for non-planar profile curves.

Vittorio appears to prefer the “constant thickness” version which is what Roadlike Top current does provided the profile section is planar and in Top view appears to be perpendicular to the rail. That can be useful. However it is not what the documentation currently describes. The sections are not perpendicular to the CPlane. If this is the desired behavior then the documentation needs to be revised.

Perhaps there should be two sets of options. One set being the current behavior, and the other set being what is currently described.

1 Like

I agree there should be two sets of options
Ciao Vittorio

Yes. The documentation is wrong in my opinion.
The “angle” (orientation) of the propagated shapes changes according to the rail direction and doesn’t stay parallel to any reference plane.

Frames are made along the rail and used to orient the shape curves at those locations. In the simple case with one shape, a frame is made at the shape location and another where the made-up shape is going to go. The 3d rotation between those frames determines the rotation of the shape curve to its new location.

The Freeform and Roadlike options determine how the frames along the rail are made.
In the current example of Roadlike Top, The frames are made by rail tangent cross normal of the “Top” plane - World Z.
The other Roadlike options work like that with other planes.
Freeform generally uses rail tangent cross rail curvature direction.

In many cases, the resulting surface is the same with all options.

Lowell discussed this issue with me today. The low level code is correctly calculating the answers it is designed to give. From my understanding, the issue is that we could do a better job of automatically selecting the appropriate input to the low level calculations so users get the “expected” answer.

In the case of helices and spirals the calculation should use a “roadlike” sweep with the vertical axis equal to the axis of the helix or spiral. In the case of a planar curve that is not a line, the calculation should use a “roadlike” sweep with the vertical axis = normal to the plane. In the case of a nonplanar curve without an obvious axis, we will have to ask the user for some guidance and try to do a better job of making it easier for the user to select appropriate settings. Lowell is considering what to do next and is checking some bugs to see if there is something the low level code is doing incorrectly in a few limited cases.

It’s very good to see this being worked.

Edit - paragraph removed.

Users need to have the option of the vertical axis being normal to the selected CPlane, including for planar rail curves and other rail curves with an “obvious axis” which is not normal to the selected CPlane.

As I said above, the docs are wrong or incomplete or something for the roadlike options. They don’t describe what the command does or is intended to do. That’s something for us to fix.

I’m not sure I understand what you mean by
"vertical" axis which the profile revolves around during the sweep. Except in very special cases there isn’t a single axis around which the shape revolves.

In the roadlike options there is an axis used in calculating a 3d rotation for the shape, and the axis does stay constant, but the result of the calculation also depends on the direction of the rail which usually doesn’t stay constant.

My apologies for the confusion. I edited my post above and removed a paragraph.

There should be an option to make a radial sweep. That is a basic CAD surface creation function that is missing in Rhino.

In Rhino you can make a thread form that follows a helix and stays oriented to the helix axis, but you can’t make a thread form that follows a spiral and stays radial oriented to the spiral axis. That’s an option that should be there.

Jim,
Can you show me what you mean about the spiral?
I must not understand.

All you have to do is create a thread profile using a helix and then using a spiral. Assuming the thread profile starts out in line with the axis, the isocurves of the helix based surface will remain oriented toward the central axis while the spiral will
twist. I’m not claiming this is wrong. I’m saying there is no automated way to do a proper radial sweep along a spiral in Rhino. Radial Sweep is a missing feature that other CAD programs have.

The sweep1 roadlike option produces a radial sweep when the path curve is circular when veiwed from the cplane plan direction. For any other curve that is not circular (when viewed from the cplane plan direction) the resulting surface will not have isoparms kept in line with the axis.

Rail revolve is another tool that behaves similar to a radial sweep. Rail revolve keeps the interpolated profiles oriented correctly to qualify as a radial sweep but it scales the profiles based on the distance from the defined axis instead of sweeping the profiles along a path.

Radial sweeps have been included in CAD programs for many years because they are important in defining the geometry of things like augers, centrifugal pumps and turbines.

Ultimately what we are talking about here is what rule is to be followed for orienting the intermediate profiles that are created before all the profiles are interpolated to create the result surface.

Thanks. I see what you mean.
It looks like we need an arbitrary axis direction instead of just top, front and right.
Its pretty hard to recognize a spiral by looking at the shape.
I guess we could flag spirals and helixes made with our commands and align with their axes.
Other than that we’d probably have to ask for an axis
Not sure really how this would work out, but it looks like it would be worth a try.