Hi @chris,
I started with 0.001, then 0.01 and 0.1. Also tried 0.0001. Recomputed the solution after each change.
With all those i still get the error.
-A.
Re-computing the canvas doesn’t really change the tolerance that the Ladybug Tools uses. You change the units system this way but, because tolerance changes usually result in weird behavior, Ladybug Tools continues to use the model tolerance that was set whenever you first load up the Grasshopper definition. So you kinda need to restart Rhino if you truly want to change the tolerance.
But, doing this with a few tolerances, I am still not able to recreate your issue.
Could it be that you just have a corrupted version of the sample file where the workaround that I posted for @Geo_curious was not deleted?
Does this version of the sample file still give you the error?
from_building_solids.gh (593.4 KB)
For the record @AbrahamYezioro, I have not been able to repeat this problem in later variations of the
from solids workflow. It was probably the way I was rotating in the mesh objects from OSM2World. I do not know if you are using the same objects, but bringing similar meshes into the workspace then manipulating them along the CPlane before beginning the from_building_solids workflow is likely the source of my problems.
Unfortunately it does @chris
I defined two new Rhino templates with 0.1 and 0.01 tolerance and set them (each at a time) to be the default at starting Rhino. Of course restarted each time.
Still get the error.
Well, it will be one of those that enters into the category of “mystery”.
Thanks,
-A.
Ahhh, I was able to recreate it!
I looked back through our discussion and I saw that you said you were using Rhino 7 SR 15 instead of the SR 14 that I was using. So I updated to Rhino SR 15 and the issue was there.
I guess McNeel must have changed the intersection functions of RhinoCommon SDK again. @piac or @wim could probably confirm this.
I’ll try to push a fix to the latest development version of the plugin that works with both the old and new SR. In the meantime, it might be wise to have students pause the auto-updating of Rhino if they’re planning to use the last stable release of the LBT plugin.
Ok, I just merged a fix for this case, which you should be able to get with the LB Versioner in a hour or so:
From what I can tell, the change that McNeel made was completely under the hood of the
Rhino.Geometry.Brep.CreateContourCurves function and nothing publicly changed on the method itself. But it’s clear to me that certain intersections towards the bottom of the Brep that were succeeding previously were no longer succeeding in Rhino version 7.15. So my workaround is just to add 2 * ModelTolerance to the lowest section plane used to make contour curves over the Brep and this seems to get it to work. Importantly, I needed to only add this 2 * ModelTolerance in Rhino version 7.15 and above since this addition seems to break things in the earlier versions of Rhino.
If @piac or @wim has a suggestion for an alternative fix for this case that doesn’t involve me sensing the service release of Rhino, I would be interested in hearing it.
2 Likes
It was too soon … for me.
I updated with the versioner, also updated to the last Rhino SR, but the issue persists.
Don’t know what to say.
-A.
Yes, I can see that the fix hasn’t made it through our CI yet. It should be there in another 20 minutes or so.
Thanks for being prepared to test it.
Hi @chris
this is a question for someone on the brep intersection team.
I’ve created RH-67429, where you can follow progress.
To help the team, would you be able to send the original non-intersection geometry and the intersection call you use, without other components or installation overhead? (This would be a reproducible case). I’ll then assign it to someone on the team. There is already enough food on my plate with mesh intersections 
Thank you!
Giulio
–
Giulio Piacentino
for Robert McNeel & Associates
giulio@mcneel.com
1 Like
Thanks for the response, @piac . If you want a file that recreates the issue without any dependencies on Ladybug Tools, here it is:
sample_intersection_issue.gh (182.2 KB)
In Rhino version 7.14, all of the Breps in that sample above would produce an array of PolylineCurves that together formed a closed planar curve for each Brep. As you see from the screenshot in Rhino 7.15, most of these intersections now produce empty arrays. Furthermore, the few Breps that are still capable of producing an array of PolylineCurves do not make closed curves.
As you see in the code, this intersection is being performed right at the lower boundary of the Brep so I know it’s a bit of a grey area in terms of whether the intersection should succeed. I’ll understand if we ultimately decide that this is just a case where we’ve now realized that the intersection should not succeed, in which case the workaround I implemented above is here to stay. But, if you are able to provide some backwards compatibility for the older success of the intersection, I’m sure it will make the lives of Ladybug Tools users a bit easier.
I hope that helps and let us know if there is anything else that we could provide to help.
1 Like
Hi Chris,
Greg Arden (greg@mcneel.com) here from Robert McNeel & Associates. Thanks for reporting this. This was a bug in the Rhino Contour functions exposed in the RhinoCommon SDK. If an entire face of a polysurface is within tolerance of the contour plane then the result of the contour calculation should include that entire face.
This has been fixed in the 7.17 release of Rhino. You should be able to download a release candidate now.
Please let me know if you have a chance to test this. I’d certainly like to know if this fixes your problem.
1 Like
Thanks for the fix and for letting us know, @GregArden . I’ll try to test with the new release candidate tomorrow.
I verified that the the 7.17 pre-release gives me the expected behavior that I had previously. I have a PR ready to merge on our end.
Thanks again for the fix!
1 Like
Hello, I have actually the same issue, and since I am a newbie in Grasshopper I would really aprecciate some help. First I must mention that I haven’t used OSM2World, I had a gml with 3D Data which I transformed into STL and after opened in Rhino, now I have closed poly surfaces. I am trying to prepare the DF model to use specifically UWG, but I am having this problem that you are discussing about. I would like to know where should I change the script in which section, which script exactly should I use?
I am attaching the Grasshopper and rhino model that I have made, I would be grateful for any kind of help!
https://drive.google.com/drive/folders/1qoUpHkzpnQ8FXos4UEC51y_v7bAPRpFL?usp=sharing
Hey @Kristi ,
It looks like the tolerance of your Rhino Model isn’t the “real” tolerance of the OSM geometry that you’re working from here.
I was able to get the component to run successfully by moving up the floor height of the first floor by 2cm, which tells me that the bottoms of your Brep geometries are not really flat to within your Rhino model tolerance of 0.01. So the best recommendation is to clean up your geometry further so that the floors are truly flat. In the meantime here’s a version of the component with the temporary hack that lifts the bottom floor height up by 2 cm by adding this to line 120 inside the component:
floor_heights[0] += 0.02
Creating the DF model.gh (184.6 KB)
Dear Chris, thank you for your answer. I have now a new model with more than 8000 buildings.I wanted to ask what you mean by cleaning? I cannot go and check each of the 8000 buildings 
. Do you have any other suggestion for it, also with the new model “floor_heights[0] += 0.02” I increased it more, which makes it not realistic, and even now many of the buildings cannot be part of the simulation.
I would really appreciate some help!
Best
Hi @Kristi ,
I’m sure that you can find a way to automate it since Grasshopper is a visual scripting interface but it’s up to you to find the method that you think is most appropriate. Something like taking the bottom of the OSM Brep geometries, projecting them into the XY plane to make sure they are flat, and then using the “From Building Footprints” Dragonfly workflows is one thing that would get the geometry to be acceptable. But there are other ways to do it that have various tradeoffs.
Hello, I couldn’t still find the right method to deal with it, I also need to identify the elements that are creating the issue. Is there any function that does this and identifies the object that gives the issue, as an example in the picture down I have many objects under Office Solids and some of them are creating the issue, I can identify them with a slider if they are 1 to 40 buildings but I have far more thousands. I searched if there were any functions but couldn’t find them. I would really appreciate your help.
