Bug: Non planar planar curve

Rhino Rhino for Windows
,
1

This is an odd one. In the file below, there is one contour curve, which is supposedly planar and at a plane level of +62mm. However SelPlanarCrv does not select it.

NonPlanarPlanar.3dm (26.3 KB)

I tried to figure out where it’s out of plane. At first I had a hard time finding anything. I then ran the following script on the curve:

import rhinoscriptsyntax as rs
crv=rs.GetObject("Select curve",4,preselect=True)
if crv:
    pts=rs.CurvePoints(crv)
    for pt in pts: print pt.Z

The result was this:

62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0000000000
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0
62.0

So, somewhere in the middle - from point #25 to point #41, the printout is different, and I suspected floating point “fuzz”. So then I modified the print line in the script to force more decimals:

import rhinoscriptsyntax as rs
crv=rs.GetObject("Select curve",4,preselect=True)
if crv:
    pts=rs.CurvePoints(crv)
    for pt in pts: print "{:.12f}".format(pt.Z)

And sure enough, then it showed up:
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
61.999999999999
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999997
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999998
61.999999999999
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000
62.000000000000

So we’re off by max 0.000000000003 That’s really wrong. Hence the word “bug” in the title.

What’s also odd about this curve is that when you turn on control points, you get 42 points indicated. If you ExtractPt, you get 58, including 16 dupes. What’s going on there? The offending segments are listed as “Elliptical arcs”. But even after simplifying the curve, which substitutes normal arcs, the curve still does not select as planar and I still get a difference in number between PointsOn and ExtractPt…

1 Like
2

Looks like a bug.

Workaround: set CPlane to the defined plane on which you expected your Contour to reside; ProjectToCPlane (Delete Input Objects = Yes).

3

Hi Mitch, I’ll take a look - it does seem like SelPlanarCrv ought to use a tolerance, maybe - whatever PlanarSrf uses.
(I get 42 extracted points, btw, here, if points are on, and the 58 if points are not on…hmmm)

RH-65979 SelPlanarCrv: use a tolerance
RH-65980 ExtractPt: depends on point visibility

-Pascal

4

I have several scripts I use to automatically correct this, the curve posted is just an example from a whole collection of similar curves in a particular file.

I would call this a programming misjudgement in this case. Most of the planar checks go back to the base function ....TryGetPlane() which attempts to find a plane from an input curve or surface. This function can take an optional tolerance argument. If the optional argument is not supplied, it defaults to the Rhino “Zero tolerance”:

image
image769×492 17.7 KB

I always thought that the Zero Tolerance was equivalent to 1e-12. However this says it’s larger than that:

image

The out-of-plane-ness of the posted curve is actually less than that (if I calculate correctly), so it should have been considered planar. However the out of plane distance is just larger than 1e-12, so maybe that is the value that is being used. This is definitely confusing, would be good to clarify.

In any case, the programming misjudgement is not using the optional tolerance argument for the planar check. Something around the file absolute tolerance would be good, perhaps an order of magnitude or two smaller if one wants to be strict.

image
image709×555 20.1 KB

5

Mitch -

Apart from the SelPlanarCrv and the ExtractPt issues, I wonder if the creation of that curve is something that should be looked into. Was that just with the Contour command and, if so, could you share the input surface?
-wim

6

Yes, definitely something less structured and less-disciplined within the McNeel camp than I would have expected. :cry: Almost as bad as the Rebuild command….

7

In this case that’s something we’re unlikely to know. This particular file came from a colleague. Contour curves can come from anywhere, they could be downloaded from some official geodata source, supplied by someone else (unknown origin/software), or they could be created by slicing a 3D terrain mesh for example. Then, the modelmaker (in this case) will modify the curves for production (with any and all of the Rhino tools at their disposal), for example changing some of the contours to match the current project, cutting in new building outlines, etc.

So the procedures and methods used will always be different. So it’s important to be able to detect this type of situation correctly.

8

another workarround, for those you do not use a script is to use
select the curve,
call the macro

-_setPt xset=no yset=no zset=yes alignment=cplane

klick point at z-position

9

Yes, there are quite a few workarounds, the main advantage of a script is you can just select all the curves and run the script once without having to pick or set anything. There were a dozen of those curves in the file, I just posted one as an example.

10

For folks who work billions or trillions of units from the origin those last few digits can be significant. :slightly_smiling_face:

11

RH-65980 is fixed in Rhino 7 Service Release 12

12

RH-65979 is fixed in the latest WIP

1 Like