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.
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
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.
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.
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.
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.