Rhino.Geometry.Intersect.Intersection.CurveCurve hanging

I’ve come across a maddening situation where Intersection.CurveCurve hangs repeatedly during the following call:

def TrimCurveByClosedCurve(crv, ccrv, plane = rs.WorldXYPlane(), 
includeOverlaps = False, tol = tol):
    """trims a 2d crv by rect or closed curve, returning [inside sections], [outside sections].
    includeOverlaps: if True, segments that overlap ccrv are considered inside. 
    if isinstance(ccrv, Rhino.Geometry.Rectangle3d):
        ccrv = Rhino.Geometry.PolylineCurve(ccrv.ToPolyline()) 

   inters = Rhino.Geometry.Intersect.Intersection.CurveCurve(crv, ccrv, tol, tol) 

In the case of the hangup, crv is a NurbsCurve instance and ccrv can be either a Rectangle3d or a Polycurve, both effectively 2d. I’ve tried relaxing the tolerance passed to Intersection.CurveCurve, which has no effect at all. What’s really odd is that if I add those objects to the document (ie via Rhino.RhinoDoc.ActiveDoc.Objects.AddCurve(crv) and then call the same function from another test script using rs.coercegeometry(guid) on the document objects it works fine.

I’m running R7 with all updates applied - its a disconcerting problem because I use such intersection calls all the time and I’ve never ever seen one hang up. Would be tricky to provide the whole context here. Anyone ever had something like this happen before?

Edit: Apparently so, although it seems that isolating the problem is next to impossible:


Hi @will8,

To provide assistance, we’re going to need a 3dm file containing the two curves you are attempting to intersect.


– Dale


Thanks for the reply - I can’t seem to replicate the failure without it running inside a rather top-heavy python environment containing a ton of source files, and on a specific polysurface input. If I dump the virtual geometry to a 3dm document it works fine (only fails on ‘virtual’ geometry generated by scripts).

I’ll take a stab at pickling / unpickling the offending objects, and if I can replicate the hang in lightweight package I will send you the data. The function that’s causing the failure has been in my code base for quite some time, working fine, and this is the first time I’ve seen a Rhino API call hang up (without doing something dumb). It feels like it’s very context dependent.

Thanks again…


Okay, this replicates the hang and I’ve tested it on two machines with the same result.

Parallel_RhinoBugIntersectionHang.zip (2.3 KB)

Run DebugIntersectionHang.py and select file ‘DebugIntersectionHang.bin’, which contains the pickled geometry that causes the hang.

I’m curious if you get the same result.

I’ve tried all sorts of things to side-step the problem, such as duplicating the geometry, extending the open curve (n2dcrv), passing the argument domrect in various different flavors etc and Rhino always seems to hang up here.

Both machines are running R7; my primary workstation is up to date, not sure about the other box.


Here’s the output of SystemInfo:

Rhino 7 SR28 2023-2-27 (Rhino 7, 7.28.23058.03001, Git hash:master @ 4ffc5d7156fbccf2a5d9fcc80e522b3851bc7f6c)
License type: Commercial, build 2023-02-27
License details: Cloud Zoo

Windows 10 (10.0.19044 SR0.0) or greater (Physical RAM: 64Gb)

Computer platform: LAPTOP - Plugged in [100% battery remaining]

Hybrid graphics configuration.
Primary display: Intel(R) HD Graphics 630 (Intel) Memory: 1GB, Driver date: 1-8-2021 (M-D-Y).
> Integrated graphics device with 3 adapter port(s)
- Windows Main Display is laptop’s integrated screen or built-in port
- Secondary monitor attached to adapter port #1
Primary OpenGL: NVIDIA Quadro P5000 (NVidia) Memory: 16GB, Driver date: 3-28-2023 (M-D-Y). OpenGL Ver: 4.6.0 NVIDIA 528.89
> Integrated accelerated graphics device with 4 adapter port(s)
- Video pass-through to primary display device

OpenGL Settings
Safe mode: Off
Use accelerated hardware modes: On
Redraw scene when viewports are exposed: On
Graphics level being used: OpenGL 4.6 (primary GPU’s maximum)

Anti-alias mode: 4x
Mip Map Filtering: Linear
Anisotropic Filtering Mode: High

Vendor Name: NVIDIA Corporation
Render version: 4.6
Shading Language: 4.60 NVIDIA
Driver Date: 3-28-2023
Driver Version:
Maximum Texture size: 32768 x 32768
Z-Buffer depth: 24 bits
Maximum Viewport size: 32768 x 32768
Total Video Memory: 16 GB

Rhino plugins that do not ship with Rhino

Rhino plugins that ship with Rhino
C:\Program Files\Rhino 7\Plug-ins\Commands.rhp “Commands” 7.28.23058.3001
C:\Program Files\Rhino 7\Plug-ins\rdk.rhp “Renderer Development Kit”
C:\Program Files\Rhino 7\Plug-ins\RhinoRenderCycles.rhp “Rhino Render” 7.28.23058.3001
C:\Program Files\Rhino 7\Plug-ins\rdk_etoui.rhp “RDK_EtoUI” 7.28.23058.3001
C:\Program Files\Rhino 7\Plug-ins\rdk_ui.rhp “Renderer Development Kit UI”
C:\Users\will\AppData\Roaming\McNeel\Rhinoceros\packages\7.0\PanelingTools\2021.3.2.446\PanelingTools.rhp “PanelingTools”
C:\Program Files\Rhino 7\Plug-ins\NamedSnapshots.rhp “Snapshots”
C:\Program Files\Rhino 7\Plug-ins\RhinoCycles.rhp “RhinoCycles” 7.28.23058.3001
C:\Program Files\Rhino 7\Plug-ins\Toolbars\Toolbars.rhp “Toolbars” 7.28.23058.3001
C:\Program Files\Rhino 7\Plug-ins\3dxrhino.rhp “3Dconnexion 3D Mouse”
C:\Program Files\Rhino 7\Plug-ins\Displacement.rhp “Displacement”


By the way, I’ve managed to circumvent the problem by adding the geo to the doc and then referencing the document objects and I’m moving again:

    if IntersectBug: # workaround attempt to Intersection Bug
        n2dguid = Rhino.RhinoDoc.ActiveDoc.Objects.AddCurve(n2dcrv)            
        n2dcrv = rs.coercegeometry(n2dguid)

This works for now (which will keep me going) but it’s slow and terrible and there’s still an underlying problem in the API…Please keep me posted!


Hi @will8,

Before calling your TrimCurveByClosedCurve method, do this:

if n2dcrv.Dimension == 2:

– Dale

Thanks Dale,

That fixed it all.

I suppose that I should have mentioned that n2dcrv was obtained from BrepFace.Pullback. Does that imply that you can’t use 2d curves in Intersection.CurveCurve?



Hi @will8,

Surface.Pullback pulls a 3d curve back to the surface’s 2d parameter space. Its useful when constructing Breps from scratch - to fill out the Brep.Curves2D collection. But it does have other uses.

If you want to use the results of pullback in a 3d geometric operation, make sure to change the dimension from 2 to 3.

– Dale