Fast line length

Hey everyone,

Hope you can help me with this question. I am trying to calculate all neighbors in a point grid with the proximity 3D node. Now the output of this node are the links as lines and a topography. Besides that however, I would also like to know the length of each line.

Therefore one might consider to use the curve length on the links output. However, I am working with quite a big dataset (like 100.000 points) and the curve length function therefore takes too much time to calculate.

Now my question is: in the output panel of the link, the length of the lines is already calculated and presented. I was wondering if there is any way to get these lengths in a fast way.

For your information, I am familiar with Python but not so much with C# and VB. Already tried parallel computing the curve length, but that didn’t solve the issue.

Hope you can help me out :slight_smile:


Hey !

Curve length is also able to mesure curves.
But in you case, it looks like there are only lines.

What about a end point + distance component ? You might have to use (simplified) Shift Path after, to get beck your {0}, {1}, … data structure.
Another even fast way would maybe be by using the coordinates of the points.

Easier to test if you upload you internalized file ! (8.9 KB)

Hey, thanks for your fast response,

Hereby the GH file. I know that, at the moment, all distances are only 1 mm. But I will change that in the future. Voxelgrid (12.8 KB)

Hey thanks you. Sorry, didn’t increase the speed, this script has to change strings to floats which takes way more time than curve length

Then, why don’t you remove the lastNumber parameter and all of the redundant panels and get the string fr List Item?

Sorry, perhaps didn’t explain it well. I do need the values as numbers, not as strings, but converting them as you did by adding the num node, makes it way slower. So I would prefer to get them out of the links output directly as floats (perhaps by using a python script).

As @antoinemaesantoine mentioned above, the last one is faster IMO…

1 Like


Thank you both guys. I think that, indeed, that should be the fastest calculation.

Perhaps it was easier than I expected…