I am trying to do something very similar to this,[https://generativelandscapes.wordpress.com/2016/05/31/water-runoff-script-example-8-6/]
but on a network of curves rather than a surface.
Basically I am testing out different patterns on where the water would go but instead of just letting it go anywhere i am forcing it to stay on the curves I defined.
I have been trying to adapt the script a bit but whenever I run it for more than 1 iteration my grasshopper and rhino crashes.
It seems quite straigthforward, so I am not really sure what I’m doing wrong here? It works well with the original script from the website on a topographical surface.
Can anyone help me with that?
flow tests.gh (51.5 KB)
You didn’t internalize your points?
oh sorry! didn’t realize. here’s the file again.
flow tests.gh (55.3 KB)
When I closed your previous file, Rhino/Grasshopper froze and then crashed. Not good!
Looking at your updated file, I see HUGE numbers of points and data tree paths (many empty) in the outputs, so it’s very likely that there are data tree mixups involved. Looking…
Later: How does this look? I flattened the output of MCX, then sorted those points by Z to choose the lowest point as the next way forward. Finally, added the red group to end the loop when a duplicate point is encountered, a “dead end detector”.
Using a different starting point (yellow), a different dead end is encountered after 53 iterations.
Note that in general, flattening is “bad”. It will prevent handling multiple starting points at the same time, for example, though I’m not sure if the loop would handle that anyway? Will try Shift Paths instead of flatten? Uh, nope. So for only one starting point at a time, flatten is fine.
thank you! this is exactly what i wanted
Caveat: As written, the radius of the sphere determines the incremental distance. If the radius is too large, there is a danger that it could intersect an adjacent path instead of a connected one, causing an unwanted jump between routes.