Unroll Issues

Outer edges seem fine. I am getting weird distortions in the text!?

UnrollTest.3dm (257.5 KB)

It seems like this is a tolerance problem in UnrollSrf - tightening the file tolerance to .0001 lets it work OK, but this should not be needed here- .001 should be fine, so this is certainly a bug as far as I can see. Another workaround, at current tolerances, is to untrim the surface, with Keep=Yes and then unroll the reasulting curves with the untrimmed surface and then retrim the flat objects.

Hmm- I take it back- this appears to work correctly in the latest Mac Rhino.


Alright next issue.
I am untrimming to give me my curves which I can unroll with the surface. This is so I can get the inside sections of the R and A.

When I unroll those surfaces seperately they move to the center of the screen so I can’t place them where they belong.
Now when I untrim and unroll the surface with the text curves. I’m missing U and both S’s!?

UnrollTest2.3dm (120.8 KB)


Another tolerance issue yet “in reverse”:
The curves are not unrolled probably because they are out of tolerance (not considered on the surface with a file tolerance of 0.0001)
So If you loosen the tolerance to 0.01 they do unroll with the surface.


I’m running into a similar issue. I’m trying to unroll 80 surfaces, each with eight 0.200" diameter holes in them. They are approx 70 inches in overall length.

When I unroll using a python script I wrote, some pieces of certain surfaces are distorted. When I unroll using _UnrollSrf, there is less overall distortion, but the holes are much more distorted.

The line of interest in the script:
unrolledObject = rs.UnrollSurface(object, explode=False, following_geometry=None, absolute_tolerance=.0001)

My model absolute tolerance is 0.01 units, angle tolerance is 1.0 degrees.

A potential clue, but probably just a coincidence:
All of the surfaces were named with a prefix (A thru E) and a number (1-10). The only problem surfaces were those with a number 1 or 10. C1 is shown in the image below. I had to manually unroll 7 out of 70 pieces: C1, E10, D1, D10, F1, A1, and B10. Then again, it’s more likely that the cause is their location in physical space?

Attached Rhino file
I’ve included a file that demonstrates the issues: note that I’ve only included the borders of the unrolled surfaces, let me know if you need the actual surfaces to diagnose, and I’ll try to track them down / rebuild them.

Image showing problem:

Rhino File:
UnrollProblemsFocus2.3dm (17.2 MB)

Unroll Script:
SV_UnrollMultiple.py (1.7 KB)

Hi Steven - on this file, the surfaces are developable at a pretty tight tolerance - the ones I checked are fine at .0001 (file tolerance) with UnrollSrf, and the results are much cleaner:



Pascal, I changed my file tolerance to 0.0001, and that fixed the manual unrolling, thank you!

The scripted unroll is still problematic. I’ve shown “C1” unrolled, manual at left, script at right. The deviation is approx 0.200", well above tolerance. Is there a reason the script would unroll the objects differently than the manual method?

Checking back in. I have about 200 individual surfaces to unroll and I’d rather not do them all by hand / visually error-check each one. Is there a way to script an unroll reliably?

Hi Steven - I’ll take another look. Hold on a bit.

@StevenV_Gizmo - I don’t know the reason yet but it looks like ShrinktrimmedSrfToEdge on the input and then UntrimBorder on the output gets things much closer - I don’t say that is a good thing in all cases but it may help for now, I’ll see if I can find what is going on with the two approaches to unrolling - it does not jump out at me.


I have had a similar problem, where only the list of curves is reversed? This happens only in some instances… Is this a bug in the unroll function or tolerances?

I attach example of transformation in question.

Jrevserse-list-curves.gh (14.2 KB)