UnrollSrf broken?

It seems Unrollsrf is seriously broken!
I can unroll an obviously doubly curved surface: BrokenUnroll.3dm

Please have a look at this and tell us how to work around this!
Unrolling surfaces is a critical part of my workflow.
I no longer have V4 installed here, could someone test the UnrollSrf in V4 please to see what that does with this surface.


Hi Willem,

In Rhino 4 the usual prompt of ‘Unrolling doubly curved surfaces will produce inaccurate results.’ appears. I’m not sure why this surface is seen as a not doubly curved at the moment and will file this as a bug now (RH-19867). A portion of a sphere for instance doesn’t work as usual still in Rhino 5. Thanks for this report. I assume you don’t want to unroll this surface but noticed that it was working in error. Is there a model that is unrolling incorrectly with unrollsrf that should work as well?

Thanks Brian,

I have not run into that issue (yet).


I did a couple of tests here and at least in this case, it appears that a surface will unroll (even a doubly curved one) if the distortion is less than a certain value. As the example starts to refuse to unroll pretty much exactly when 5% is reached, I suspect someone put a “cap” in the programming somewhere… I can repeat this with other surfaces.

@lowell, can you please take a look at this?

Doubly curved surfaces up to a limit will unroll.
The way that limit is defined has changed some over the years to try to respond to what people wanted and expected.
Its a relative tolerance test and works like this:
If in at least one direction the surface is within 10% of straight the surface will be processed.
The direction assumed as straight is the one with the least relative deviation from straight - least deviation / length. (The surface in the example is within 10% of being straight).
The tolerance is looser in v5 than v4 as a response to requests.

Its very common for people to want to unroll surfaces that aren’t really developable and if the test needs to include a tolerance. Even if a surface is linear in both directions it may not be developable.

I’m sometimes amazed at the things people run though UnrollSrf and I guess the surface in the first example is not a real case, but used for illustration. Things looking about that unlikely (to me anyway) have come in with bug reports about UnrollSrf not working right.

When a surface is unrolled, the difference in area is printed if its at all significant so that when you see that warning, you can check if what you did makes sense.

I’ll connect the tolerance used to the Document Properties Relative Tolerance setting so that you can control what UnrollSrf will accept and see if that works for people.


Hi Lowell,
If you’re going to introduce a specific user tolerance setting here, I would prefer that it be accessible on the command line directly in the command…
Cheers, --Mitch


Hi Lowell,

I’m a little taken aback by the apparent loosening of the tolerance.
First to quote the Help file on UnrollSrf

UnrollSrf command
Flattens ( develops) a surface or polysurface with curvature in one direction to a planar surface.

Yet if I understand your wording correct the above statement is not true. It should read something in the line of “Flattens a surface that is about 90% flat in one direction”.

What strikes me as odd is that a tool with the purpose of flattening developable surfaces had a relative tolerance of 10%. It renders the tool useless for production purposes. I wonder what sort of requests were made to justify the loosening to such high tolerances. Those might have been for users modeling kit bags, not ship hulls. @heath Could you shed some light on this, you are an expert in (un)rolling sheet-metal and wonder if you use UnrollSrf for this and if a tolerance of 10% is acceptable.

I understand there is a need of some tolerance to allow for (nearly) 0 curvature in one direction to be met, but this needs to be an in command option. The way UnrollSrf is currently setup makes it no longer reliable to me. I will see what squish can do and otherwise I need to install V4 again just to have a (more) reliable way to unroll surfaces.

Note that many times I use UnrollSrf as a means to check the validity of a design that is to be made in sheet-metal. In some cases I script UnrollSrf so I need now to add extra double checks to validate the surface has actual 0 curvature in one direction.

Forgive my ignorance, but how is the 10% determined? The example surface clearly has a bump that is absolutely not developable, regardless of the rest of the surface being flat or not. If UnrollSrf is not able to catch such local 2-way curvature spots it fails at being a tool to unroll nearly flat surfaces.

Finally the question that is most important for now:

  • How can Rhino V5 reliably only flatten surfaces that have no curvature in one direction?
  • How can I check that a surface has no curvature in one direction?


Why, thank you for referring to me as an expert. :smile: But I’m afraid I’m not much help here, as over the years, I’ve refined my modeling techniques to the point where, well, I just don’t model surfaces that wouldn’t unroll cleanly in the first place. So I haven’t run into any issues… I need my forms to unroll cleanly in 14g stainless, and the metal has always been less forgiving than rhino, so I’ve stayed very well within the tolerances.

I would agree, though, that the user should be able to have some say as to what the acceptable tolerances should be with this tool.


In UnrollSrf, testing for flatness is done on all of the surface isocurves.
The 10% is determined by comparing the deviation from a straight line to the length of the isocurve and seeing if its less than the allowed value.

Using the fact that UnrollSrf flattens a surface to see if something is developable isn’t and never has been a good test.
I’ll attach a v4 example of a surface that’s not developable that UnrollSrf unrolls and prints a deviation report.Twisted surface.3dm

Gausian curvature is a measure of single curvature. It is the product of the principal (max & min) curvatures at a point and if either one is 0, the Gausian curvature is 0. You can use Rhino’s curvature analysis to check that.


So what kind of settings would make sense to you?

The original idea years ago was to limit it to surfaces that were degree 1 in at least one direction which, of course, isn’t a measure of developability. It is sort of linked to probability of developability I guess, and because of the way UnrollSrf works internally, it facilitates pretty good error reporting about the area differences. It would still be theoretically possible to have a surface degree 1 in one direction that grew a little in one area and shrunk a little in another and have the flattened area come out the same as the curved area.
It didn’t take long until people sent in bug reports about degree 3 surfaces that were in fact the same shape as ruled surfaces, but got rejected because they were degree 3. So testing for straightness instead of degree 1 began. Then nothing was exactly straight so a tolerance came in.
Some of the hardest ones to get right are very long skinny ones with slight double curvature.

I can easily add a control for relative tolerance of isocurves in one direction so instead of 10%, you could set 1%, but that wouldn’t assure single curvature as you can see from the Twisted Surface attached to my answer to Willem.

I could also put a control on for max gaussian curvature. That’s scale dependent and would need to involve some judgement to use it effectively I think.

Is there any other way that might make sense?


Your ideas sound fine. Like I said, I’ve personally figured out over the years how to model my surfaces so they really are well within my own tolerances… but I suppose if I had extra controls, I might be a little looser with my modeling. It’s not a huge issue for me, and the more you explain it, the trickier it sounds… so I’m fine if nothing changes. But I guess I imagined it’d be handy if there was a dashed version of the command that allowed more tolerance options, especially for max gaussian curvature… I think. :smile:

OK I’ll see what else surfaces here and try to make sense of it.

There’s a lot of merit in the idea of knowing what you’re modeling and knowing what the relationship is to the manufacturing and what you’re asking the software to do.
It seems like my mistake has been to assume too much about that.

1 Like

Thanks for considering it, Lowell. :smiley:

Thanks Lowell,

I also noticed the same looseness in the settings recently and was going to comment on it

My feeling is that the tolerances for what UnrollSrf will unroll should be kept pretty tight. We have squish and external software available for doubly curved surfaces.

I’m probably a bit like Heath in that I have worked out my own ways over the years to know what is acceptable. However I have always assumed that UnrollSrf would fail on a doubly curved surface and relied on it to be a sort of “surface curvature checker”.


Precisely. I’d personally like to be able to know the tolerances are fairly unforgiving.

1 Like

Hi Heath,

I have also adapted techniques that will basically allow for straight lofted surfaces to be the only surfaces in the design. It was only in this current project that I found double curved surfaces to be valid input for UnrollSrf. If a surfaces like the example I gave with such a bump on it can be unrolled, Rhino no longer has a way of Unrolling developable surfaces within reasonable tolerance.

1 Like

Hi Lowell,

Thanks for the insights. It is my believe that UnrollSrf should be tight by default and adjustable by user input to a larger tolerance. As pointed out in another topic about Squish there are currently 3 different tools for flattening surfaces

  • UnrollSrf
  • Smash
  • Squish

In the current setup they apparently all do about the same (reading their help topic and the information in this discussion):

UnrollSrf command: Flattens ( develops) a surface or polysurface with
curvature in one direction to a planar surface.

  • with 10% relative tolerance in being flat*
    @margaret It appears the Help file on UnrollSrf should -for now-be updated to reflect the tolerance used to determine flatness in one direction.

Smash command: Flattens a surface without restriction to
single-directional curvature.


Squish command: Flattens a non-developable (curved in two directions)
3-D mesh or NURBS surface into a flat 2-D pattern.

Would than with Smash and Squish available, UnrollSrf not set to be tighter in tolerance rather than looser?
I’m in favor of user controlable settings but my mathematical understanding is not that good to know what exactly those settings should be. What I expect reading the Help file on UnrollSrf is that it is a tool to Unroll non-double curved surfaces and I wish it to remain so.

The example surface with the bump I gave is clearly non-developable and should as such not be Unrolled by UnrollSrf.
I understand that there are surfaces like your example Twisted Surface that appear to be developable but in fact are not.
This to me only emphasizes the fact that Rhino is not sufficiently equipped with standard tools to analyze and model developability of surfaces.

As for UnrollSrf, I would love to have control over and a report of how flat a surface should be to allow for unrolling.
What that means in terms of settings and type of data is beyond my expertise.
It would be useful to know where undevelopable areas in the surface are; how much the deviation form developable are.
I can even imagine the tool to work as a fix:
Unroll the surface; get a report on what criteria were (not) met and construct a developable surface within desired tolerance. This could be as simple as rebuilding the surface in one direction to a degree of 1 or as complex as refitting a surface. Sort of like a Unroll → Re-roll route.

Last but nor least; would it be possible to get a prototype/beta version of Unrollsrf with user control when it is available?

Many Thanks

Thanks for the input.
I’ll add a tolerance option to UnrollSrf.
I’m pretty hesitant to change the default mid-stream like this.
The tolerance the way it is now didn’t just happen because I woke up one morning thinking it would be fun to change it. Its been fiddled and adjusted in response to tech support questions and bug reports over a long time span.
I also understand that you and some others here are pretty clear about wanting it different and somewhat less clear about exactly how it should be different.
I’ll get something in a service release candidate pretty soon so you can see what you think.