Why Honeybee_Intersectmasses component doesn’t work and without any error in Rhino 6?
When I use rhino 5 Intersectmasses works fine and split adjacent surfaces between zones in same file.
Illustration between two comparison:
In Rhino 6,
It shows RH 6 intersect mass doesn’t work.
In Rhino 5,
Did you check the tolerance in both documents to be the same?
Hi @mostapha, thank you for the response. Yes, all settings include unit and tolerance in both are the same.
Thanks! Can you share your model? and you input for tolerance. Let me see if I can replicate the issue locally.
No! I realized my Rhino 6 trial version is actually expired.
One suggestion is to try a higher tolerance value. 0.001 should be good enough for any architectural project.
Thank you @mostapha for the response, I tried many types of tolerances after your last reply
BTW, Until the problem is resolved I can use RH5 in my laptop.
I still have a valid Rhino 6 trial and I’ll see if I can fix this now. The main issue is that Rhinocommon no longer supports the boolean difference method we used previously to find the intersection. It fails to generate the intersection both in our python scripts and using Rhino commands manually. Thankfully, the other code that we have, which splits the surface using the intersection curve still works. I’ll see if I can write one component that will work with both Rhino versions.
I have found a solution that works for both Rhino 5 and Rhino 6 and I have pushed it to the github:
What is perhaps even nicer about this solution is that it is much faster than the previous one and is far less hacky. The only potential downside for the method is that the previous one could sometimes catch cases of curved surfaces that needed to be split. This one can only split planar surfaces and will always leave all curved surfaces un-split. Given that 99% of the interior geometries that we simulate are planar and the fact that we can reliably say what the component does now (whereas the previous curved splitting capabilities were hit-or-miss), I think we will agree that this implementation is an improvement overall.
I agree as long as we’re giving a clear warning to user about this limitation once they have non-planar inputs!
I can add a warning. Ideally it would be nice if this warning is for the when component fails to make a curved intersection and not when any curved geometry is connected. This may be tough given that the component doesn’t know if a given surface is on the interior or not. Let me see if I can make this work but it will take me some time. If I can’t get it to work, is it still a good idea to give a warning for any curved geometry? I feel like the vast majority of cases with curved geometry are exterior (like a dome).