Grasshopper

algorithmic modeling for Rhino

Re-order branches in two trees simultaneously (by sorting one, the other would follow)

Hi everyone,

I'm usually okay in finding my own workarounds but I get migraines when it comes to data trees/lists.

So here is my situation:

I am doing a sun path study (shadow projections) using Heliotrope on GH. The settings are fine and I am getting the projections I want, but they all come out the same color. Therefore, my idea is to use a color gradient to identify each "time of the day" through calculating the combined area of the projections. I got there fine, but I am now trying to re-order the branches of the "non-combined" area, and the list sorting doesn't allow me to do so since the branches on both trees, even if they have the same path, don't have the same number of items.

Here is a snap of the definition I got so far.

Views: 749

Replies to This Discussion

Forgot this one, its the full thing without warnings covering components.

'Sort' can "carry" and re-order multiple trees based on the values in one of them - but they all must have the same number of items:

As to the gradient, you can get the lower ('L0') and upper ('L1') limits without sorting:

Attachments:

What if they dont have the same list lengths but the same number of branches?

Lists that don't have the same length don't have a one-to-one relationship so there is no logical way to re-order secondary lists based on sorting one of them.  It's not a Grasshopper flaw, it just doesn't make sense.

The deeper questions are 1) why are they mismatched and 2) what makes you think it should work?  It's impossible to get far with GH until data trees make some sense.

Since I am doing a solar (or more precisely, shadows) study on multiple buildings, over a 24 instance time-frame (projecting the shadows of the group of buildings at 24 different times during the daylight period) I thought of mass-adding the area of each of the 24 times of day and color them based on their combined area. The problem that arose was that once the area is mass-added, the data in the tree becomes numbers and not breps, and therefore I cannot color the shadows (projected breps on the ground and surrounding buildings). I wished GH could handle branches alone, reordering the branch paths regardless of the number of elements in the lists of each branch. Basically using sort and reproducing the pattern of the mass-added areas' sorting and carry it to the "unmerged" tree. 

To put it step by step, I wished the "sort" function's input K could be the mass-added area tree so it could sort each of the 24 times based on the global area of the shadows casted, and the input A would be hooked to the tree before it was mass-added (as it would be including all the breps of the projected shadows). So it could carry the reordering from the K input over to the A input, since both trees have the same number of branches, so the same paths, regardless of the number of elements within the branches. 

Is that clear enough? I feel like its all very blurry but if you need any more explaining, by all means just ask for it :).

Not interested in further explanations, I get the general idea.  It's not an uncommon problem but the answer is VERY SPECIFIC to the data.  Without access to that (as a GH file), I have nothing further to offer.

Very well, thank you for the help. If I end up needing more I will upload a dummy file. Thanks again!

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service