CrvDeviation problem

Please see the attached file. Why CrvDeviation fails on those 2 curves?
CrvDeviation problem.3dm (203.3 KB)

Rhino5 SR14

thanks, Tobias

1 Like

Because the maximum deviation from Curve1 to Curve2
and the maximum deviation from Curve2 to Curve1 do not overlap.
What are you looking for? Closest Points between the curves?

1 Like

Hi Jess,
Yes, I am looking for the closest point between the curves.

But hey, maybe I am a bit dense here, but the maximum deviation from Curve1 to Curve2
and the maximum deviation from Curve2 to Curve1 should be the same, isn’t it? So they must overlap…:thinking:

1 Like

For the closest point calculation you can use the _Object option in _ClosestPt.

Well, I’m only guessing regarding _CrvDeviation failures since the Help does not cover the details. Would be good to get some insight from the developers. @dale ?

I think the maximum deviation is not overlapping in your sample because
The longest of all closest point calculations from curve A to curve B is different to
the longest of all closest point calculations from curve B to curve A.

1 Like

Jess, your screengrab is quite interesting. I would never think of both arrows to be the max deviation. Maybe I just don’t understand the concept here.

I would expect this as the max deviation in both directions:
CrvDeviation problem-Front[6]

Btw, I found out that if I poit edit curve B to make it shorter, CrvDeviation does work:
CrvDeviation problem-Front[7]

But if I look at the result I’d say everything except for the shortest deviation (green curve) is wrong.

I have no idea what the left-most distance (white curve) is all about and how the start and end points of that curve are defined.
Also the red curve / distance is wrong IMO.

Some insight from the developers would indeed be nice! The help for CrvDeviation doesn’t explain the results at all.

Hi Tobias,

IMHO also a valid analysis, the opposite of Closest Points -> Furthest Points?
But something different than the red MaxDeviation like in this case:

Edit: The other curves mark the shortest distance of any start or end point. Not sure how useful that is.
There are already some youtrack items regarding CrvDeviation. It definitively needs some love from the developers!

CrvDeviation works well for its intended purpose - which is analyzing whether edge curves can be joined and if not within tolerance where the maximum flaw is found. It does not work as well for curves that are not edges being considered as candidates for joining.

Hopefully any changes made to the command that is going to be made available to users won’t destroy its current excellent functionality for its intended purpose. I mean looking at your example one can only wonder what information is expected here or what purpose that information might be used for.

Hi Jim, if there is an “intended purpose” for the command than at least the documentation of CrvDeviation needs some love.

1 Like

This seems to be your limited expectation. Rhino’s failure to report general curve deviations is a huge disservice to the Rhino users. :wink: Like Tobias already said the Rhino Help does not mention any limitations:
CrvDeviation command: Reports the maximum and minimum distances between two curves.

I think there are cases where CrvDeviation fails, but the surfaces join without problems.

The help explains what the command does:

“The command may find one or more intervals of overlap between the two curves, or it may report that the curves do not overlap.”

It seems proper to me that the command would report that the curves do not overlap in your

I have no problem with added functions but you haven’t explained what useful purpose it would serve. Anybody who uses the command often could have told you that it only finds the max and min distance in an overlapping interval. That means it may exclude the parts of the curves that are not overlapping. That’s a useful context for the measurements. My proposal is that if the command is used for comparing edge curves that usefulness should be preserved.

So post an example

No, not propper at all!
Obviously the curves don’t need to overlap or (intersect)
This just shows how vague and incomplete the help file is in this case…

1 Like

Rhino could easily accommodate for the most common deviation analysis needs.

Obviously they do need to overlap because that is what the tool is designed to do. It finds overlapping intervals and reports the max and min deviation in that interval just like the helpfile says.

You think there should be a tool doing something different. That’s fine but I suggest not destroying something that is useful to get what you want. Don’t blame the Help it just describes what the tool is designed to do

How is measuring from point to point different from Rhino’s Distance command?

Rhino help file says: “To evaluate the distance between two surfaces compare the points on the first surface to the second surface using the PointDeviation command. The easiest way to generate a set of points on a surface is to create a mesh using the Mesh command and then use PointDeviation on the resulting mesh object and the second surface.”

Imagine curved supporting structures which you’ll have to bridge with material which is only available up to a certain length. This problem came across my work several times in very different industries.

1 Like

Just for the record: The statement above is a modified quote of jim from another discussion here.
I thought it fits somehow considering the number of CrvDeviation failures posted here on discourse.

C2C, C2S and S2S deviation is also important when one has to design around a sub-supplier’s components while minimising the shape envelope of a product. There are many cases in industrial design and architecture where such deviations need to be accounted for accurately.

Typical example from transportation design: pre-defined headroom requirements above percentile manikins, where the curves that later make up a sculpted cabin headliner or driver cab ceiling need to be just at the right height without wasting space. Manually taking circles or spheres with the right diameter and then fudging it does not go down too well with top-tier clients.

1 Like

I recognized the quote.

I don’t think there is any comparison between McNeel’s refusal to warn users about degenerate geometry and the inability to automatically find a deviation between a line and a circle.

The failure to warn users about degenerate geometry has resulted in many thousands of hours of wasted time for users who would have avoided the waste if they were made aware that geometry was likely to cause commands to fail and thus was leading them into a dead end.

That’s easy to imagine. How does a differently designed crvdeviation command solve that problem?

@jim Your comment about surface edges intrigued me… Because that’s generally not what I was using CrvDev for.

Below is one of the sample “failure” files I posted here and on youtrack awhile back. I copied the two curves in question and then extruded them in opposite directions to create a theoretical situation where I might want to join two surface edges.

CrvDev on the two curves fails.
CrvDev on the two surface edges which correspond to the original curves… works.

How is that not buggy? (note the command is named CrvDev and not SrfEdgeDev)

No_CDev_Crvs_Srfs.3dm (302.0 KB)


Yes it works but it doesn’t work the way you describe it. It works because as an edge its treated as 2 component curves. You could have
made it work by exploding the curve with kinks

Its not buggy because it performs the job it was designed for. What you guys are asking for will destroy good functionality and replace it with bad.

Take these 2 curves"

Currently it gives the maximum and minimum deviation over the interval where the 2 curves overlap. That’s useful information.
If what you want is implemented then the maximum deviation will be distance from the 2 ends. IMO providing that information makes the command much less useful.