Finding same geometries from two lists

Replies to This Discussion

Permalink Reply by Danny Boyes on January 28, 2011 at 2:51am

hi Jordan,

 

It's quite time consuming (processor) but decomposing each point into X,Y, and Z and checking there equality to a Grafted List, which forces a cross reference, will get you your overlap. Each separate component must pass through a Ternary And Gate to find which point on each list is equal. The results of this are a boolean pattern which you can supply to a Cull Pattern component.

 

 

Permalink Reply by Jordan Barr on January 28, 2011 at 6:59am

Danny,

Thanks for the tip. I think that I may be missing a step in your explanation because I've now decomposed the points and have compared the individual coordinate elements but I am only getting 12 overlaps.

 

I've attached my files again, but where does the grafted list come into play and/or how do I use it properly?

 

Thank you,

Jordan

Attachments:

• Wall color.3dm, 92 KB
• wall color-two elements.ghx, 1.6 MB

Permalink Reply by Danny Boyes on January 28, 2011 at 8:10am

The upward arrow on the input of the lower decompose component indicates that the stream has been Grafted using the right click context menu on the input. You could also use a stand alone Graft component between the CP output and the decomp input. The dashed lines are a setting in the View menu called fancy wires which allows you to visualize content of the data streams. They indicate that the two different types you see in the image above have different structures, the solid double lines show multiple data on a single path and the dashed show data on multiple paths.

Permalink Reply by Jordan Barr on January 28, 2011 at 8:34am

Big time thanks Danny...got the graft concept now.

 

By chance, when you were looking at this definition did you see opportunities for simplification? I've just started using Grasshopper (coming over from the scripting world of things) and am trying to learn how to better streamline my definitions. I'd love to be able to apply a for-loop type of logic to this definition.

 

Thanks again,

Jordan

Permalink Reply by Danny Boyes on January 28, 2011 at 9:04am

I'll have another in depth look. with regards to the for-loop Grasshopper in its very essence is one big for loop. i.e. for every item (or set of items) going into a component GH will carry out the desired function until it gets to the end of the list. It all depends on your data structures and matching of data as to whether you get the desired results or not.

 

What exactly did you have in mind?

Permalink Reply by Danny Boyes on January 28, 2011 at 11:30am

Ok so I've had a look at your definition again. Firstly there is no need to duplicate chunks of components for every walking path. This goes back to what I mentioned above that GH is one big for loop. On the right click context menu of the curve param you can select multiple curves. With these curves on separate branches (graft) the same components can be used for two different scenarios. The only trick is to separate them at the other end if needed.

 

Now down to the nitty gritty. (I must add that there are many was to achieve the same results in GH it comes down to personal preference, which way the wind is blowing or simply not knowing any better. Which is why this forum is so great for learning GH)

 

You used divide curve to get the locations along the walking path. I would use the evaluate length component with a slider this allows you to specify where on each curve you want the "ball". Also in your version you created a sphere at the origin and then moved it to the point on the curve, this is unnecessary as you can supply the point on the curve as the base plane for creating the sphere.

There is a facility on the Sort component that allows you to synchronously sort any other list based on the values going into K. Which means you can order the surfaces directly based on there distance with out having to measure between closest points. Tip you can sort more than one item. With the input manager on the context menu you can add multiple inputs to sort.

Also above you will see the Sublist component used to get the first half of the list.

 

Next, because the criteria for comparing points was to find the matching pairs there ends up being ones that don't match because of the CP component acquires some intermediate points. i.e. when the mid point of a surface is closer to one point but not the other they are not coincident. Therefore I have used the centroid for every surface to compare for duplication.

This all adds up to the image below which I have created with one single gradient component that evaluates each "ball" separately but then adds the colours together to get the overlapping shades. But I have also separated the actual overlapped surfaces and coloured them separately.

File attached done in Version 0.8.0004:

 

EDIT: I forgot to add flip one of the curves in your 3DM file to get the same results as me.

 

Attachments:

• wallcolortwoelements_mk2.ghx, 479 KB

Permalink Reply by Jordan Barr on January 28, 2011 at 12:48pm

Hey Danny,

 

Where can I send the thank you fruit basket? I really appreciate all the help and even in giving your definition a basic look over, I'm getting a better sense of how tree structures work and how I can layer information into my components.

 

Essentially this whole definition has been working towards replicating a thermography graph (i.e. heat sensor) in a grasshopper definition. The arbitrary paths at the beginning of the definition simulate a walking pattern, the proximity (and the subsequent half of the wall subsurfaces) indicate which wall panels should react and finally, the radius of the sphere (which I've been working on since my response this morning, is indicative of the temperature of an entity at the point along the path and is represented on the wall surfaces by color.

 

The reason that I first started this thread was because I am trying to make the definition work for multiple heat sources (e.g. multiple people walking by this wall), which in turn creates a hierarchy among the subsurfaces of the wall. Essentially there are three groups:

 

Area 01: Subsurfaces that are not in proximity to any of the heat sources (the opposite of what you helped me with earlier)

Area 02: Subsurfaces that are in proximity to multiple heat sources (what you helped me on earlier)

Area 03: Subsurfaces that only are in proximity to a single heat source.

 

Area 01 will always be the darkest color on the gradient because it essentially is not reacting to the heat sources. Area 03 will have specific reactions to only one heat source. Area 02 will be an amplified area because multiple heat sources are being read. For me, the hard part to get my head around is that all subsurfaces of Area 02 are technically part of Area 03 and so their color should be a product  of whatever initial heat sources are interacting. If I were in a program such as photoshop/illustrator, I could change the opacity of each zone of interaction in order to see the overlap, but in this case I need to build this idea into the components.

 

There is unquestionable redundancy in the grasshopper file that I'm attaching, but it illustrates how I'm trying to have the wall surface measure and react to two independent entities (using the position and radius of the spheres). I have started re-working the definition according to a lot of the logic you used in your file, but I still am uncertain of how to have the overlap area also reflect an amplification because of multiple points. I've tried to make notes on the definition and call out areas where I am still questioning my logic.

 

Again, thanks for all the help Danny.

 

--Jordan

Attachments:

• Wall Color (Two Elements).ghx, 3 MB
• Wall color.3dm, 91 KB

Permalink Reply by Danny Boyes on January 29, 2011 at 5:24pm

Hi Jordan,

 

Here's something that you might be interested in, using cones to find "containment" surfaces and then aggregates the number of cones that contain them to add a gradient colour scheme. 

 

Attachments:

• wallColourMultiElement.ghx, 409 KB

Permalink Reply by Jordan Barr on January 30, 2011 at 4:55pm

Hey Danny (and all others that have been following this thread),

 

Updated definition and file are attached. I've been able to simplify a lot of the definition but am still trying to determine the best approach for blending two points when there is an area of overlap. I like the cone containment idea but the crux of the matter is preserving the intensities of the two individual points (represented now by the radius of the sphere) and showing the area of overlap as an amplification based upon the two initial intensity values.

 

Right now the completed definition works for both location of source and intensity of source, with a new part built in that allows the definition to work on any kind of surface. At the tail end of things, I'm try to think how the interpolate colors/blend colors might be able to be worked in to solve my area of overlap.

 

As always, thanks to the entire community for thoughts on both how to tackle this problem and further thoughts on simplification--it has been a great grasshopper learning experience thus far.

 

--Jordan

Attachments:

• Wall Color (Revised).ghx, 888 KB
• Wall color.3dm, 3.9 MB

Permalink Reply by Danny Boyes on January 31, 2011 at 5:42am

I think I miss understood your Area highlighting. I thought you were highlighting in particular surfaces with multiple heat sources but weren't interested by the actual amount.

 

I've had a re think with this in mind and produced a Mesh based version which I think is simpler to combine the gradient colours.

 

With regards to you definition I think you are over complicating the division of the surfaces. Is this to get around the polysurface produced by the bend in one of your curves? if so then you can control the loft settings to overcome this.

 

I know i was the one to point you in the direction of Tree Explode but since then I understand that this is not limited to Two Elements but could actually be applied to an unspecified crowd in which case you will have to manually alter your definition each time you add an element. With this latest version I have overcome this by flipping a tree structure manipulating it and then flipping it back to the original configuration.

 

NB: I've done this on my definition with the cones, not because I'm pushing the cone issue, but because it was easier for me to adapt to this new approach. I'm sure you can just as easily match it up to your own criteria.

 

 

Edit: I'm pleased to say that the size of file is getting smaller and smaller: 497 > 409 > 390 kb

Attachments:

• wallColourMultiElementMesh.ghx, 390 KB