CrvDeviation problem

Simply by not refusing to show me the maximum deviation. Please have a look at the attached real world sample. I don’t see a reason why it should not work in this case. (result is hidden)
MaxCrvDeviation.3dm (36.0 KB)

I can solve these things with my own commands, also minimum bounding boxes and the like, but I think this stuff is core functionality.

1 Like

You can solve it easily with line perpendicular to 2 curves, but that example probably should work.
Crvdeviation does work if you move the curves 0.1 mm closer together.

1 Like

Now I will not make an example which you cannot solve with line p2c approach. I think nobody at McNeel is following our discussion anyways :wink:


Isn’t it an idea that McNeel comes up with a total new analysis dialogue that covers all examples and possibilities mentioned above?

Hi Gerard,
it does not have to be a total new interface (makes it more unlikely to happen).
Some options would work for me:

OverlapOnly = Yes/No
StartDistance = Yes/No
EndDistance = Yes/No
MinimumDeviation = Yes/No
MaximumDeviation = Yes/No



Nope, I am reading…



Hi Pascal,
I don’t really understand what is meant with:

OverlapOnly = Yes/No
StartDistance = Yes/No
EndDistance = Yes/No
MinimumDeviation = Yes/No
MaximumDeviation = Yes/No

IMO it’s not about providing more types of info, but to explain the current implementation. Some results of CrvDeviation might be bugs, others might just not being understood… at least by me.

thanks, Tobias

Hi Tobias,

The idea behind these options is to make the command work in cases where the buggy algorithm fails to detect an overlap. It should be possible to check the deviation in general, no matter if the curves overlap or not. Start and End distance is also distracting if it is identical with min or max deviation.

So it is not about more or different types but a simple, clean and specially reliable result!

Attached is another typical failure of the command.
The blue polyline was rebuild to get a smooth curve, some points have been adjusted.
CrvDeviation fails. It is my last attempt helping to fix that bug - I promise :stuck_out_tongue:

CrvDeviationNoOverlap_v6.3dm (37.7 KB)

Hi Jess - I see that Rebuild also does not show a deviation to this polyline, butExplode-Join on the polyline then Rebuild or CrvDeviation works… I’m still poking at it.
It looks like it has to do with the location of the seam - if it is on the point of the football, it all fails.

Well than I have misunderstood at least part of the conversation - if we can add options that fix the bugs we might as well just fix the bugs, no?


Thanks Jess. I get it now!

Detecting an overlapping is buggy for a very long time and has often been reported with many examples. So I’m sorry, but I have to assume you are not able to fix it. :wink:

Another bug is that CrvDeviation only works with overlapping curves.

The truth is that CrvDeviation does not do what one needs it for in industry. Nobody apart from hobbyists has time and budget to fiddle around with workarounds that are amounting to nothing but guesswork and lucky coincidences.

That’s not a bug. That’s what the function was designed to do. That’s what the help says it was designed to do. The first thing it does is find an overlapping interval and if it fails to find one that’s what it reports on the command.

The option is needed to restrict the analysis to the region of curves that overlap.

The thread about the trim failure this morning is an example of what CrvDeviation was designed to be used for. To analyze that problem you can first make an intersection curve and then do the trimming. Then use CrvDevuation to find out what went wrong with the trimming boundary. If the changes that Jess and Tobias are asking for are implemented it will produce a result that is completely useless for determining where the edge is out of tolerance with the intersection curve. That;s because the analysis will not be restricted to the interval where the curves overlap so the ends of the curves will be the maximum deviation and that’s useless information.

This needs to be viewed as expanding the design intent of CrvDeviation. That will require either another command or an option that changes how it works.

I work in industry and use it many times everyday and it works well for its intended purpose which is primarily determining if 2 overlapping curves are within tolerance of each other (in the overlapping interval).

The command cannot do what it does well now and do the other things people want it to do without at the very least having an option to preserve the current behavior.

The problem with your logic is that you are trying to expand the meaning of “overlapping” to the point where that concept becomes meaningless.

I think its a good idea to have an option to restrict the analysis to 2 types (OverlapOnly = Yes/No)
To have a robust algorithm to analyze overlaps its not a good idea to consider curves that 300mm apart and 100mm long. That just makes the defining of the interval of poor quality for anything other than parallel lines

That is hardly its intended purpose. Curve deviation means to find out the closest or farthest points between two curves or establish a deviation (distance) over a range or a curve’s deviation from some other entity. Rhino’s tool is fully inadequate for this task (see use cases in my comment above). The tool should be renamed CheckCrvOverlap to not insinuate analysis functionality that cannot be delivered.

A rose is a rose is a rose.

Well, I know what CrvDeviation can do and what not. But most users expect much more from this command for good reasons. Even experienced users like Tobias stumble over the failures. He was looking for the minimum deviation between two curves. Sometimes it works and sometimes not. And who knows about the object option in ClosestPt? That’s how this thread started.

Recently Mitch was trying to use CrvDeviation to find curve duplicates within a certain tolerance. That would be perfectly possible if this command would not just analyze the overlapping. I’ve provided a script solution for this task.

Glad you found out that I don’t want to take away the functionality you need.

I have no way of knowing what you want. I do know you keep calling checking curve deviation only in in an overlapping intervals a bug. It can’t be an option and a bug

Hmmm. (I’m using Rhino 4, but probably this hasn’t changed.)

(1) This is getting close to a problem I encounter sometimes: I have two curves that are Supposed (by me and the way I made them) to intersect. They are very close to crossing, but they don’t intersect. On the other hand, when I ask to draw a line perpendicular to both curves, no line is created. (And no error message is produced. Isn’t this in violation of one of the rules of user interfaces: “If the user asks for something and you can’t give it to him, give him an explanatory message.”)

(2) All this talk of “overlap”: look, I’m a PhD mathematician, and I have no idea of what you mean by the “overlap” of two curves. It’s just another example of Rhino needing more documentation. I suggest you add a paragraph or two to the existing documentation of each command, called “Details”. For example: you are about to explain to me what you mean by the overlap of two curves, and how it affects the Curve Deviation function. Great! Now write it into the documentation.

Another example: The limits and behavior of U size and V size (I don’t have Rhino here, and I don’t remember the exact words) of Patch. (Yeah, the limits in Rhino 4 have been changed.) I spent a bunch of time having to explore how this worked. Watching Rhino change parameters I specified, without saying anything. (Another violation of user interface rules.)

This kind of Details documentation would save me a lot of time.

Academic? That may be the root cause of it…

Seriously, I’ve never had an issue drawing perpendicular lines, and it is hard to ascertain what specifically you are referring to.

Suggestion: make a quick video screen shot of the issue, and I almost guarantee that someone here will breakdown the malfunction.