Intersect command produces self-intersection/incomplete [why/how to fix]


I have an issue with intersection results.

The problem is consistent in both Rhino and Grasshopper.

I am creating a sliced model from a crazy polysurface (result from quadmesh-to-SubD-to-Nurbs):

Polysurface is valid and no naked edges are present other for the ones that that are supposed to be naked (marked in image below):

When I run the Intersect command to generate a curve from the polysurface and the planar rectangle surface, I get a curve that crosses itself at this particular plane/surface location:

When I zoom in and inspect the object, things look fine.

Could this issue be related to how the Nurbs object is generated from the conversions?

I thank you in advance from your input and/or advice - I got many sculptures to convert and slice!

another issue is incomplete intersections:

Here’s the model if you need to look at it:
sculptureslicing.3dm (9.3 MB)

Hello- for now, set the document tolarance to .0001 and then intersect. (DocumentProperties > Units page)


1 Like

Thank you Pascal,

I should have included that in my topic entry: I’ve been tweaking that setting along with the Mesh options (setting it to custom, increasing density).

The incomplete intersection seems to work better now however unfortunately I still get the self-intersections.

Thanks again…

What are you doing with the slices?

At .0001, there are no self intrersections in the curves here when intersecting the plane and the polysurface - is this correct:
sculptureslicing_Curves.3dm (97.9 KB)


Thank you for your time and responses @pascal

Yes - the file you shared does not reproduce the error.

At this point the ‘bug’ is a mistery to me.

It seems also that if I trim my sculpture, results are not consistent.


intersect command run between a trimmed fragment of the polysurface and the planar surface:

intersect command run between entire polysurface and the planar surface:

When intersected in grasshopper the same area is problematic:

These intersections are results from using brep-vs-brep as opposed to brep-vs-plane because planes for some reason yielded more inconsistencies.

So yeah who knows, sorry for bothering you with this - I think I’ve done it before when dealing with Rhino WIP (I was originally working on this file using RH8 and went back to 7 because of intersecting bugs).

Thanks again for your time and patience!

cutting them to make a ‘classic’ stereotomic object like this one but several feet tall in steel:

Eventually I have to resort to work-arounds like producing all parts as curves and not rendering surfaces - which is fine, CNCs need CAD anyway - but a rendering looks nice and helps guide fabrication - you can always manually tweak a profile here and there - however the inconsistency and unpredictability (despite how meticulous one is to keep mesh-to-subd-to-nurb fidelity and cleanliness) are the perplexing element.


Oh that’s interesting.

The file above looks like a SubD that you converted to Nurbs.

What’s your starting point? Do you scan objects and blow up the size?


It varies - we do laser scanning and mesh things - but not for this purposes as it requires too much clean-up. Fort this case/project, things are manually 3D sculpted, then turned into SubD, either through Rhino or Fusion360 (T-Splines), then breps.

I own an Artec Leo.

Why don’t you create create contours on meshes and rebuild the curves?

Are you using Grasshopper at all?

We alternate between all ‘section’ options (bbx, sec, contour, etc) - they all rebel in different ways :sweat_smile:

1 Like


1 Like

You have a point - however the {other, lol} point is:

Mesh contours/intersections are true to the mesh, meaning curves are actually polylines, which would require rebuilding the contours as you suggest to make them smooth splines - nonetheless rebuilding produces a new approximated curve, which (for obsessive people like us haha) is not accepted as this spline is no longer the actual intersection - hence we choose a specific level of quad mesh resolution prior to SubD generation knowing the nurbs resulting from this conversion ultimately yields intersections that are splines naturally and need no rebuilding - satisfying our desire to obtain the ‘authentic’ intersection.


My guess is the problem arises because the intersection just grazes a surface edge - passes within .001. Just the lower of the two faces there at the goofy intersection curve fails to find an intersection at all at .001 but gets the right answer at .0001. Anyway, I’ll get the example on the pile for the developer.


RH-71915 Surface Surface intersection - incorrect result


1 Like

Thank you!