PlanarSrf fails after Splitting a Polysurface

Rhino Rhino for Mac
1

(OSX 10.7.5, build 510)

Any insights into this curious PlanarSrf failure after a Polysurface was Trimmed with a Surface?
Many thanks!

~Dave

Screenshot 2014-05-02 00.22.44.png1117×712 227 KB

PlanarSrf_Fail_After_Trim.3dm (199.9 KB)

2

Rhino thinks your curve is not planar… If you use ProjectToCPlane, the surface then works…,

I checked the deviation… it’s 2.76612e-12 extremely tiny. However, looks like Rhino is using the Curve.IsPlanar() method to check planarity, and here’s what it says:

“true if the curve is planar (flat) to within RhinoMath.ZeroTolerance units (1e-12)”

You’re at 2.766 times this tolerance… :smile: …so it fails…

As to why trimming your polysurface with the plane results in a “non-planar” edge, that I don’t know. Looks like a tolerance issue or a bug… Can you post the original polysurface before trimming? If I make a plane surface with your custom CPlane and use that to split another part of the object, that makes a planar surface and the object caps at that point as well.

–Mitch

3

The curve is not planar. (see file below) I imagine the trim failed because
the fillet that didn’t get trimmed is a tiny bit too short.

Trim_Fail.3dm (141.5 KB)

4

how did you get the curve?

because in the drawing, i can cap the part you’ve trimmed… as well as dupEdge, move the edges elsewhere, then PlanarSrf …with no problems

[edit] oh wait… never mind… that’s after i moved the cutting plane then retrimmed the object… but yeah, what jim said… you didn’t completely trim the object and have that little bit of the fillet sticking out.

5

Hi Mitch,

Thanks for the feedback (and sorry for a poorly worded question – I did realize the curves were not planar, but was wondering why, since it seems like they should have been).

Enclosed is the relevant part of the larger file. Some things are worth noting:

  1. To create the entire polysurface, two surfaces were lofted after the Split (and now that I’ve slept and am properly caffeinated “Split” is actually what I did, rather than a Trim). Methinks that geometrically (if there is not some kind of issue somewhere), all resulting edge curves should have been coplanar.

  2. Also, there is a (possibly unrelated?) larger issue in the overall geometry resulting from a Sweep2 command with Maintain Height used. The detailed profile that was swept on two rails had a small separation in surface continuity (where noted on one of the layers).

I decided against posting about this particular issue because upon closer examination of the rail where the problem occurred, I discovered that while the rail curve was in fact continuous there is a very slight lack of tangency at that location. Is this an issue? Not sure. While I thought Sweep2 probably should have handled this lack of perfect tangency without a hiccup (assuming it’s truly working properly right now, which is a little unclear given the recent related thread on a confirmed Sweep2 bug), I suspected that the Maintain Height option may have created some type of issue?

Dunno… Would have to test some other Sweeps with a perfectly tangent set of rail curves and compare them with some others that have greater disruptions in tangency, but are still joined.

Insights welcomed if anyone has some!

~DavePlanarSrf_Fail_After_Trim_ALL.3dm (1.7 MB)

6

Hi Jim and Jeff,

Many thanks for taking a peek. I see what you’re talking about now. Late night and did not notice this!

Upon reflection, it makes some sense that a fillet would be perpendicular to the curves and cause an issue if the split is not also perpendicular on the polysurface.

Now… Any insights into the problem listed above in Item 2? That’s the more vexing issue.

Dave

7

there’s a problem with sweep2 on mac right now and this appears as if it could be another example of it (but i only quickly glanced at the file)… marlin has said he found the issue and it will be fixed in the next release… so, maybe wait til it comes out then retry.

http://discourse.mcneel.com/t/sweep2-error/7798

[edit] hmm. maybe not… i still haven’t fully looked at the file but maybe this is something different… i’m not quite sure the input geometry is fully aligned properly though… but one of these guys with windows should be able to find the difference if it’s the same/similar error happening as the one in that link above.