# Developable surface not developable

G’day McNeel,

I use a program to make very close to developable surfaces. The process is to define a surface (1) based on the desired edges then adding and modifying interior control points of a duplicate surface (2) to reduce Gaussian curvature. The unrolled result (2’) of (2) ultimately has less strain than the unrolled result of the original surface (1’). Materials are assigned to the surfaces before unrolling and this seems to work quite well, quite happy with the results. So we have surface (2) which is “more developable” than surface (1), but they have the same edges.

So now I bring these surfaces into Rhino and things get confusing. (1) will unroll nicely, but (2) won’t unroll at all. Surely a “more developable” surface (2) should unroll before a less developable surface (1)…?

This gives me concern with both programs. Should I just close my eyes and forget that I’ve seen this? The other program seems to give good results that are workable. Should I dig deeper and/or find a better solution?

Dev vs non-dev surfaces.3dm (52.9 KB)

UnrollSrf will unroll some surfaces which are not developable.

Based on some experiments, it appears that UnrollSrf uses the isocurves to determine if a surface can be unrolled. One set of isocurves needs to be sufficiently close to straight. One consequence is that a developable surface which is modelled so that neither set of isocurves is straight will not be unrolled by UnrollSrf.

The V isocurves in your “non-developable” surface are straight. UnrollSrf unrolls it even though it is not close enough to developable for you. The V isocurves in your “developable” surface are curved. UnrollSrf does not unroll it.

Neither of your surfaces is very close to being developable, even though the numerical value of the magnitude of the Gaussian curvature appears to be very small.

The Curvature command shows circles fitted to the principle curvatures at a point on a surface. A developable surface will have on of the principle curvatures equal to zero everywhere, and the corresponding curvature “circle” will have infinite radius, ie a straight line, everywhere. Neither curvature circle is close to a straight line over a large part of both of your surfaces. In other words they are not very close to being developable. But the magnitude of the Gaussian curvatures of your surfaces have very small numerical values. What’s going on?

The problem is the numerical value of magnitude of the Gaussian curvature by itself is not a good way to judge how close a surface is to developable. Gaussian curvature is a dimensional quantity with units equal to the inverse to the dimensional units of the surface squared. Your surface has dimensional units of mm so Gaussian curvature has units of 1/mm^2. Change the units to meters and rescale the model so that the physical size and shape stays the same. The numerical value of Gaussian curvature will increase by a factor of 10e6 or one million while the “physical surface” stays the same. The only change is in the units used to measure Gaussian curvature.

Check for developability using the Curvature command.

David already pointed out the UnrollSrf shortcoming that prevents unrolling your surface - the fact that the surface isocurves aren’t linear in either direction. That’s not a problem with your surface, but UnrollSrf doesn’t work on that kind of surface.

In the attached file:

The green flattened surface is the result of using Squish on your green surface.

The black curved surface is the result of Sweeping a surface with the long edges of your green surface and some lines that I made up by eye-ball. The made-up lines could be a little better, but they’re pretty close to on your green surface.

The black flat surface is the UnrollSrf of the Sweep surface.

I don’t know what all that proves, but maybe it will help understand why UnrollSrf didn’t work on your developable surface.

Dev vs non-dev LW.3dm (127.3 KB)

Thank you both for getting back to me. Very interesting responses. Reading through the other developers help file again it seems they also allude to Gaussian curvature only being an indicator of developability, the real test is to actually try to develop the surface and look at the strain.

Attached is another developable surface oddball situation. The caveat is that I would model it as I have done originally, not the lofted option. This post is merely to add to the knowledge about using developable lofts in rhino.

lofted dev surf issues.3dm (4.0 MB)

1. Curve profile (a planar spline)
2. Extrudecrv (this should be perfectly developable)
3. Trimming curve
4. Trim the surface
5. Unrollsrf (perfectly developable as expected)
6. A - Two different results of a loft with developable option based on the edge curves of the original trimmed surface. The different results arise from picking at different ends of the curves. (picking corresponding edges to avoid “twisting” the loft) Corresponding unrollsrf results also shown.
7. B - Lofting (developable) between edge curves but with a rebuild added (to see if something nicer would result.

Admittedly, one of the results in 6A is a decent result, but it doesn’t have parallel isocurves (see picture). Also, it shouldn’t matter which ends of the curve are picked (as long as twist isn’t induced).

So, this clearly shows that dev lofts between arbitrary curves are not always the best way to create a developable surface.

Interesting example.

Pascal has said that the Developable option will be dropped from the Loft command in V6. DevSrf is the preferred method for creating developable surfaces from two edge curves. http://wiki.mcneel.com/labs/devsrf However DevSrf struggles with your example unless the curves are divided into several segments. The resulting surfaces do have parallel isocurves.