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
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.
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.
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
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:
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’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.
This is not really a LBT problem that you are seeing. This is how you are setting the geometries in Rhino. Grasshopper would allow you to script an individual solution or you want manually manipulated them in the Rhino visual pane. Chris mentioned snapping this to the XY plane. There are many features in Rhino to do this. I would start by learning the basic Rhino methods to do this before returning to your LBT problem.
Thank you very much, as it is understandable I am new in Rhino and Grasshopper too, I know that it is a problem In Rhino, but I thought maybe grasshoopper had a way to identify the object who don;t have the adequate properties to comply with the functions. The file I have is a conversion from a city gml file and maybe that is why it creates problem. Thank you!
One thing I would point out — starting out with thousands of building in Rhino is probably not the right approach for ease of learning. Perhaps you can cut your learning workspace down to 20 structures, develop a method that works for solving the errors, then go bigger.
I agree wholeheartedly with what you said, @Geo_curious . Making an urban model with hundreds of Buildings is not a recommended way to start working with Dragonfly. Still, I realize that a lot of people have encountered this issue of Stories not having a Room2D when using the “From Building Solids” workflow in particular. It seems like there are just a lot of cases where the Rhino intersection of the solid Brep with a horizontal plane does not return a result. Because rebuilding the geometry usually fixes it, I assume that it has something to do with tolerance but I haven’t always been able to explain why it fails so I’ve just decided to improve the messaging of the DF Building from Solid component when this happens. Instead of throwing an error, the component will now give a warning whenever it fails to make a Building from a particular solid Brep and the warning will give you the index of Brep that failed so that you can isolate it and rebuild it:
. 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.
