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?
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? .
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.
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.
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: Since int comparisons are waaaay faster than double ones … maybe Topology filtering should being used first (in the BrepInfo class) via stuff the likes:
