BuildingSolid Error: Story must have at least one room2D


I am not sure how to overcome this error. I ran into it after preparing new solids on the from_building_solids workflow.
A simplified version is attached. (82.8 KB)



Hey @Geo_curious ,

The Rhino intersection command wasn’t able to produce a floor plate from your geometry because the footprint face was not horizontal to within the Rhino model tolerance. Projecting the footrpint to the CPlane using the Rhino ProjectToCPlane command and then re-extruding it produces geometry that it clean enough to create the floor plates: (67.3 KB)

I think you are saying the problem has something to do with the objects not sitting on the bottom.

Can I just move the objects downward to get it back to the right place, and function? I would rather not lose the entire object file, since these were solids that I did not extrude from footprints. There are dozens of buildings that I do not know the heights to for this workspace. When I attempt the ProjectToCPlane it flattens all the objects along a single plane, leaving no footprints behind.

Could it not have something to do with the BuildingSolids component being 1.3.1 while the rest of the model components are 1.3.0? I do not know how the BuildingSolids component ended up changing the version without the rest following suit. I copy and pasted direct from_building_solids, where the component is 1.3.0 all around.

I switched the component back to 1.3.0 and scrapped the old workspace. The 1.3.1 component would not leave any of my older functioning workspaces with solids. It could have been a combination of the component and a geometry problem. Having no success with CPlane corrections in Rhino, I used an old workspace instead of continuing to fight with whatever the geometry problem was. I believe the 1.3.1 component snuck in by running LB Versioner at some point.

Hi @Geo_curious ,

Yes, the issue is that the bottom of these solids is not flat to within the model tolerance.

Changing the component versions from 1.3.1 to 1.3.0 does not change anything for me (and I don’t know why it would as there haven’t been any changes in the component related to geometry) but there is another way to hack this issue if it’s just not feasible to rebuilding the geometry right now. If you are confident that all of the bottoms of these solids are flat to within a certain value (let’s say 0.2 meters), you can add this to the min floor height that’s inside the component. So you can change this line in the component to the following:

floor_heights, interpreted_f2f = interpret_floor_height_subdivide(
    _floor_to_floor, max, min + 0.2)

Again, this is a hack and the “right” way to address this issue is just to clean up your geometry. But there’s always a way to hack a shortcut in an open source project.

Hi @chris,
Checking the from_buildings_solids example you get this error. Suggest to fix the solids geometry … FYI.


Hi @AbrahamYezioro ,

The sample code that I used above was really only intended as a workaround for @Geo_curious 's specific case but I realize that trying to use it for all cases will result in getting the error in files like the

If you check the latest sample (with version 1.4.0), you’ll see that you don’t get this error, though:

Hi @chris,
Well, it is not working for me:

I’m updated to the latest, and i get this error. This happens without changing the code.
Tried to play with the tolerance but no change.


Are you using something other than Rhino 7 SR 14? Or are you using a Model unit system that is not Meters?

I’m still not able to recreate on my end:

Hi @chris,
No and no.
My Rhino is 7 SR 15 and the units are meters.
Just opening the file as is, no changes at all.


I guess that just leaves one last question: What tolerance are you using for your Rhino model? If it’s less than 0.01, I imagine that could explain it.

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.

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? (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”.


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.


Good detective work @chris ,
Thanks for that.

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.

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.

Happy to report that it is finally working as expected.
Thanks @chris!