generative modeling for Rhino
I made a python script that estimates the direction of drainage paths on a surface.
It does not deal with puddling or accumulation, and if you have any suggestions on how to make it faster or to improve it in any way, let me know -- this is a first draft.
you can see the python code in this github gist:
I'm probably too late but i just read the last replies.
The VB code to make this work with a mesh object would be something like this:
Private Sub RunScript(ByVal pto As Point3d, ByVal m As Mesh, ByVal tol As Double, ByVal maxsteps As Integer, ByRef A As Object)
Dim ptl As New list(Of point3d)
Dim pl As New plane(pto, vector3d.ZAxis)
While ptl.count < maxsteps
Dim mpt As meshpoint = m.ClosestMeshPoint(pl.origin, Double.MaxValue)
pl = New plane(mpt.Point, m.NormalAt(mpt))
If ptl.count > 0 AndAlso pl.OriginZ > ptl(ptl.count - 1).z Then Exit While
Dim an As Double = vector3d.VectorAngle(pl.XAxis, -vector3d.ZAxis, pl)
pl.Translate(pl.XAxis * tol)
a = ptl
Note that since mesh welding affects the mesh normals it will also affect the drainage direction.
Genius! Very handy, thanks much!
is anyone able to elaborate on the method to achieve this with a mesh. I am a novice when it comes to writing code directly and cant seem to work out how Vicente's code is applied to achieve the results seen at the end of the thread. I have tried copying them into a VB script component but must be missing something. Is anyone able to post a definition that makes Benjamin's original drainage script work for a mesh terrain?
I've created a GH + Kangaroo solution that works in a much looser method, but it can work with mesh geometry. See the example files here.
i figured it out with kangaroo already... but was after the scripted component because kangaroo runs very heavily and i want to run it across >50sq km of terrain with a grid spacing of 25m or less so a lot of calculations if done in kangaroo and very slow and clunky.
I think tracing around 80,000 points on a complex terrain mesh over many iterations is going to be quite slow whatever method you use.
However, using PullToMesh instead of CollideMesh will be considerably quicker than the method above, because it doesn't have to check for containment (also meshes are generally much quicker than surfaces).
Here's a definition using that, with around 40,000 points. It takes maybe 100 seconds to initialize the simulation, but then runs around 2 iterations per second.
I know in the past Kangaroo has slowed down with very large numbers of points, but I have been working on it. The latest version should be noticeably quicker than before, but of course there's still plenty of room for improvement...
many thanks. I didnt realise that the pull to mesh component had the same/similar functionality and overlooked it first time round.
I did get some great results from kangaroo so thanks. I had been speaking with my tutors (DS10 at westminster) who had suggested the scripted approach may provide a way to achieve denser results, but i did manage to get the following from kangaroo after my initial forum response on this thread. I will have a go with the pull to mesh approach and really appreciate kangaroos functionality! Thanks for your input! :)