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:
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:
@eirannejad or @wim ,
Do either of you have any idea why this behavior recently changed in RhinoCommon?
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
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.
@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
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.
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:
I think I will also update the installer of LBT 1.2 so that this fix is in there.
@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.
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:
You should be able to get it with the versioner within an hour or so.
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!