Checking and finding the identity of solids/breps

Hello Guys

I am trying to write a universal definition for finding identical solids
made the 3rd option they produce different results
While the script was built on simple cubes of different colors
but for more complex bodies they do not work !!!

maybe someone already has a definition for finding the same bodies?
Or ideas how to identify the same body? can share please?
or maybe there is a definition for the python and c#?

or maybe there is some kind of plug-in to the grasshopper with such a function?


in brep.gh (25.0 KB)
identical breps.3dm (53.0 KB)

Indeed I did a thingy that attempts to do that long time ago (NOTE: object equality is NOT like comparing 3 to 33). If you are interested I must search to find(?) it … but what was the name? what was the directory name? and in what workstation? .

1 Like

Peter, can be lay out the definition?
or tell me please how to do through a grasshopper?

As I said the only thingy MIA is where the C# is. But I do hope that I’ll find it soon.

In the mean time (If memory serves well):

It worked by testing equality (given a reference Brep VS a candidate one) based on Brep Area, Volume, NofLoops, NofEdges and equality (1:1) on edges length. This is NOT an assured/safe way to tell that your 2 Breps are “equal” … but as I said object equality is a big rabbit hole.

1 Like

I guess that this is one of them - found in practice - but I have a feeling that far more (?) elaborated (?) defs are (?) at some home workstation (???).

As always no internalized stuff (NEVER do that with breps) … meaning that you should load the R file for the demo case.

IM Q: Does this thing cut the mustard 100% ? Not even close to half empty I’m afraid.

object_equality_textDot_V3A.gh (131.8 KB)
object_equality_V3.3dm (1.4 MB)

1 Like

I’m at home now.

Guess what? Found a far better def (and 400% faster).

Recycle that faulty (has 11.452 bugs [min]) and stupid and crap and pointless C# posted above and use this:

object_equality_V5.gh (129.7 KB)
object_equality_V5.3dm (1.4 MB)

2 Likes

BTW: Finish this (get all the BrepFaces blah, blah).

Is the last check (not included in V5) that maybe(?) can quide you out of that ugly rabbit hole.

object_equality_TheLastCheck.3dm (305.0 KB)
object_equality_TheLastCheck.gh (117.9 KB)

1 Like

Peter,
Thank you so much!!!
You are a great master
thank you very much for your work!!!

For big N of Breps (of different “type”) this leads ultimately towards machine learning matters:

For instance for rectilinear geometry the volume has no cost but for blobs … etc etc. On the other hand the last check (iso trim aware curves) as above takes ~4 milliseconds per BrepFace (if you do that on V5 [ filter = 3] Elapsed time grows from ~15 milliseconds to 150++.

Meaning that the ideal solution is to mastermind the collection of filters according the “type” in question. Quite challenging I guess (and requires days of testing since in coding chances are that you’ll encounter lot’s of cases/combos that you haven’t predict).

And last … well … stuff like this may look “handy” but is not the fastest bunny around:

BTW: Change the Method as follows (faster and safer):

BTW: Since int comparisons are waaaay faster than double ones … maybe Topology filtering should being used first (in the BrepInfo class) via stuff the likes:

Using finer coding techniques (i.e. switching from raw Tequila to Margarita) here’s the trad update:

object_equality_V5A.gh (131.0 KB)