Hi Guys,
I am new in Kangaroo, and still trying to get a feel for all the settings.
I saw this nice animation of way finding done in Kangaroo and decided to replicate.
I think I got the logic and system working, but still something wrong with it.
PathFinnding_Kangaroo_01.gh (199.0 KB)
How can I improve it?
Tried a couple of things, but still can’t figure out what is wrong. I am trying to get something like on attached image.
I found a solution from @DanielPiker but it was done in Kangaroo 1 and I can open it on Mac to get the logic behind.
I am trying to make same test but with Galapagos, bout for now Kangaroo looks more promising. I wonder if there is a way to hook Galapagos to Kangaroo to update strength values ?
Hi @arten,
Try this:
pathslope.gh (188.3 KB)
Once you have your curve, you can take perpendicular lines, project them to a horizontal plane and sweep, then use booleans to find where the land needs to be cut away or built up to keep a non tilting road
Thank you @DanielPiker.
It looks much cleaner and closer to what I was trying to achieve. In some cases (as you said) it will not pull to the mesh , but I can control the pull strength.
Still can’t get a fill for strength parameter and how it effects others.
You meant something like this ?
PathFinnding_Kangaroo_02.gh (217.3 KB)
I think it helps to think about the geometric aims here and when they conflict.
If the target length is low, this keeps the curve closer to a straight line. Clearly a straight line cannot lie between the 2 fixed end points on the curving surface - just because a destination is 100m away at 10m greater elevation doesn’t mean a route exists that can drive you there at a constant 1:10 slope.
Because the 2 aims are conflicting, their relative strengths will control which one is violated more.
If you increase the pull strength enough to force it to lie on the surface it will have to violate the length goal, meaning it no longer has constant slope.
If the target length is long enough though, there are multiple ways the curve can stay on the surface and keep constant slope. Both goals can be exactly satisfied.
However, starting with the target length high could cause the curve to rapidly crumple and overlap. It seems to work better to gradually increase it until it can lie fully on the surface, and with the desired slope.
If the constant slope goals are strongly enforced throughout, the path shouldn’t be able to cross itself, since it never goes back downhill, so I don’t think additional Collider goals should be necessary.
The bending goal also conflicts with the constant slope aim, since to turn smoothly at the hairpin bends means at one point the path is pointing directly uphill. The wider radius turns you have, the more earth you will need to move to build a non tilting path.
Here’s the file including the sweep of the road surface. I used a data dam, because you don’t want this to have to calculate for every update while still finding the path.
pathslope3.gh (196.9 KB)
To answer the questions in your notes on the gh file - the ‘rod’ goal is the same as creating length and angle goals, just sometimes more convenient to use.
The fixing of Z values for points on the curve is what enforces constant slope, since if each segment is the same length, and its end points are the same distance apart in Z, they must have the same slope.
I think it should be possible to get to a desired slope range just by adjusting the relative strengths of the goals in the existing setup.
If you did really want to control the limits of the slope range directly though, ClampAngle could work, or perhaps more simply, just use the same setup as above, but with a ClampLength goal for each of the segments. Since the height difference of the end points is enforced, you can easily convert between slope and length.
Daniel, this is awesome!
This tool you made is just mesmerizing!
I’ve played a bit with Grab … dragging around the road is the best!
An idea:
instead of trying to implement many forces/rules, which can make everything really complex and slow, add some gradient or else to check the result, like the curvature, or distance to ground, etc.
This way you can just grab and adjust in real-time the road position, possibly avoiding places that would be too much a hassle to implement with forces…
Hi @DanielPiker
Thank you for great explanation. It all make sense.
I think I having the problem with below :
I usually start the simulation, then adjust sliders to get the result I like , but when I reset the simulation it gives me something completely different? Is it the correct behaviour?
This is a good idea, will try.
Kangaroo is amazing I was trying to build something like for ages as I do a lot of developments in steep areas.
Will try to do it with multiple paths now 
Ok finished my version as well. Without “Grab” it doesn’t work.
Will try to build on this system to project a grid of roads or defining multiple points.
Looks good.
I’ll try and get to the bottom of the slow performance and problem with Grab on the Mac.
Yes, this is the expected behaviour. When you adjust sliders over time, these adjustments and their order are not stored by Grasshopper, only their current value.
For many types of optimisation this doesn’t affect the end result - if you have a catenary mesh and you increase the load and then the stiffness, or the other way around, or apply the full value of both at once, Kangaroo will still converge to the same solution.
However, with something like this pathfinding question, there are many nearby local energy minima, so which one it converges to will be affected by the way the strengths are varied over time.
I would like to do something to enable repeatability of this sort of timing-dependent optimisation.
I was sharing some thoughts about this recently here: Triggering a button - #8 by DanielPiker
With the new graph mapper functionality @DavidRutten is adding for GH2 it looks like making this sort of timeline control might get a lot easier.
i am digging to find a presentable version of the script seen in the video (kangaroo1 version).
if i have correct notes it was based on the logic of a definition Daniel had shared in a similar question in the old forum, as a kanagaroo alternative to galapagos and/or graph type solutions.
it “suffers” from user instructions as seen in the updated video but still quite usable.
It is so cool it even works with multiple curves. The wee problem I have are small intersections…
But it is where drag component would help I supposed. Collide doesn’t seem to do anything:)
Will do another test on a real mountain. And will try to solve junction 
PathFinnding_Kangaroo_Routes_01.gh (197.2 KB)
ok here it is. i had to redo some parts because the original looks like this
what i never got a chance to resolve is:
sliders need gradual increase and to have the final output curves you need to wait for the pull to curve to converge.
paths forum.gh (1.2 MB)
Very nice @ng5_Alex. On a first sight looks very similar to Daniel approach, the only thing he advised to add Z anchored as well so the slope tries to be the same on all segments of the curve.
Have you tried making an intersections? For example two roads are crossing each other ?
the version i shared anchors z through curve pull, not aiming after segment slope equality, but as an alternative to pull to surface goal. i also found useful to associate the path resolution, as in polyline segment parts, with the contours of the terrain itself.
the definition comes back from 2014-15, where kangaroo wasn’t the beast kangaroo2 is, though K1 was/is more than awesome at the time. Intersections between two paths can happen, but if you are targeting to happen, i can see goals of kangaroo2, like transform and magnet snap towards this direction.
btw is this for a student or pro project?
Neither student nor pro. Working on my own research. I work for a practice where predominantly everyone uses SketchUp/Archicad, this manual modelling atmosphere gives a lot of ideas regarding workflow optimisation.
But I do design and urban planning in hilly areas where Kangaroo might help. not sure if it is going to be used professionally unfortunately.
