Solve Adjacency Issue: Unwanted surface

Hi everyone,

Have come across an issue with the ‘HB Solve Adjacency’ tool. As I pass my rooms through, it finds an unwanted ground surface (shown in light red below).

The intended geometrical should follow as the second part of the model, with the open atrium in place. I can’t find anything in the original geometry which would indicate why the surface has been created. Further, this issue only occurs on the intersection between the top two floors.

Any advice / insight on this issue would be appreciated, thanks !

1 Like

Hi @FelixMallinderBH, can you share a minimum example with us to recreate the issue? @chris is the right person to help you with this question.

Hi all,

Here’s an isolated example. I’m guessing it’s a tolerance issue, but I’m not sure how to fix it.
Intersect Issue.gh (74.5 KB)

Before HB Intersect Solids

After

Appreciate any thoughts on how to handle this.

Cheers,
Charlie

Interestingly if the intersect is run before making them HB Rooms (ie on the breps) it seems to work OK

Thanks for reporting this, @charlie.brooker and @FelixMallinderBH ,

This is definitely a tolerance issue and I was able to figure out exactly why it is happening.

First, I’ll explain why everything works when you intersect the Rhino Breps before creating the Rooms. This is because, when you connect Breps to the component, the intersection calculation runs using Rhino’s intersection methods, which are extremely reliable for planar geometry. So, when all else fails, you should always be able to fall back on that.

However, having to run the intersection calculation before creating the Rooms sometimes forces people to set up their Grasshopper scripts in a manner that they would rather not do. So we recently added the ability to connect Honeybee Room objects to the Intersect Solids component but, when you do this, the intersection calculation runs using Python methods that we recently implemented in ladybug-geometry. These methods were initially not all that reliable but I found that, as long as I snap the polygons of adjacent faces to one another before doing the intersection, the result becomes very reliable.

I was doing this polygon snapping for the boundary of each planar face but it seems that I forgot to do it for each hole polygon within the planar face (or I probably thought the case of hole-to-hole intersection was not very common at the time). In any event I just implemented a change that does the snapping of the holes:

… and I verified that this gets your case to be intersected correctly:

The fix should be available with the LB Versioner in a couple of hours and it will be in the next release of the Pollination installers. Until then, you can use the Rhino Brep method to get something that works.

But congrats on finding the edge case that I thought no one would ever encounter when I first put together this intersection code :slight_smile: . At this point, I should just accept that anytime I tell myself “no one is going to try using the software like that,” I have at best a year before someone finds and reports the case.

5 Likes