Data Trees vs. Objects

I have struggled for days with a data structure problem that would be trivial using JavaScript objects or PHP associative arrays but has eluded me with data trees...

I have two lists of "beams", A in green & B in red. These surfaces are at the centerlines of thicker beams in the model (not shown).

I have a list of "Intersections", the yellow vertical lines, usually four at each point the beams intersect (85 points or 340 intersections expected, though there are only 335).

What I'm trying to do is "get" the list of yellow vertical lines for each beam and keep them "associated", so that I can re-orient them with the thick beams in a flat, "nested" layout.

These intersections will appear in two sets of lists, one for beams "A" and another for beams "B".

I found and hacked a bit of C# script to partition the sorted list of indexes but not the related list of intersections ("Line-like Curves").

In this case, the data trees aren't working for me. I want "beam objects" with arbitrary properties, such as lists of intersections. Are there ways to do this "easily" in GH without resorting to C#, VB or Python?

Attachments:

associate_2015Jun25a.gh, 88 KB

Replies to This Discussion

Permalink Reply by David Rutten on June 25, 2015 at 11:16am

I'm still trying to understand the file and the problem, but the answer to "Are there ways to do this "easily" in GH without resorting to C#, VB or Python?" is probably no. You cannot make custom data types in GH without writing code. It's possible to combine various geometric entities into a single group, but this is probably not advanced enough for what you want (it was designed to make it easier to transform collections of associated objects, there's nothing dynamic about it).

Permalink Reply by Joseph Oster on June 25, 2015 at 11:54am

If I could group each beam (centerline brep) with copies of the yellow lines closest to it, and then re-orient (transform) those groups, that's all I need.

I can see the "map" right in front of me, the information is there, I just don't know how to do it.

Thanks.

Permalink Reply by Chris Hanley on June 25, 2015 at 12:39pm

If you are trying to group intersections and beams, maybe something like this would be a way to go? (the vertical rectangles are just examples to visualize intersections per beam).

While it doesn't embed any data/attribute, (user text), into an object....the data structure dictates how many objects, (objects = intersections), per branch, (branch = beam).

Not sure if that is what you are looking for, but this is one way to group using data trees.

Attachments:

associate_2015Jun25a_CAH.gh, 94 KB

Permalink Reply by Joseph Oster on June 25, 2015 at 1:21pm

That's very cool, thank you. Some clever stuff I hadn't seen before, like the combo of 'TStat Paths (P)''. List Item and Tree Branch:

Your merge of the "beams" with the intersection blocks before 'Group' is perfect; it's what I've been trying to do with my lists of yellow lines. The group re-orients well:

Thanks again very much! It doesn't quite solve my data tree mysteries though... I've tried for two+ days to get a merged, partitioned list that will group beams and yellow lines - it's just not falling into place.

Permalink Reply by Chris Hanley on June 25, 2015 at 2:41pm

did you use GH to generate those intial intersection lines? the same type of logic could probably be applied a little earlier in the definition.

Permalink Reply by nikos tzar on June 25, 2015 at 4:04pm

Hello Josheph, David, Chris,

You can create the steps that you describe like this:

Use [Srf CP] with the surfaces grafted and test the Distance outputs to create a True/False pattern for each surface and use those to cull the list of lines.

Then merge each surface with the corresponding lines and (if you want) group them together:

this way each group (or branch if you don't group & flatten) has one surface (at index 0) and it's matching lines.

Attachments:

grouping.gh, 83 KB

Permalink Reply by Joseph Oster on June 25, 2015 at 6:03pm

Well, well. Thank you sir!

I knew it had to be possible but had to study your code many times to see how it works. Will have to study it again tomorrow. Bizarre in many ways. So very, very far from intuitive... Grafting the beams that way, before they are matched with another list - culling through ~12,000 combinations... Seems like a very strange road to take, manipulating data trees and lists in such arcane ways.

Not sure I want to replace decades of object-oriented data structures in my head with concepts that seem so very hard to grasp.

Thanks again very much though.

Attachments:

associate_2015Jun25b.gh, 81 KB

Permalink Reply by Chris Hanley on June 26, 2015 at 8:36am

Data trees are certainly something that takes some experience to get a handle on, but I do think that they are implemented quite well. In your case, I would be interested to see how the initial intersection lines were created. In the example you posted, (and perhaps I am misunderstanding the initial problem), there is no relationship between the beams and the intersection lines.

The goal seems to be to create that relationship. Whether it be through a coding language solution or a pure GH solution, the relationship needs to be established through some type of criteria. There are similarities between your project and others that fall into the "waffle" category. Perhaps researching some of those projects and looking at how they handled the data matching would help?

Permalink Reply by Joseph Oster on June 26, 2015 at 9:03am

Yeah, thanks Chris, didn't mean to ignore your earlier comment.

I did spend quite a bit of time examining the original intersection code, looking for a better way to preserve this relationship, and it might be worth reviewing...

The 2D "beams" in my code here are the surfaces that were extruded to create "thick beams" from which the yellow intersection lines were obtained.

Lists and trees do amazing things, for sure, but it can be a convoluted way to access things one can plainly see.

I'm still a long way from having interconnecting slots where the beams cross each other, with each slot effectively numbered, possible holes and brackets, etc. I'm used to re-factoring conventional code but with GH, data structures just don't seem to have the same "solidity" as JavaScript objects, for example.

RSS