Hi All,
(or rather @piac , I think this is for you )
I have been playing with the Shortest walk component recently and I have noticed a strong performance hit when using custom lenghts.
Please see the screenshots below.
Without custom path lengths the difference between searching one path and searching 100 is negligible.
with custom lengths the difference in time between searching one or hundred paths is
much bigger (although not quite linear).
This leads to calculation times of several hours when applied to 10k points with custom lengths, while the other methods breezes through it in a matter of few minutes…
I’ve never used the length options though,
just never came across a situation in which it is needed.
But if you insist on it, I guess I have a temporary solution for it, correct me if I’m wrong.
Firstly my understanding of length is that it gives a curve a defined length that overwrites the actual length.
Then if you have a list of defined length for a list of curve networks,
all you need to do is to modify the curve to achieve the defined length,
while retaining the start and the end point of each curve.
Many ways to do it, depends on specific project.
Fo example, for 2D curve networks,
each segmented curve can be boosted towards direction Z Axis to get extra length.
For 3D senario which is your case, it will be slightly more complicated but not too bad.
Guess you can use curve nromal as direciton for boosting the curve,
basically the principle is not to touch anything else.
Note:
If your defined value is smaller than the actual length, obviously you can’t shorten it,
but you can scale up the defined value by 10, 20, etc…then have them remapped.
The reason I divided each original segmented curve into 10 sections is that, for some really curvy curves, having line from start to end may misrepresent them and ended up clashing with others. You can obviously increase that number to whatever you want.
Thanks for the suggestion Zach.
I thought as well about this workaround.
My issue is that I need to run this algorithm on ten of thousands of points and with this I am going to double up (at least) the size of the network by adding extra segments.
Also, the extra points will make more complicated a subsequent step of re-mappping statistics extracted from the path network ont the underlying mesh.
I will test he performance hit I get and I will let you know.
Best,
I’d also like to mention that the project is open-sourced here:
If you feel like, you can check if you see something obvious that would slow down the second option!
If not, I’ll still look into this, but it might take a little while (sorry I have another project that is taking priority).
Well it is true that it doubles/triples/*100 the amount of points,
but it shouldn’t be too hard for GH to deal with it since they are basic points and lines.
If worried, you can simply start a new file just for converting network curves into my ver. of zig zag lines.
Then once you join them together, in my case 10 zig zag for as ONE SINGLE CURVE,
run them through shortest walk, it shouldn’t take longer from my guess,
since each zig zag is treated as one curve.
Then in terms of remapping, not sure about your specific senario, but as you can see,
they can be easily mapped back to the original curve network using INDEX produced out of shortest walk.
Thanks for pointing that out,
unfortunately I’m not capable enough for jumping into coding space.
Just wanna raise a issue,
sometimes the Shortest walk component will show fewer items in length output than the curve outputs.
That also means the index number of used curves are missing the ones accordingly.
)
