I opened your model but it looks fine to me. When you open the model, what are the units of the rhino file?
It should be set to meters.
1 Like
What? 
That’s so strange…
I’ve had a colleague open the same definition that I posted here, and she also gets the warning message
Strange! I can not find the reason why this is happening. Maybe you can have a look at the report output.
What happens if you change the tolerance to 0.001 (probably you’ll need to restart rhino, since LBT routines don’t get updated, even with recompute). Change that before opening GH.
-A.
I have a guess as to what the problem might be. You might be using a LBT 1.3 component while having the LBT 1.4 core libraries installed. There was a tweak we made to the room-solidity check between version 1.3 and 1.4.
Do you still get the same warning after you run the LB Sync Grasshopper File component?
Hi @chris,
I have used the Versioner and the Sync component, recomputed the definition, even restarted Rhino with absolute tolerance set to 0.001 as @AbrahamYezioro suggested, but am still getting the error:
unnamed.gh (29.7 KB)
it looks like you have a non-planar surface:
Look at the additional “seam” on the “valid” geom, vs the original:
tf_edit.gh (61.1 KB)
The HB planarize brep is going to handle it slightly different than the cap holes ex component:
The “bad geom callout” is courtesy of the Pollination Rhino plugin, wicked nifty for troubleshooting geometry!
Hey @TrevorFedyna, thanks so much for that analysis, I didn’t know the HB Planarize component existed!
By “bad geom callout”, do you mean there is a command in the Pollination Rhino plug-in that shows surfaces that are non-planar? Do you know what else it checks for?
I still find it wild that when I rebuild that geometry in Rhino it still has the nonplanar surface in it, despite it being an extrusion It’s almost like I should be posting this to the Rhino forum…
Hi Max -
Only almost? 
It being an extrusion doesn’t have anything to do with things. When you extrude a circle, you are not going to end up with planar surfaces.
It all comes down to document tolerances. Two edges of your ground plan are 0.12° off from being straight. The document angle tolerance is likely set to the factory-default of 1 degree. If you change this to 0.1°, you should see that two surfaces are created in that location, instead of the one non-planar surface now.
-wim
The way that the community is split on being able to recreate this issue makes me think that it results from a change between Rhino SR 14 and Rhino SR 15. We’ve already had one breaking change that happened as a result of the update and my intuition is telling me something similar is at work here.
I updated to SR 15 a week and a half ago and I am able to recreate the issue. The Brep has non-planar faces and there’s no doubt about that. The quick fix is to do what @TrevorFedyna suggested and pass it through the “Planarize Brep” component before creating the Room. For now, I am adding an extra step into the code of the the “Room From Solid” component that does exactly what the “Planarize Brep” does so that things will run smoothly for this case without the need to use “Planarize Brep”:
The reason why we seemingly didn’t have this issue in SR14 is that the RhinoCommon Mesh.CreateFromBrep method seems to have changed. This method used to yield a list of meshes that formed a closed volume when the input Brep was a closed solid. Now, this returns a list of meshes that don’t perfectly touch each other when simplified unless they are joined back into a closed Brep.
@wim , I have been trying hard to put together an example file that can recreate the issue using only RhinoCommon but it’s been challenging since it seems this change was subtle. I can say that it has something to do with the fact that the simplified edges of the planar and non-planar parts of the Brep don’t perfectly touch each other:
planarizing_brep_in_Rhino7_SR15.gh (24.4 KB)
But I guess I can’t really complain since the distance between the points and the curve is less than most model tolerances. And, like I said, I can join all of these simplified Faces into a closed Brep. Maybe it’s an issue that results more from angle tolerances rather than the absolute tolerance?
2 Likes
Hi @wim, the reason I was expecting the extrusion to contain only planar surfaces was that the profile curve is a polyline.
I see what you mean with the angle tolerance. I didn’t realise that ExtrudeCrv gets rid of these instead of creating kinks in the geometry as I would have expected:
However, setting the angle tolerance to 0.1 gives me the exact same result
@chris FYI, when I manually delete those control points with the arrows above, the RoomFromSolid component works without an error (this was with default angle tolerance of 1), despite that other wall still being non-planar:
Hey Chris -
I’ve been looking at this for a longer time now and am not even sure what I’m looking for 
There’s definitely something going on with extruding polylines creating non-planar surfaces - I’m throwing this on the list as RH-67628 …
… but that issue is also present in Rhino 6, so not related to any changes between Rhino 7.14 and 7.15.
Have you checked the latest comments in RH-67429? That points to a regression between 2 internal 7.15 versions. I can’t tell, but do you think that this might be related to what we are seeing in this thread? If not, I’ll take a closer look at your Grasshopper definition!
Hi Max - thanks for pointing those out - this example went into RH-67628 that I linked to above.
-wim
Sorry that my sample ended up being more confusing than helpful, @wim . @MaxMarschall 's example is much better and illustrating the unexpected behavior.
And you’re also right about Rhino 6. I should have checked that before jumping to conclusions. This means that I can’t explain now why @Erikbeeren was able to run that geometry through that component and get a closed solid. However, I see he is using version 1.3.0 of our software so perhaps I made a change between version 1.3 and 1.4 that would cause this.
In any event, the most recent development version of the LBT software has everything working as expected. If we end up finding out more how the extruded polyline made a non-planar surface, perhaps I can implement a better fix for this case in our plugin’s geometry processors.
1 Like
Hi @chris
I had 1.4.0 installed on my computer. The grasshopper file from @MaxMarschall however contained the 1.3.0 nodes. When I opened the file, the 1.3.0. nodes where there and somehow worked.
1 Like
I’m sorry to report that HB Intersect Solids is giving me some trouble with the afore mentioned issue. Somehow geometry that was perfectly functiontal a few minutes ago somehow got corrupted after tweaking an unrelated part of the grasshopper definition. I will upload a screen capture and the .gh file in case you want to take a closer look, take a look at item 1 in both lists. All the geometry has been previously generated from simple perimeter polylines extruded with Z vectors. Neighboring room shapes had exactly the same control points so there are no gaps.
I tried baking the geometry and referencing it back with short lived success. I also tried using the Planarize component but nothing changed. As Chris suggested, using Legacy’s IntersectMassII worked just fine.
I have the latest version of LBT and Rhino 7 SR18 and four digits of tolerance on my units, which are set to meters. Beats me, I hope any of you guys can work it out.
Intersect Solids Debug.gh (183.8 KB)
It is working fine with me.
My tolerance is set to 0.0001.
-A.
Thanks Abraham, must be something wrong on my side then. I restarted my computer and now it’s working once again.
Thanks for taking the time for checking, @Erikbeeren. I’m still puzzled about what could have led to the issue. The original file was much more complicated and extensive. At some point I duplicated the model and then incorporated some more components to generate additional geometry and after a while I noticed I had a HB Room from Solid that had turned orange, which in turn was caused by an Invalid Brep.
This wasn’t the first time happening so I decided to come here and report. I will keep you guys updated in case it happens again.
Edit: Yes, units tolerance was fine.