FINDING OUT IDENTICAL POLYSURFACES

Hello Grasshopper users,

Can someone help me with the following problem.

I have a large scale 3D model.
And I need to find out the similar objects.

If one 3d geometry same of another then they must take the same names, else they must have different names.

Based on this lojic i would do fabrication drawings. and i dont want to end up with unnecessary work load in preparation of fabrication drawings.

Your helps are highly appreciated.

Thanks & Best Regards

Replies to This Discussion

Permalink Reply by Firat Aydin on February 24, 2016 at 4:51am

i know
but once you told me i already received this file...
one thing i can do is...

I would explode the blocks ( also sub blocks)

i would identify matching geomteries.
then i can block them up once again...

sorry you are right with it but it was already set up with blocks...

else we can try to find a way work with blocks..

Permalink Reply by peter fotiadis on February 24, 2016 at 5:49am

Dealing with instance definitions is a piece of cake (obviously ONLY via code).

In the mean time what about this? (Rolls Royce of guns, no kidding > highly recommended for this particular thread > who wants to live for ever?):

Permalink Reply by Firat Aydin on February 24, 2016 at 6:19am

come on peter, this challenge is easy busy for you...

Permalink Reply by peter fotiadis on February 24, 2016 at 8:35am

You mean that I have more than 150 C# thingies that do any imaginable job with instance definitions? (mild, wild, freaky, paranoid ... anything).

If so ... well ... it's a shame ... but I confess that I have only 148.

Shown your stuff under some KGB interrogation.

BTW: there's 2 things in a given doc (with regard instance defs):

The instance definitions (the blocks, that is - nested or not): this means geometry and various other mysterious things.

The referenced definitions (the stuff used in the active Rhino doc from the above collection).

Against popular belief Rhino is NOT lightning fast when inquires the as above collections - but it's at least 1000 times faster than ... er ...the other thing used insofar (WHAT a stupid way to do business).

more soon.

Permalink Reply by Firat Aydin on February 24, 2016 at 8:40am

Ohhh man you are doing amazing things with C#
I will knock your door quite often, (IF YOU DONT MIND ;))

Permalink Reply by Firat Aydin on February 24, 2016 at 9:10am

btw i just noticed your questions.
within the blocks there may be some nested blocks - such as some purlin brackets...

Permalink Reply by Firat Aydin on February 24, 2016 at 9:25am

HEY PETER;

I just want to warn you about an issue...MIRRORS...
imagine that your body is a structure.
and your body is symettrical.
building up your body you cannot use left arm instead of right arm - because they are not symmetrical with respect to symetry axis of the structure.

However you can inter use left and right eyes.
I hope i made myself clear with it.

parts identified to be same must be the parts can be overlayed by using ORIENT3PT command - without mirroring.

Thanks mate - you are a life saver, your cool!!!! #1!

Permalink Reply by peter fotiadis on February 24, 2016 at 11:21am

... within the blocks there may be some nested blocks...

Of course they are (and the depth of nesting is not 2). The whole thing it's structured as it should: properly. That said few understand what assembly/component actually means ... until they get hired in some practice that knows a thing or two on that matter.

BTW: This is a cliche (used for classes in programming) but ... Imagine a cookie cutter (the instance definition) that provides us with cookies that we use in some Rhino document. Chances are that some sort of transformation is used (otherwise the whole thingy is paranoid: cookies stacked each other > why bother?). Now ... we have some cookie made from the cutter and information about where to put the thing. Meaning that the trans matrices are stored and (obviously) used in order to put the #^%# thing in the right place... blah, blah (this answers to the mirror question? eh?).

But there's bad news as well : C# thingies that do something other than Academic ... er... hmm... are classified as internal in my practice (for more than obvious reasons: because they can arm a pro with "some" weaponry, kinda like a proper Glock 40 Gen4, he he).

Thus I'm in a rather delicate position right now (notice that I haven't posted anything related with management of instance definitions: and this is a bit more complex than it appears on first sight).

I'll see this w/e what can I do on that matter i.e. removing a lot of "sensitive" stuff and making some "entry level" C# for this case of yours; but all the WOW things would be MIA.

Permalink Reply by peter fotiadis on February 25, 2016 at 3:54am

For instance see this instance def (a nested one) as it appears in Rhino document.

Now ... let's switch nesting off (on some C#, that is) and ask to see the "parent" instance definition isolated (nesting off) with respect the insertion point (used at instance definition creation time) that is mapped to Plane.WorldXY.

Freaky "codes" (as List) in the pink group are the object GUID's related with the Geometry that is involved on that "parent" thingy.

Black box is a BoundingBox with respect a given index from the as above GUID List.

blah ... blah.

Permalink Reply by peter fotiadis on February 25, 2016 at 5:02am

And finally we arrive to the 1Z question:

What may be our policy with regard instance definitions at creation time? There's 2 answers (the one is wrong):

Thinking the present (the current thing that we do).
Thinking the future (the other things that we'll do).

See the havoc in your file (nest depth flag: off) : meaning that thinking/acting on an assembly/component basis ... er ... is simple provided that you know what are you doing (and why).

Permalink Reply by peter fotiadis on February 25, 2016 at 8:56am

Here's a small (heavily reduced) demo on that matter.

This is NOT like the thing in the above images (that finds the Geometry per Instance Definition): it just tells you where the referenced instance definitions are.

1. The mysterious things in the cyan panel are extracted from your specific file > therefor the C# works ONLY with this file. Nesting information is restricted to depth 1. No trans matrices are taken into account.

2. Adding visual aids: text dots and the likes is the easiest of things (kinda like in the other C# that you have already). Naming conversion ... well ... it's rather obvious.

3. Inspect the structure: not on a pro level with regard a proper assembly/component discipline ... but proper in some way.

Attachments: