Flat blank from 3D ribbon — devstrip_equal.gh adaptation issues

Hi there, I’ve created this ribbon centering around a 3D line.

The idea is having a straight strip when it is unrolled. To be able to do that I converted it to a one-quad-wide quad mesh which looks straight when I use the Kangaroo unroller — as seen in the second image, it seems almost straight. However, after converting back to NURBS and unrolling, the result turns out it is not straight.

I tried to adapt @DanielPiker’s devstrip_equal.gh (shared in plywood-strips-twisting-and-bending-simulation) to my strip, though I might have interpreted something wrong because the result went worse :sweat_smile: as seen in the third image.

I’m opening a new topic since that original thread ended with an unanswered question three years ago.

Would be great if anyone has suggestions — what’s the correct approach to get a truly straight flat blank from a ribbon wrapped around a 3D curve?

GH file attached.

FREEFORMRIBBON-UNROLL_W_KANGAROO.gh (54.3 KB)

Thanks in advance,
Kamil Kaptan

Hi Kamil,

Firstly, the 3D curve has to be a geodesic, which is basically the shortest path from a Start Point, A, to an End Point, B, across a surface. You can explore this by using the ShortPath command in Rhino, or the Geodesic component in Grasshopper.

The Geodesic component, for example, has 3 inputs, S (Surface), S (Start Point), and E (End Point). If as a quick test you input your 3D ribbon as the Surface and then use the Start and End Points of your 3D curve for the other two inputs, you will more than likely find that the geodesic doesn’t match your 3D curve (and probably doesn’t even fit on the width of the ribbon), which would be why you are discovering that your ribbon isn’t straight… because it isn’t(!).

If it helps to understand this better, you can think of a geodesic as being a ‘straight line’ across the UV space of a surface; just as there is only one possible line between two different points on a plane/flat surface, so there is only one possible geodesic across a 3D surface. In order to end up with a straight ribbon when it is unrolled on a flat surface, you have to start with a geodesic, which can be thought of as the centre line of a flat ribbon that has been rolled over an undulating/3D surface.

Hope it helps.

Hi Jack, thanks for the reply! I understand the geodesic concept, but my case is a bit different — I’m not starting from a surface and finding a geodesic on it. I’m starting from a 3D curve and generating a ribbon around it, then trying to find the correct flat blank that would bend into that shape in real life (1/16" laminated veneer).
The interesting part is that Kangaroo’s mesh unroller gives a nearly straight result, but converting back to NURBS and using Unroll doesn’t. And adapting devstrip_equal.gh made it worse.
Feel free to take a look at the GH file if you’d like — would appreciate any thoughts on what might be going wrong in the setup.

We need to distinguish between:

  1. A developable strip centred on a given curve, which can be unrolled to flat without any stretching.
  2. A strip which meets condition (1) and is also straight when unrolled.

I’ve posted about ways to achieve (1), and this could also be approached through geometric constructions, such as (Tangent developable - Wikipedia or All you need is rotation: Construction of developable strips) but for general space curve inputs, these strips will not unroll to straight.

I’ve not looked at achieving both 1 and 2 simultaneously for a given input curve, but my intuition is that this is not geometrically possible for general space curves.

Thanks for the reply, @DanielPiker, and for the Maekawa & Scholz reference — I went through it and the φ parameterization gives me a much clearer picture of what I’ve been doing implicitly.

For condition (1), I’ve been generating the 3D ribbon around a space curve using the Darboux frame (effectively fixing φ ≈ π/2, rectifying developable), which has worked well enough in practice on an earlier side table project.

For the new project I wanted to push closer to condition (2), which is why I turned to Kangaroo — in your devstrip_equal.gh, I can see the rulings redistribute while the solver runs (starting perpendicular and evenly spaced, ending at varied angles and spacings). Reading it through (15) in the paper, letting the rulings rotate is effectively letting φ (and dφ/ds) vary along the curve, which couples κ_g, κ_n, and τ_g together — so a single-sided setup where only the rulings are free can’t find equilibrium on its own. The centerline curvature has to be free to adapt too, and the developability constraint is what links them. I think that’s why your solver converges where mine doesn’t.

My own setup made this worse: I was driving the mesh toward a straight rectangular target built from centerline length and ribbon width, but the actual mesh unroll isn’t straight, so the target was fictitious and there was no real path for the solver to follow.

The practical piece I can’t figure out in Kangaroo: which goal(s) let the ruling endpoints stay on the edge curves but slide freely along them during relaxation? Any pointer would be really helpful.

Thanks,
Kamil