What am I doing wrong with data structure this time?

Replies to This Discussion

Permalink Reply by Andrew Heumann on May 1, 2016 at 8:18am

See the attached - I've made some modifications and added some annotations to help you.

In general I think the missing "piece" from your understanding of Data Trees is the idea of "Shift Paths" - this is like flattening your data PARTIALLY - chopping an index off the end of the branch paths without obliterating the tree entirely. When working with one "set" of input data, a flatten works to get these lists to match up - but when working with multiple sets, we need to be careful to preserve the original branch indices that keep all four of your original regions separate. As a rule, whenever you're feeding two data trees into any component, they should have the same number of branches. (or one should have branches and the other should be a flat list, in other cases). 

The rule of thumb I tend to teach is this:

In 90% of cases...

For lists, all your inputs should either have 1 item or N items. That is to say, if you're feeding 4 items into one input and 9 items into another, something is probably wrong.

For trees, all your inputs should have either 1 branch or M branches. That is to say, if you're feeding a tree w/ branches {0;0} to {0;3} into one input, and a tree w branches {0;0;0} to {0;3;8} into the other input, something is probably wrong.

Grasshopper essentially matches up branches first, then lists second. By "matching" I mean it processes them together. Simple example of the Line component - it will match the first branch of points in the A input to the first branch of points in the B input, creating lines between those points, then match the second branches, the third branches, etc. THEN, it applies the same logic to the level of the list (with a pair of matched branches {0;2}, match all the items in those branches to each other - first item in one branch to the first item in the other branch, etc.)

This is a tricky concept but it seems like you're already well on your way to understanding it from your definition - "PShift" is a critical tool in your path management arsenal. I hope this (overly long) response helps clear things up for you! 

Attachments:

• Path_match_problem.gh, 45 KB

Permalink Reply by Jonas Blazinskas on May 1, 2016 at 11:55am

Thank you so much! Such a great way to explain a problem, I am looking forward to the days when I will be able to achieve yoda status on grasshopper!

Permalink Reply by Jonas Blazinskas on May 3, 2016 at 6:13am

So now I am facing a reverse problem, Ladybug daylighthouranalysis, I need to run it for multiple planes without them self obstructing each other. So I found that by grafting them you bypass that. But weirdly now I can't get the output sunlighthourResult to be in branches no matter what I do. I have been trying everything for hours now I am just confused. 

Attachments:

• obstruction and branch struction WHAT THE FUUUUUNKTION.gh, 404 KB

Permalink Reply by Jonas Blazinskas on May 3, 2016 at 8:13am

Right so I got by this with unflattening tree component, everything was flowing like water up until to the point I hit the quadtree component, all I want for Christmas is to know how to unshift a path :D that doesn't happen right? What do I do here how do I get a little 0 in front of every line? uhhh and yeah when you open a file just cancel the weather file opening because it will lag u the hell out. 

Attachments:

• roof grid volume all good2.gh, 1.4 MB

Permalink Reply by David Rutten on May 1, 2016 at 8:48am

You need to stop flattening trees, that never scales well to more complex situations. That said, this was ridiculously difficult to solve. There's a relatively simple approach using Surface Split but it's super slow.

The main problem I had was to close the open cells along the boundaries using a segment of the boundary.

The issues were that sometimes the boundary seam would be inside the wanted segment (a), which means trimming/subcurve extraction doesn't work, and that it wasn't at all clear how to get the (a) segment rather than the (b) segment.

In the end I cheated and wrote a small C# script which, given the boundary curve and the open cell, finds segment a and joins it to the cell curve.

This should clearly be a lot easier than it actually is.

Attachments:

• SlowButEasy.gh, 24 KB
• CheatingButFast.gh, 34 KB

Permalink Reply by Jonas Blazinskas on May 1, 2016 at 11:39am

Yes I figured out the surface split one myself, but problem is that it created curves where was none before ill check yours maybe its a bit more complex and yes its super slow, especially when its not only 4 faces that I am going to work on in the end its going to be more like 30+ and I am adjusting the grid size so every calculation would take 4h+.

I can not open both of your files, crashes rhino stating the out of memory message.

Permalink Reply by David Rutten on May 2, 2016 at 4:30am

Wow... can you open the files if you lock the solver first?

Permalink Reply by Jonas Blazinskas on May 2, 2016 at 6:19pm

Nope still straight up crashes it

Permalink Reply by David Rutten on May 3, 2016 at 4:40am

Welp, that is really weird. Unfortunately I'm about to go on holiday for two weeks so I doubt I'll be able to figure anything out until afterwards. Unless this becomes a more common problem perhaps we should just ignore it and hope that the same bug doesn't end up in GH2...

Permalink Reply by Jonas Blazinskas on May 3, 2016 at 6:06am

I don't mind it I have the solution, lets hope its just my computer that has not been restarted for months. Have a nice holiday!!!