BUG: CurveMeshIntersection?

I am having a hard time understanding why a curve mesh intersection reuturns so many intersections.

I have curves drawn from a point to the vertices and the CurveMeshIntersection seems to return an intersection for each face, regardless of this being the same point. (If four mesh faces meet in one point, then CurveMeshIntersection returns four intersections, but I only want it to return one).

Can this be one of the reason for why SplitMesh is so buggy too? If I try to split a large mesh with a curve, and the curve passes through a vertex then I am almost guaranteed to get a faulty split.

Thanks for any kind of help on this.

1 Like

I don’t know if the CurveMeshIntersection function can be cleaned up or not, but a workaround right now would be to use CullDuplicatePoints() on the list of intersection points found…


Thanks, I wrote the script so it compares the intersectionpoints to the endpoint and thus solves it, but it isn’t pretty nor fast. So it works in this particular case.

If you know that the intersection SHOULD be just one point (or nothing) you can just take the returned array/list of points if there is one and grab the first item…


1 Like

Sample geometry would be helpful to us…

Any mesh geometry will generate this, it is predictable, as all mesh faces will return an intersection.
(Edit: That is not accurate, so it’s a good thing you look into it)

I made a sample script to illustrate this as clearly as possible.
It uses the camera as one end of the intersect line and each vertice as the other end of the line.

import rhinoscriptsyntax as rs
import Rhino

mesh_id=rs.GetObject("get mesh",filter=32)

for i in range(len(listPoints)):
    listIntersect=rs.CurveMeshIntersection (curve_id, mesh_id, return_faces=False)
    print len(listIntersect)
    rs.AddTextDot (len(listIntersect), listPoints[i])
    rs.DeleteObject (curve_id)


curveMeshIntersect_file.3dm (45.9 KB)

Got it, thanks.

The rs.CurveMeshIntersection method, which calls Rhino.Geometry.Intersect.Intersection.MeshPolyline, does not to any culling or parsing. It just returns the results. Since you know you know mesh vertices will be hit, culling the resulting duplicate points is a good idea (as Mitch mentioned).

Hi @dale so this culling will be done in the command in an future update? (That’s what you meant by “Got it” right?)

If the curve didn’t intersect at the end, as it does in my example, but rater somewhere along the curve, then it would be much better if I didn’t always have to cull the results to see if there are duplicate points returned.

I have a made a workaround for the tool I needed, so I am ok for now.
I made a “is the vertex visible from the camera” script to see what areas of a landscape can be seen from the point of view. It is slow, and can probably be done much faster, but it was the only way I could figure out how to solve it. (I compared all intersections to the endpoint, and if they differed then that vertex was not visible)

No, the method will always just return the raw intersection data. Without the duplicates, you would not know you “hit” a vertex. If you don’t want duplicate points, then you can prune them if you want.

That makes sense. Culling it is then. Thanks.
And maybe this could be addressed in the help file.