Continuing the discussion from Grasshopper 2:
@Thomas_Helzle do you have a small sample of the definition that you can make public, where I can test and see where the add-on slows down? Also, if you could make a small scheme of which parameters besides Euclidean distance would help you, then I can consider what to add!
Hey piac,
Iâm a bit busy ATM but Iâll try to create something for you that shows what I think would be interesting to make the plugin more versatile. Basically itâs about âdirectabilityâ - having ways to tell the paths that they should follow a certain path or direction as long as possible.
This is an example from Houdinis âshortest pathâ with custom path costs:
You can see how the paths try to stay in the centre and only turn towards their individual endpoint when they âhave toâ.
Most natural forms are like that and it generates a much more interesting variety of patterns.
So I could imagine defining a spline curve as a âgoalâ or âattractorâ that the shortest path tries to follow. Attractor behaviour would be good, so the paths donât follow the guide too absolutely(or at least not if I donât want them to).
Like you pointed out in the other thread, Iâm not even sure if Shortest Walk is the performance hog or if GH simply has a hard time with lots of points no matter what tools you use. I worked with very detailed grids and the system became extremely slow.
Does the plugin use multithreading internally? In theory it should be possible to search each path in itâs own thread?
Cheeers and thanks again for your feedback!
Tom
The real longer and more difficult part is not multi-threading the finding of a path, but rather constructing the graph from the bunch of lines only once, and in a fast way. Pathfinding should not be very difficult after that. Several different pathfinders can run at the same time.
Another question eventually for later. Should path length always be positive? Or could there be âsinksâ/shortcuts that have negative or 0 lengths?
I see.
Well, lengths as such should be positive and ârealâ (the output value I mean), but with path cost I could imagine allowing all kinds of values - this is a different thing in Houdini and can be output per path as well as per point.
They also offer turning cost (which I found quite interesting) and a mode where the actual path length doesnât come into it at allâŚ
Here are the three interface tabs:
The first canât be reproduced in GH - every point or line can have resulting values assigned to attributes that you can use later in the graph (so you donât fiddle with lists and order but instead each entity can hold itâs own information).
The second deals with different costs, for points, primitives (~lines in GH), then turning and angular costs (can be per point as well). etc.
The third tab allows to restrict the path to certain objects, uni-directional primitives and edges to avoid. This is done by entering group names one assigned beforehand.
While this is very flexible, I could imagine a more artist-friendly way, where one deals not with such abstract values but like I said with for instance a spline curve which the paths try to stay close to (with a custom falloff) or something like that. I donât know the algorithm well enough to offer good suggestions how it could be done.
Cheers and thanks for looking into it!
Tom