Help needed for Sweeping a Rectangle profile

If you could explain the rules for the spiral itself it would help as well to come up with some logic. Or explain how it is constructed. I think the base geometry for construction will help in constructing the section curves too.
For example, the square you draw is perp to the curve but also seems to be aligned to an imaginary hull around the spiral. If you have this hull surface you can use it to align the remaining axis of the section.


Thank you for your answer.

Here is some additional information concerning the problem raised.

1 - Rule of the Spiral.

Freeform curve used as a guide to create a pipe with a square section.
Purpose : Metal casting.
Transformation Needs : MSR

Needed Tolerance for FAB : 0.1
Since the loss of precision after casting varies between 1 and 3 % for the intended purpose, it is necessary to be able to apply precise compensations on the profile at the CAD stage.

2 -The construction of the spiral

Since the shape of the guide curves has to be arbitrarily adjusted for purpose-related reasons, using a parametric spiral model does not seem relevant.

However, if it is possible to set up a spiral parametrically that can conform to two guide curves, this would make the implementation easier.
GH is probably one right path for this…

If we stick to Rhino, one way of creating of such a spiral from manageable guide curves could be focus on easy to control guide curves:

  • Create two clean guide curves
  • Find the average curve
  • Create a spiral around the averaged curve starting @ 50%
  • Rotate/Copy the resulting spiral
  • Use the 3 levels of control offered by the guides to adjust things if needed.

There are naturally many other ways to work around the creation of such a spiral with Rhino.
the method described by @encephalon is one such.

What must prevail is the ability to adjust the profile downstream.
This is why it seems relevant to me to focus on the behaviour of the profile on the rail as well as on the ability to modify the characteristics of that same profile in a second stage.

That the idea, yes.

While understanding this concept is within my grasp, I admit my inability to describe it in the form of a Python script.

Rhino not being parametric, I am facing a certain limit that can probably be crossed with GH.

As far as I’m concerned, not being skilled in coding, I don’t really have any other choice than GH or an existing plugin ( I really don’t like this way ).
But in the absolute, I have the feeling that a Python script would be a more transversal solution…

Rodolfo Santos.

in that case the attached might be a good approach:
Make the hull with loft
Use FlowAlongSrf to transform the spiral to the new hull
Use ArrayCrv (roadlike top) to make sections
Use FlowAlongSrf (rigid) to flow the sections to the transformed spiral
use Sweep1 natural, freeform to generate the transformed square spiral
note: for squares it works, but for trapezoid shapes, Rhino seems to flip the curves in the ArrayCurve

all can be done with History, so basically this makes the whole thing almost parametric, try to modify one of the circles used for loft (red) (not the left one) or the base section (orange) to see it update the rest
flow.3dm (471.5 KB)


Thank you very much for your contribution.

Sounds good except the non linear aspect of the general shape as described above.
Screenshot 2021-03-21 at 11.06.11

I will try to reproduce the described steps to check if there could be a limitation by sticking to the implicit history of Rhino.
Rhino will probably not allow to maintain the history relationship on the circles and on the surface at the same time.

Loft more the 2 circles may solve this…

*Too many nested steps involving the use of too many objects sometimes leads to cascading problems or to a solution which may not be very flexible tu use.

Don’t know why, but the file you posted crashed my Rhino 7 three times ?

Let me explore the suggested approach and I will give you a feedback.

Rodolfo Santos.

maybe I don’t understand this but I can still scale the mid circle non-linear and the shape stays up to date:

just wanted to add, that the sweep commands somehow handle the
the framestyle in an unexpected way: see this post:

please also notice, that the normal of the spiral is not pointing in the same direction as the normal of the (virtual enclosing) surface…

a spiral has torsion, so the resulting surface will also have torsion !


Sure, visually that sounds good…

… but I need to check if the resulting PolySrf is stable enough regrading the directions and compatible with the FAB constraints.

If this is not the case, we will have to increase the number of profiles ( again ) in order to obtain a better approximation.

Let me experiment this…

Rodolfo Santos.

This is why is was focused on the curve and not on a virtual skin which drive to a compromise.

a spiral has torsion, so the resulting surface will also have torsion !

I am well aware of this, but I must admit that the result obtained via Sweep 1 in Rhino is sometimes surprising. These unavoidable ‘twists’ seem uncontrollable at times, although I suppose there are methods to minimise this phenomenon but not with the native tools, right ?

Thank for you contribution.

Rodolfo Santos.

HelixSweep02_rh6.3dm (2.4 MB)

dear @RodolfoSantos … yes i agree that the sweep1 framestyle is not predictable … that is why i opend the above topic, but did not get the desired attention.
my workarround is, to copy the profile for many times (via rhinoscript) and then just loft the curves.

see screenshot / attachted file.
You will just find the result of the script, with some additional debugging-output:
the inital curve (blue) divided into 200 Points (blue)
the result (red square-surfaces) from CurveFrame
for all those 200 points
the result (green surfaces) from CurvePerpFrame
(which i did not use further, as i do not understand the rotation of the plane)

… the CurveFrame gives x-y-z vectors, “local cplane” if you want.
… within this the script draws 200 squares (or orientates 200 curves)
… the 200 squares / curves are lofted…

i may find time on Monday to clean the script and post it, so it can be used by others…

and if you use curvature-Analysis, make sure to set a custom mesh.

hope that helps - kind regards -tom

1 Like



By comparing this approach ( Curve based )
Captura de ecrã 2021-03-21, às 12.28.15
With this approach ( Surface Based ) from @encephalon

Or with this approach ( surface based ) from @Gijs

I see no real benefit in using a virtual skin to calculate the sweep as desired.

The main reason is that the initial objective is not achieved, i.e. to have a level of control over the starting profile adapted to the needs.

In one case there is no profile to work on.
In the other case , some adjustments lead to unpredictable results ( as pointed above ).

That’s why I think that Rhino’s implicit history seems to set certain limits regarding this specific demand, which a scripted solution would probably allow to overcome…

Rodolfo Santos.

Then we should find a way to catch more attention.
*I was not aware about the existence of your topic, thanks for pointing this out.

Sweep 1 is a frequently performed operation.

Increasing the number of profiles on a rail to hope for a better approximation should not be the only possible approach.

It is a race to complexity.

Let’s address the question more directly then.

Can anyone at McNeel help us to better understand how to proceed in such a situation ?

  • What are the possible solutions with the native tools ?
  • What are the recommended external solutions ?

Rodolfo Santos

Thank you very much for sharing this.

This is an interesting and exotic way of evaluating a curve (200 profiles ).
As I wrote doing this manually in Rhino is a race to the complexity, the use of a script makes sense.

I see

Planes ( 2 directions )
A ribbon Srf
A PolySrf

You would like to explain what is executed by the script and what is done by the user ?

Unpacking a given logic is always instructive.

Rodolfo Santos

1 Like

i was not sure, wether you just need a result (my fast guess) or an more general understanding - your last question … i will edit the post above…

Hi, I did not check all solutions…
Attached is a version where the twist is controlled by the curve curvature. As others already mentioned the point count of your curve is a bit low and the curvature at the ends is not so nice. However I think this would be nice to have in Sweep.
HelixSweep_jM.3dm (281.7 KB)


Thank you for sharing your file.

This curve was just an example to put forward the current scenario.
More accurate curves can be used naturally.

I start to see something emerging concerning the Spiral/Helix curve .

A :
Be able to reshape the guide curve used to calculate the Spiral/Helix curve that we may need to transform a bit ( FAB constraints ).

Curves with less points is the right path.

Sweep 1
More points is the right path.

Seems like there is a 2 step workflow emerging…

Simplicity is required to reshape the guide curves while complexity seems required for the Sweep operation.

I will check your file on another computer, I am using RH6 on this one.

Rodolfo Santos.

nice idea @Jess

attached is that concept in a simple gh file (12.3 KB)

1 Like


Thank you for sharing your file.

Curvature alignement is to my opinion an elegant way to manage the twist.
I still need to apply such a strategy to a project awaiting production, but Instinctively I think this is a valid and appropriate solution for the intended purpose.


What I see is that the input curve can be simplified with no significant impact on the accuracy of the resulting surface.

This confirm that a 2 step workflow makes sense as mentioned earlier.

Most important, the initial objective with this approach is achieved.
Adjusting the profile becomes easy and intuitive.

Less is more…

I vote for this one as well.

Rodolfo Santos.

Shall I publish a wish topic based on the existing ones + this thread ?

You may, but I’d bet that this will never happen :wink:
That is way too fuzzy since a curve may have zero curvature…

I would be happy if it were possible to model a super simple picture frame with the Sweep1 command like the attached sample. SimpleFrame.3dm (73.0 KB)

Yes, it is a legitimate counter argument.

Having a way to manage the twist is however a legitimate request.

If we compare the orientation of a profile created around a curve at the knot location with another profile created around the osculating circle (calculated at the same location), it seems obvious.

I admit that I don’t really understand which information leads to the twist applied on the red profile when using the AroundCurve option…

The result obtained from the osculating circle can be suitable in many situations.

Do you think that the GH solution provided by @Gijs could be written in Python ?

Rodolfo Santos.