I’ve developed a Grasshopper definition that creates a series of ramps and landings between several points across a landscape and within a defined gradient [based heavily on a definition from the Generative Landscapes website].
I’m got three data branches running through the loop simultaneously. The issue I’m having is that branch {0} and {1} finish and exit the loop before branch {2} has time to complete its task.
In the screenshot below:
Branch {0} runs from Point 1 to Point 2
Branch {1} runs from Point 2 to Point 3
Branch {2} runs from Point 3 to Point 4
If I change the loop exit rule to only be true when branch {2} is complete, then branches {0} and {1} draw overlapping ramps back and fourth a few times.
Is there a way to have multiple branches running through the same loop and exit when each one is complete? Or should I just copy the whole Grasshopper definition down two more times and have one branch running through each loop?
Got a solution for you! I’ll admit it’s not the most elegant, but it’s a reasonably functional workaround (for now, I guess - you might need to rework the specifics if things change).
The issue comes down to this - the loop is always going to run a constant number of times for each branch, but you have a variable number of items you want to extract from each branch (a “jagged” array) - so we need to trick Anemone into “running” the loop falsely for branches that have already finished, while there are still other branches that haven’t. There’s a couple ways to do this, I find the simplest to be simply using cull pattern to let it run the computation and then “filter” out the unwanted result if the branch had already reached a finished state.
To this end I made two changes to your file - first, adapted the exit condition to only tell the loop to exit when everything’s complete, rather than a majority, and second, placed in the filter (using the same data from the exit condition to determine if the branch is finished or not). This should ideally take care of any unwanted doubling back.
One thing I don’t understand is that each data branch is missing the last ramp. For example, branch {2} finishes with a ramp that’s 15.14m, when it should be 8.99m. See screenshot below:
The rule for the exit condition is that it’s only true if the final point is less than the 1:14 ramp length defined by the Australian Standard [in this case 9 meters], so I’m not sure why it’s exiting the loop one step early?
Thanks for the time you spent on this and if you have any suggestions regarding the final ramp length issue it would be very much appreciated.
Whoops - logical error! My bad. Turns out that when the “filter” condition is reached it needs to run one more loop to put in the last “correct” result at the end. My shot at this for the moment is to put the filter results in a container and pass them to the next iteration of the loop, and then use them there (starting with three “true” values), and replace them in subsequent iterations with the new calculated values) delaying filtering by one loop - which in this case is what we need.
Is the doubling back at the end of the track of Branch {1} OK? Looks like that’s the “correct” result from this strategy, but that it might be avoided by using some other pathfinding strategy beyond just the local terrain gradient? I’m not sure. Anyway, here’s a definition that should make Anemone work for you.
