CrvDeviation problem

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.

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!