Rhino 7 - MeshRay intersection changes

Hi all

I wonder if there were some changes in MeshRay intersection logic since version 6?
I have some unpredictable results with sunlight calculation in my grasshopper plugin in Rhino 7. The plugin uses mesh boxes representing buildings and a bunch of vectors for sun rays. The final goal is to calculate the number of unobstructed sun rays.

The algorithm is basically following:

        Extrusion ex  = Extrusion.Create(crv, height, false);
        var brep = ex.ToBrep();
        var mesh = Mesh.CreateFromBrep(brep, MeshingParameters.FastRenderMesh);
        mesh.Vertices.CombineIdentical(true, true);
        double result = Intersection.MeshRay(mesh, ray);

Since my client started using Rhino 7 there have been some mistakes with intersection between sunlight vectors and meshes. I haven’t figured out yet where exactly the problem is but it seems to be somewhere between Extrusion.Create(), Extrusion.ToBrep() Mesh.CreateFromBrep() and MeshRay().

Is there something in particular I should pay more attention to?


There is definitely a bug with meshes in Rhino 7
I made a quick test file in grasshopper.

Only few rays actually hit the mesh.
I also tried Mesh/Curve intersection and “Oclusion” component - all of them produced different incorrect results.

Gh def is attached
mesh-bug-rhino7.gh (16.3 KB)

1 Like

Some follow-ups:
Mesh Inclusion doesn’t work either
Tested on Rhino 7.2.20343.11011, 12/08/2020

@stevebaer, @DavidRutten could you guys please have a look at this issue?

test-file: mesh-bug-rhino7_upd.gh (20.7 KB)

The problem is that your geometry is “infinitely” far away from the origin, a longstanding well known issue. Move it near the origin and it works fine.

mesh-bug-rhino7_2020Dec16a.gh (25.4 KB)

P.S. To clarify, I should have used your slider value (100K?) as the ‘R’ (Radius) input to IVRay:

mesh-bug-rhino7_2020Dec16b.gh (25.9 KB)

Why such big number values? I know, you’re working in millimeters? Get a grip on that.

1 Like

Hi Joseph!

It looks like moving closer to center can indeed solve this issue.
But the problem is that if you open that test file in Rhino 6 it would work fine regardless of location. And I can’t easily scale down everything in my project because all the dimensions are interconnected with other rhino and revit-plugins. Scaling would involve re-writing and debugging a lot of code.

It would also be quite inconvenient to use meters because I work with buildings and export everything to revit. The location is so off-centered because it uses GIS data with a city center as the origin. Depending on the site location buildings can be quite close to the origin as well as far away.

It’s a bit frustrating that my perfectly working Rhino 6 projects suddenly became incompatible with the new release.

I sympathize with your frustration that R7 breaks models that work fine in R6. Same thing happened going from R5 to R6. McNeel doesn’t care and that is way beyond annoying…

However, I don’t have much sympathy for using coordinate values and dimensions that are so extremely large. Good luck.

Thanks for the sample; I’m trying to figure out who on our team needs to investigate the issue.


You guys are right; we should improve here!

This code does NOT use the new Rhino 7 intersector. I should see how to tweak it to use it or get help to move back to the same results of Rhino 6.

I reported RH-62060 regarding Mesh|Ray and RH-62109 regarding inclusion.

I’m joining Steve in thanking you all for your accurate reports and help.

1 Like

I was checking what to do with Mesh|Ray and MInc, and looks like there will be some improvement.


Rhino 7 SR2 will use the new intersector for both Mesh|Ray and the Point-In-Mesh inclusion test. RH-62060, RH-62109.

Please let me know if you notice anything, both good and bad! :slight_smile:


RH-62060 and RH-62109 are fixed in the latest Rhino 7 Service Release Candidate

A post was split to a new topic: MeshRay slow in 7 SR2