[Closed] Placing points along spline at even distance between them

@Serejah, I have the same problem with your code as Andres have – the cursor goes mad.

Andres, thank you. While I was at work i think that I can use this:
1- divide the spline to 100 “segments”, not 1 000 000
2- find the “segment” where the next point have to be paced
3- divide this segment to 1 000 poitns and find the right point

Your solution works better than my idea. But there is one problem – try it on my scene with fixedDist = 0.3 – the max freezes. My ugly code in my first post works with 0.3 only if I increase the accuracy to 1.0. The time is the same 4+ secs, the used memory is much, much, much more than your code uses.

EDIT: increasing the numSubSeg = 100 to 100 solved the problem.

I have tried the Shape Check utility – it works only when the circle is part of the same spline.

If 0.3 is very small with respect to the segments length, the behaviour you tell is quite logical.
Perhaps you can make a previous check, comparing the maximum segment length (you know it’s a cached value) with the fixedDist and then set subdivisions to the double of their relation.

I have added this to the code, and for now it works without any issues:

numSubSeg = (curveLength selection[1] / fixedDist) as integer

It not gives the best result, because sometimes the code above calcualtes that 300 subSegments have to be used while using only 100 segments is faster and more memory friendly.

But it makes it five times slower than the original Aaandres code
Try moving numSubSeg inside the for loop

...
slen = getSegLengths selection[1] 1
ptsCounter = 0
for i = 1 to numK0 - 1 do
(
	ptsCounter += 1

	numSubSeg = (slen[ numSeg + i ] / fixedDist) as integer
	invNumSubSeg = 1.0 / numSubSeg
	relStep = invNumSubSeg * invNumSeg
				
		
	coord = getKnotPoint curSpline 1 i
	segment = i - 1
...

It’s curious…
In your spline example, with fixedDist=0.3 and 100 subsegments, you get for each point a maximum of 12 iterations and you reach for all of them the 0.0001 accuracy.
With 300 subsegments, the maximum is 10 iterations, but there are 9 points that reach the 1000 iterations, thus their accuracy is lower.
These points, still with 10.000 iterations, give the same result. There must be a problem somewhere in the code, possibly when the point matchs the end of the segment. Have not time today to search for it, but shouldn’t be difficult to check if the value ‘b’ gives the right accuracy, so no need to do bisection.

EDIT: no, that’s not the problem. Must be something related with float precision when calculating distances.

Seems really strange to me.
Can you send me the spline, please?

I’ve just checked my suggestion on your spline and sometimes it is indeed doesn’t make almost any difference.
And seems that very few points actually reach target accuracy level even after 1000 iterations.

fixedDist 30
Total points 1224 valid: 2.78005% – added before 1000th iteration
Time: 8.206sec. Mem: 6623134L

fixedDist 100
Total points 367 valid:2.73224%
Time: 2.372sec. Mem: 7041406L

fixedDist 300
Total points 123 valid:4.09836%
Time: 0.743sec. Mem: 8915950L

fixedDist 666
Total points 55 valid:1.85185%
Time: 0.323sec. Mem: 7896406L

Here is the link for the new spline: https://drive.google.com/open?id=166UMWuDjtOIT90VSx0EmPB5tJRN8PLKG

Accuracy of 0,01 is enough for me.

OK, I see…
The problem is the float mantissa. Your spline is too long!
Type in the listener for example 127356.5632: you’ll get 127357.0
You should scale your model to get fine results. As it is, you just can get accuracy to the unit (1 ).
There’s nothing other to do, either working with double values as Point3 has float values.
Edit:
Float numbers: -1S × M × 2E

You have 23 bits for the mantissa (significant numbers): 2^23=8388608

Thank you.
So the script will check the length of the spline and if it is too long(too many numbers before the decimal point) it will use smaller value of accuracy.
But even with this long spline the script works when the numSubSeg is calculated and not predefined.