Hi,
I am trying to model a simple building but lately I faced rather simple issue which turned out to be unsolvable for me. I tried it with a few of Rhino versions (5.13 to 6.7) and Grasshopper (0.97 to latest) and it all behaves the same. The thing is that when I try to intersect some rather simple geometry, or a case where only 1-2 faces are common there’s no problem (like the L or T shape). But then when I have two masses, where one “huggs” the other, only a few of surfaces have correct intersection while the rest remains “broken”. In a screenshot below you can see that first and second intersection (counting from top) are correct. There are common faces and there is a face desribed as N/A. Second one is probably ok, while the last one looks undone. I think that I simplified the definition as much as possible, so there shouldn’t be other issues. Please tell me if I make some obvious mistake. If that’s the case I also apologise for the spam. But if not… what to do? adjacency.gh (541.1 KB)
It is working fine.
I’m not sure about the BC object attribute but if you pick the Boundary Condition you’ll see the surfaces boundary conditions right. Also all other attributes.
@chris: what is the BC object intended for? I see, from the above example that it shows the internal surface names.
-A.
Well if you start simulation in that situation you’ll get error saying:
** Warning ** GetSurfaceData: InterZone Surface Areas do not match as expected and might not satisfy conservation of energy:
** ~~~ ** …use Output:Diagnostics,DisplayExtraWarnings; to show more details on individual mismatches.
So I’m not quite sure if everything works fine. I’d say that issue occurs in that place. This doesn’t happen in those simple examples that I mentioned (“T” and “L” shapes). I checked what you said and when I try different options I’d say that the issue is still visible. For example when I choose EPlus construcion this long surface is described as interior while half of it should be interior, while the other half - exterior. When I choose - as you said - boundary conditions - it shows “surface” while it should be “surface” on half and “outside” on the rest of it. Same thing goes for sun exposure (whole surface has no sun exposure), wind exposure and so on…
@Avik, I can reproduce the error. Let me check and see what’s going on. As far as I can see Rhino does the initial intersection fine and return intersection curves. We must be doing something wrong in the code.
For now you can use this workaround on Rhino 6 which basically does the same.
Connect the outputs of Brep Join to your energy simulation workflow.
I tested a new approach which seems to work fine for several cases that I tested but I didn’t push it to GitHub yet.
@Avik, can you test this new workflow and report back if it works fine for your cases?
@chris, I know that you have made a number of changes to this component overtime. Do you see any issues with this new workflow. It is simpler and relies more on Rhinocommon.
intersect_masses.gh (17.4 KB)
I did it with pleasure! I tested it with some simple geometry at the begining but then I let myself loose and I tried something more complicated. And I have to admit - saying that your new component works marvelously is definietly not enough! It’s superb! It suprised me how well and how fast it handled all the geometry! Can’t wait for oficial update! Just for the record - I tested it with Rhino 6.7.18199.22081, 07/18/2018, Grasshopper 1.0.0007 and ArchiCAD 22 3006 with LiveConnection.
Last week, I happen to create a C# version with parallel processing capability. It is about 3~4x times faster than current one when there are more than 15-20 breps.
IntersectMass_1.ghuser (3.1 KB)
Thanks !
This is amazing!