Weird planar/non-planar surface issue

[Helvetosaur]

The file below came from a client. There are 5 building volumes in there, all basically simple boxlike objects, all planar surfaces. They noted to me that it took a very long time to mesh to get a shaded display. Currently, it is saved small, the file is only about 2.6Mb. Warning, setting the display mode to shaded it will take several minutes to calculate the meshes… But you can always Esc out to return to wireframe.

After a bit of investigation I found that the mesh settings were bad - someone had put a too small value in Max edge length - when they were intending to put that value in Max distance edge to surface.

Simple planes was also checked, so for all planar faces, this wrong mesh setting was ignored. That finally led me to figuring out the problem after a good bit of investigation time. I noticed that some of the vertical faces showed isocurves - but the display mode was set to not show them for planar faces. Ergo, those faces were not considered as planar by Rhino. Use simple planes was thus ignored and Rhino tried to mesh those faces with a huge number of faces… hence the long meshing time.

The question is, what is causing Rhino to consider these faces as non-planar? As far as I can tell they are way, way within tolerance. File tolerance is 0.01mm (ten microns). One surface I tested was out by around 3e-06 mm. Three thousandths of a micron.

If you explode the objects, and run SelPlanarSrf, all the ‘planar’ surfaces will be selected. Hide those and you will see what Rhino considers to be non-planar. If you set the display to shaded on only those, it may take about a minute to shade. That is because I already partially fixed the mesh settings - previously the max edge length was set to 0.01! It was taking like a half hour to generate the meshes and making a file size of 1+Gb meshed…

I reset that setting to 0.1 - just to demonstrate the problem here. Actually it should be set to 0 and the max dist edge to surface should be set to 0.01. Shading will then be instant. But I’m not concerned with that, the shading is not the actual issue.

My question is why are these particular surfaces considered to be non-planar? I am pretty sure they were imported from somewhere else. Otherwise I can’t find much actually wrong with them. Maybe somone else can.

volume Basile re2.3dm (2.6 MB)

[jeremy5 (Jeremy)]

I don’t have a why yet but I note that you can change the orientation of a surface not found by SelPlanarSrf and the new one is found.

[Helvetosaur]

Yep, copy paste into a new file - no problem. Rotation of the joined objects in hte same file also OK. But not copy in the same file, nor Scale etc…

[jeremy5 (Jeremy)]

Another snippet:

If you test the unrotated surface in my picture for planarity with the IsPlanar() method, you need to set the tolerance to around four times the default (i.e. RhinoMath.ZeroTolerance x 4) to get it to pass the test. The rotated version passes at ZeroTolerance.

[Tom_P]

my guess - selPlanar does not care about document tolerance:
draw a dice, 100x100x100, explode, pointsOn → move one corner by 0.0000001

_selPlanar will not like those surfaces anymore.

the cvs of one of those surfaces (_list command) are of.
even if you redraw the surface by _srfPt → no _selPlanar

        CV[ 0][ 0] (497.03220237575442, 443.75374747259775, 0)
        CV[ 0][ 1] (497.03220237575442, 443.75374747259775, 28)
....................................................xxxxxx      
        CV[ 1][ 0] (692.02803165611476, 443.75374747421301, 0)
        CV[ 1][ 1] (692.02803165611476, 443.75374747421301, 28)

so maybe the planar check (or bbox evaluation) is different for world aligned vs free space orientation ?

if you _pointOn _setPt (y=yes → pick one corner then the surface is considered planar. (_selplanar)

would be nice if at least the -_selPlanar version would allow a tolerance-option (document, custom, math.zero)
i think it s worth if one of the devs has a look at it.