DupEdge a trimmed edge.
CrvDeviation between the duplicated edge curve and the circle used for trimming. The maximum deviation of distance will be less than the absolute tolerance.
When a surface is trimmed an edge curve is created. This edge curve will be a non-rational degree 3 curve with sufficient number of control points that it is within the absolute tolerance of the theoretical edge. In most instances the theoretical edge cannot be represented exactly by a NURBS curve. Rhino is not “smart” enough to know about special cases such as your example where the theoretical edge can be exactly represented by a special type of curve such as a circle.
A circle cannot be represented exactly by a non-rational degree 3 curve. (With a sufficient number of control points the deviation between the non-rational degree 3 curve and an exact circle can be reduced to within any non-zero tolerance, but there will always be some deviation.) Since the curve deviaties from an exact circle the local radius/diameter of curvature will also deviate from the radius/diameter of the circle. Note a small, local distance deviation between two curves will usually result in a much larger deviation in radius of curvature. That is how geometry works.
Hi David,
When I do as Duncan instructs and the centreline of the cylinder passes through the centre of the sphere I get a consistent diameter of 40.0000000, so Rhino is recognising the circularity of the hole.
I surmise that Duncan is getting different diameters because his cylinder is slightly off centre from the sphere.
Regards
Jeremy
EDIT: As @jim rightly points out below I didn’t follow the OP’s steps at all correctly. It just goes to show the danger of posting when you’ve had too much/too little coffee. Or are developing a messiah complex.
The problem is you didn’t do what the OP did.
In the original post, the intersection is a circle and not a spline curve. That shows that the cylinder axis does pass thru the center of the sphere and Rhino recognizes the intersection as a circle (arc).
But that is an intersection. The OP is asking about a trimmed edge.
The only time that Rhino recognizes a trim as a circle is when that circle coincides with an isocurve that is a circle. This only happens in one case → when the axis of the sphere and the axis of the cylinder coincide. The trimmed edge of the cylinder is a precise circle whenever the cylinder axis passes thru the .sphere center point.
You can see that the axis of the sphere is not the same as the axis of the cylinder.
They are at right angles.
IMO this is a bug. Rhino correctly recognizes the intersection as a circle and should also recognize the edge of trimmed sphere as a circle when it is supposed to be precisely a circle.
You are absolutely right! Thanks for the correction.
Regards
Jeremy
@dale I have a lot of respect for jim’s opinions, so I bring this thread to your attention for consideration.
maybe @sfp is the one to have a look at this topic.
Thanks for the ping, @AlW — Jim is right.
Trimmed edges are normally made by pulling the trim curve into the surface’s parameter space and pushing it back up into 3D, which produces a fitted NURBS curve. The exact circle gets discarded on the way. Reproduced here with a 0.001mm tolerance: the intersection is an exact circle at D40.0000000, but the trimmed edge samples between 39.9996174 and 40.0004667. Its radius of curvature swings 19.77 to 20.14 — roughly 430× the positional error, which is the effect David described and why the readings look worse than the tolerance implies.
But we already skip that refit in two cases: when the trim lands on an isocurve (why Jeremy got 40.0000000 with the axes aligned — Jim’s diagnosis is exactly right), and when the surface is planar. So the behavior exists, it just doesn’t cover this case. We’re handed an exact circle that provably lies on the sphere and refit it anyway.
We’d like to fix the general case: if the curve already lies on the surface within tolerance, use it as the edge. I logged this specific issue.
Thanks,
– Dale
Thank you all for the in-depth engagement and the bug filing 
I did notice Rhino correctly recognises the intersection as a circle, and hence I was so confused why the diameter would fluctuate after the trim.
This might be irrelevant as the source for the problem has been determined, but I found a workaround that helped me in the meantime:
This will make the diameter stay exactly 40mm along the entire trim edge.
In this case, the sphere/cylinder intersection is correctly computed as a circle.
The case that the intersect needs to be looked at is the intersection of two true spheres. In that case Rhino makes a pretty ugly spline curve as the intersection curve instead of a true circle.
You could just have joined the cylinder and the sphere after trimming both. This would make the joined edge a true circle and the sphere would retain that edge definition after using ExtractSrf (or exploding). I imagine this is because the joined edge adopts the edge of the cylinder.
How important is the exact mathematical solution for the trim edge compared to an approximate solution that is within the user specified absolute tolerance of the exact solution? Why is it important?
For example if you trim a sphere and a plane with each other, and then join the results the only way a user would know the trimmed edge curves are not exact circles is if someone examines them in detail.
When you work in fabrication, obtaining clean circles and ellipses is vital for DXF export.
