Different Results using GH 'Equality' vs. Rhino.Point3d.Equals()?

Grasshopper
1

Hi all,

I am having a really funny result I wonder if someone can help me with?

I’m trying to locate an intersection face between two irregular shaped, closed polysurface breps. They are both funny shapes, but I’ve been super careful to subdivide the faces so they should match perfectly. I’d like to be able to find this inbetween face using GH:

Screen Shot 2021-01-23 at 11.14.31 AM
Screen Shot 2021-01-23 at 11.14.31 AM1191×839 210 KB

So just going through and testing face vertices for equality to find this face. But sometimes it seems to fail to find coincident vertices, and then sometimes it works ok? In GH, if I use the ‘native’ Grasshopper ‘Equality’ component to try and evaluate vertex equality, it gives me a different set of results than if I use the Rhino.Point3d.Equals() method?

using ghpythonlib.components.equality() gives me all the vertices I’d expect in this case (9) but then using Rhino.Point3d.Equals() only finds 5 vertices?

Screen Shot 2021-01-23 at 10.54.22 AM
Screen Shot 2021-01-23 at 10.54.22 AM1528×654 189 KB

Python code below:

import ghpythonlib.components as ghc

matching_verts_ = []
matching_verts_using_eq_ = []
matching_verts_using_gh_ = []
matching_verts_using_rh_method_ = []

for i, top_vert in enumerate(_top_verts):
    
    for bottom_vert in _bottom_verts:
        if ghc.Equality(top_vert, bottom_vert).equality:
            matching_verts_using_gh_.append(top_vert)
        if top_vert == bottom_vert:
            matching_verts_using_eq_.append(top_vert)
        if top_vert.Equals(bottom_vert):
            matching_verts_using_rh_method_.append(top_vert)

Also, if I make a simple copy of the geometry (hold ‘Alt’, click and drag) I get yet even different results:

Screen Shot 2021-01-23 at 10.59.22 AM
Screen Shot 2021-01-23 at 10.59.22 AM1480×675 236 KB

In this case, GH now fails to find some of the intersection verts it was able to locate on the original?

So I don’t really understand what I’m doing wrong here or whats happening to give me these different results in these cases? I’ve tried adjusting the ‘tolerance’ in Rhino / Properties / Units but that doesn’t seem to have any effect one way or another? Can anyone maybe shed some light on whats happening here and how I can model properly to avoid these issues in the future? This is just one small bit of geometry from a larger model and I’m seeming to have these ‘mismatch’ issues a lot (like, a lot a lot), but always rather unpredictably? Can’t seem to get a handle on whats causing this or how to avoid it.

Is there some other ‘tolerance’ value that is being used someplace for the GH equality that is different that the Rhino.Point3d.Equals() tolerance?

Any help would be much appreciated! Rhino and GH files attached here (Rhino 7)
thanks for any advice!
@ed.p.may

vertex_equality_example.3dm (717.1 KB)
vertex_equality_example.gh (18.9 KB)

2

Note that the Equality component operates on numbers, not points. When you feed points into the component inputs, they get converted into numbers based on their distance from (0,0,0).

Secondly, you really don’t want to test for exact equality between floating point data. There’s just no way it will be reliable. You must switch to a scheme which allows for some tolerance.

3

Ah - thanks @DavidRutten - I was assuming that the ‘Equality’ and .Equals(), when used on something like a vertex, would automatically be using a test of the sort you describe, relying on the document’s tolerance setting - I should not have assumed that.

Makes sense though, I think I get it now - thanks very much for your input!

best,
@ed.p.may

4

Just test with a tolerance. “If distance is smaller than tolerance”

1 Like