it basically frizzes Rhino and keeps on running ))
So it is iterating quickly, just the movements at each step are small.
The size of the steps is affected by the ratio of the strengths of the goals.
In this file the strength of the OnMesh goal is extremely high relative to the gravity on the particles.
If you increase the value in the Z component things will move faster.
Kangaroo is multi-threaded, so should use multiple cores.
It shouldn’t be freezing Rhino, especially not on a simulation of this size.
Try disconnecting the recorder component (and turn on the visibility of the Solver so you can see the points) to see if it is the recording that is causing problems.
Thank you Daniel. It works. The delay of the on/off switch I would assume is a limitation of Grasshopper and my system ?
What would be a good solution to limit the simulation to a specific timeframe?
Here’s the speed I get on my desktop with 3k particles:
(this is on an i7 4790k, so decent but not crazy powerful)
Another option to control how the simulation runs is to use one of the other solver components such as the StepSolver, with a slider connected, then it only updates when the slider is moved… or the Zombie solver, which calculated many iterations and only outputs the end result (though if you want to trace the paths of the particles down the slopes this one is probably less useful).
Wow 
It is soooo slow on my Mac, I can’t orbit my viewport at all (((
I will try a step solver tomorrow
Unfortunately it is still very slow. I think it is Grasshopper/Mac problem ?!
It looks like Kangaroo works fine, but Rhino Viewport and Grasshopper space not active while simulation is running.
I am testing it on Mac Book pro 2017 2.9 GHz Intel Core i7
Thanks, I’ll look into this and do some more testing on the speed of the Mac version.
1 Like
Thank you Daniel
I will try same file on different Mac tomorrow as well …
Hi Daniel,
I tried the definition with different mesh and on a different iMac 2012, 3.4 GHz Intel Core i7.
Simulation works fine if I reduce the OnMesh strength parameter, but Rhino viewport and Grasshopper are not responsive while simulation is running.
I also have a technical question regarding the actual approach.
Is using Kangaroo a correct approach to see drainage paths on a site? It looks realistic, but some areas looks strange ?
WaterFlow.gh (1.0 MB)
For example it is how engineers drainage analysis looks like, it seems they are filter only major streams?
I experience the same problem. Even very simple simulation in kangaroo works very slow, e.g. Basic wind on mesh simulation takes 30.9 second with zombi solver.
Can you share the file, so I can confirm the problem here is specific to the Mac version, rather than something else in the setup
There you are.
It is very simple wind simulation. It works, but very slowly 26.6 sec.
Wind_test.gh (12.1 KB)
Here you have a system which does not converge (the flag keeps flapping in the wind, like in the real world), so it just keeps iterating until reaching the max iterations limit.
So this system is not suitable for the zombie solver.
Hi @DanielPiker,
Sorry to bother again, but have you been able to look at Mac simulation speeds?
I still have same problems, not able to rotate Rhino viewport.
Maybe it is a Rhino Mac problem ? @dan
Thank you
1 Like
give me an hour
Anyone who can help are welcome.
@DanielPiker @dan @diff-arch
Kangaroo for Mac always had a problem, wondering why nobody reported.
Thank you guys
I have a similar issue running Kangaroo Mac version. The same gh(kangaroo) file working fine in the parallel windows 10 on the same machine, but when I open it in Mac version grasshopper, it’s just slow and the viewport is almost freeze, and the fan goes on crazy. so I think the issue is probably not in the definition.
1 Like
Just stumbled over this topic and wanted to share that the UI “slowness” issue on Mac has been solved a few months after you posted the issue:
Also, it seems that Kangaroo is overall 2x faster on RH8 compared to RH7!
1 Like