Visibility intersect py error

[sperrault]

Hi @chris and @AntonelloDiNunzio
I have an error with visibility percent component when points are beside meshes

I checked Github issues, found this one https://github.com/ladybug-tools/ladybug-rhino/issues/170 and replaced latest intesect.py from github

visibility_intersect py error.gh (11.9 KB)
Cheers,
Sebastien

[AntonelloDiNunzio]

Hi @sperrault,

Thanks for checking. I can replicate the error but only with Rhino v7 SR3. Are you using Rhino7?
The intersection can be simplified with Rhino7 because if it does not find obstacle it gives you an empty Array:

int_obj = rg.Intersect.Intersection.MeshLine(mesh, lin)
is_clear = 0 if int_obj else 1

Best,
Antonello

[chris]

Thanks @sperrault ,

With the new fix, I can’t recreate it on my end and I am using Rhino 7.3

Make sure that you are restarting Rhino/Grasshopper after running the “LB Versioner” component.

[chris]

We should also get someone from McNeel’s thoughts on this since I know, usually, McNeel tries not to change the behavior of RhinoCommon like this. Maybe there’s a good reason for it, though.

This is the specific change that I had to make in order to accommodate the change in the RhinoCommon MeshLine Intersection function:

fix(intersect): Fix the recent change in RhinoCommon intersection return

@eirannejad or @wim ,
Do either of you have any idea why this behavior recently changed in RhinoCommon?

[piac]

@chris

We should also get someone from McNeel’s thoughts on this since I know, usually, McNeel tries not to change the behavior of RhinoCommon like this.

Hi there @chris,

you mentioned @wim, and he’s been so kind to point me to this discussion. We added an overload to the function.

As I am sure you know, IronPython sometimes treats out parameters in a special manner.

In 7.3, we added an overload without the out int[] faceIds argument, because it was apparent that many people weren’t using it. This resulted in a change of the return value for the places where the function is called without the clr.Reference[System.Array[int]]() third argument.

We also made the return value for (faces) behave similarly to the return value for (points). (points), in the example above, used to return an empty array in case of no hits, while faces was returning null. Given that the null part was not documented, it was probably just an oversight. But this is not immediately the issue you noted. Conversion of an empty array or None in Python to a condition gives the same behavior.

Thanks,

Giulio

–
Giulio Piacentino
for Robert McNeel & Associates

[sperrault]

As you mentionned I needed to restart… Thanks for your help !

[chris]

Thank you for the thorough explanation, @piac , and I definitely understand. I just wanted to make sure that the change was intentional and that we were right to edit our Ladybug Tools code for this case. It comes at an opportune time as we should have a stable release soon. So there hopefully won’t be too many users who will have to jump to the development version of our plugin to get the fix.

[jaredf]

@chris I don’t believe the logic in the update to the intersect.py file was correct as it appears to result in everything reporting as is_clear = 0 (hence the VisibilityPercent tool not working correctly even if it doesn’t throw an error). It seems like the RhinoCommon update results in inverse behavior with the intersect_line function. It would be nice to have it work in both the previous and newer Rhino versions as I imagine it might be some time before everyone is on v7.

I made a separate function to check for this that seems to have worked on my end at least. Definitely a cleaner way to do this, but I pasted the code snippet below if it helps:

def is_clear_check(int_obj):
        '''Check if the line and mesh interesect and return 0 or 1'''
        if int_obj[1] == None:
            return 1
        elif int_obj[1][0] == 0:
            return 1
        else:
            return 0

def intersect_line(i):
        """Intersect a line defined by a start and an end with the mesh."""
        pt = start_points[i]
        int_list = []
        for ept in end_points:
            lin = rg.Line(pt, ept)
            int_obj = rg.Intersect.Intersection.MeshLine(mesh, lin)
            is_clear = is_clear_check(int_obj)
            if RHINO_VERSION >= 7.3:
                is_clear = 1 - is_clear #this inverts the 0s and 1s depending on version 
            int_list.append(is_clear)
        int_matrix[i] = int_list

[chris]

Hi @jaredf ,

I know that @AntonelloDiNunzio told me he tested the new solution in both Rhino 6 and Rhino 7. Maybe he didn’t check what the results look like, though, and only saw that it didn’t fail. Let me do a test for myself and see if I also get the issue.

[chris]

Thanks for pointing this out, @jaredf . I verified that you are correct that the change didn’t work in Rhino 6. So I reverted it back to the original fix that I had, which I have tested twice to be sure it works in both Rhino 6 and Rhino 7:

fix(intersect): Revert the change that wasn't fully tested in Rhino 6

I think I will also update the installer of LBT 1.2 so that this fix is in there.

[jaredf]

Thanks @chris. I still think there’s an issue with your original fix in Rhino 7.3+
See example below:
Results in Rhino 6 (correct)

Results in Rhino 7 (incorrect)

[chris]

@jaredf ,

Perhaps your Rhino model units and tolerance are not the same for your comparison there. The new code is definitely working for me in Rhino 7.4:

[jaredf]

@chris thanks again for your help. I don’t believe it’s a units issue considering all my geometry is internalized within gh.

I updated my Rhino v7 from 7.3 to 7.4 and now I’m seeing at index out of range error, which makes sense given the objects returned from the MeshLine intersection don’t always have more than one item.
visibility_error.gh (39.1 KB)

I tried it with some different geometries and had the same error in Rhino v7.4, so I’m guessing it’s something with my Rhino settings if it’s working for you, but just in case you want to test it I’ve attached a sample file that triggers the issue in Rhino v7.4.

I can make it work for me by editing the intersect.py file, but I’m still confused as to how the current code is working for you in v7.4.

[chris]

You are right, @jaredf . I think that both of the test cases that Antonello and I were using did not cover all of the possible failure scenarios. @AntonelloDiNunzio gave me a version of the code that works for all of the cases that I have available, including your case. I just merged it:

fix(intersect): Implement (hopefully final) fix for Mesh/Line intersect

You should be able to get it with the versioner within an hour or so.

[jaredf]

Thank you! You guys rock!

[piac]

@jaredf

inverse behavior with the intersect_line function

This is something that I had not figured out before or read. And that we certainly may want to fix if true. Let me test this… RH-63482

EDIT. I’d need more help reproducing because I cannot see when that happens.

[jaredf]

@piac When I updated from Rhino 7.3 to 7.4 it seems to have corrected the inversion issue I was seeing previously.

[GustavoB]

Hi all,

Although I cannot really follow all the code conversations above, I believe I found an issue that is related to this intersect change in Rhino 7. I’m getting wrong results when I run both the Honeybee_Indoor View Factor and also the Ladybug_Surface View Analysis in Rhino 7. But both run fine on Rhino 6. Any ideas on how to resolve would be great!

[TrilithStone]

Hi Chris,

Can you pls tell me how to replace the intersect.py file within Rhino7.4 vesion?
I encountered the same issue, try to get the solution to work.

fix(intersect): Implement (hopefully final) fix for Mesh/Line intersect

Cheers,
Lei

[chris]

You’ll be missing a lot of features but you can always go back to LBT version 1.1 as you see in the compatibility matrix:

1.4 Compatibility Matrix · ladybug-tools/lbt-grasshopper Wiki

Upgrading Rhino is the right way to do it, though.