I have added this to the code, and for now it works without any issues:
numSubSeg = (curveLength selection[1] / fixedDist) as integerIt 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.
Yes, in this particular situation it makes it slower. But I have tested it with a spline with length 553 295 units. FixedDist = 300, numSubSeg= 100 - Max freezes. When the numSubSeg is calcualted using the numSubSeg = (curveLength selection[1] / fixedDist) as integer the values are:
fixedDist = 300, numSubSeg= 1844 and the results are:
Time: 34566ms; Mem: 3164832L
I will do more tests later this day.
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: 6623134LfixedDist 100
Total points 367 valid:2.73224%
Time: 2.372sec. Mem: 7041406LfixedDist 300
Total points 123 valid:4.09836%
Time: 0.743sec. Mem: 8915950LfixedDist 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
| Bit No | Size | Field Name |
|---|---|---|
| 31 | 1 bit | Sign (S) |
| 23-30 | 8 bits | Exponent (E) |
| 0-22 | 23 bits | Mantissa (M) |
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.
No, taking 34sec is not to work. It shouldn’t take more than 0,1sec (in a slow computer for a spline like this one). I wouldn’t trust in the results you get. Scaling it gives the result in 60ms.
But there’s still a problem in some isolated verts that I can’t solve. I think it’s a ‘bug’ of interpBezier3D or interpCurve3D, but I’m not sure.
let’s bring the test to a unified form of solution…
it has to be a function with at least two parameters - the spline and the fixed distance between points on the spline.
The function has to return all found points in the world space. The function can have any extra optional arguments to make calculation more accurate.
fn scatterPointsOnSpline sp dist tolerance:0.001 =
(
-- ...
points
)here is my solution:
fn scatterPointsOnSpline sp dist tolerance:0.001 =
(
len = curveLength sp
t = 0.0
d = 0.0
current = interpCurve3D sp 1 t pathParam:off
points = #(current)
while t < 1.0 do
(
t += (dist - d)/len
t = amin t 1.0
p = interpCurve3D sp 1 t pathParam:off
d = distance current p
if d >= dist - tolerance do
(
current = p
append points current
d = 0.0
)
)
points
)
/***************** TEST *****************/
(
delete helpers
t0 = timestamp()
h0 = heapfree
points = scatterPointsOnSpline $ 33.0 tolerance:0.001
format "time:% heap:%" (timestamp() - t0) (h0 - heapfree)
dd = for k=1 to points.count collect
(
point pos:points[k] wirecolor:orange
if k > 1 then distance points[k-1] points[k] else dontcollect
)
format " >> %\n" #(dd.count, amin dd, amax dd)
)PS. spline index set to 1 (of course we can pass the index to the function)
The “one step closer” solution!
Really clever. Fast and few memory. As always, you win.
I just see two problems… well, two and a half.
Yes, that’s the solution to avoid freezing
fn scatterPointsOnSpline sp dist tolerance:0.001 =
(
tolerance = tolerance as double
len = (curveLength sp) as double
t = 0.0 as double
d = 0.0 as double
current = interpCurve3D sp 1 t pathParam:off
points = #(current)
while t < 1.0 do
(
t += (dist - d)/len
t = amin t 1.0
p = interpCurve3D sp 1 t pathParam:off
d = (distance current p) as double
if d >= dist - tolerance do
(
current = p
append points current
d = 0.0
)
)
points
)
/***************** TEST *****************/
(
delete helpers
t0 = timestamp()
h0 = heapfree
points = scatterPointsOnSpline $ 33 tolerance:0.000001
format "time:% heap:%" (timestamp() - t0) (h0 - heapfree)
dd = for k=1 to points.count collect
(
point pos:points[k] wirecolor:orange
if k > 1 then distance points[k-1] points[k] else dontcollect
)
format " >> %\n" #(dd.count, amin dd, amax dd)
)
Here’s a mixing of the DenisT’s “one step closer” and my bisection way.
Seems not to freeze and supports scaled splines:
fn scatterPointsOnSpline sp dist tolerance:0.001 =
(
tolerance = tolerance as double
len = (curveLength sp) as double
sc = sp.scale[1]
x = len / (numSegments sp 1) / dist * 10 / sc;
step0 = (1.0/ (numSegments sp 1) / x) as double
t = 0.0 as double
d = 0.0 as double
current = interpCurve3D sp 1 t pathParam:on
points = #(current)
step = step0 as double
counter = 0
while t < 1.0 do
(
counter += 1
t += step
t = amin t 1.0
p = interpCurve3D sp 1 t pathParam:on
d = (distance current p) as double
error = (dist - d) as double
if abs error <= tolerance then
(
current = p
append points current
step = step0
counter = 0
)
else
(
if error < 0 do
(
t -= step
step *= 0.5 as double
)
if counter > 1000 do
(
current = p
append points current
step = step0
counter = 0
)
)
)
points
)
/***************** TEST *****************/
(
delete helpers
t0 = timestamp()
h0 = heapfree
points = scatterPointsOnSpline $ 33 tolerance:0.000001
format "time:% heap:%" (timestamp() - t0) (h0 - heapfree)
dd = for k=1 to points.count collect
(
point pos:points[k] wirecolor:orange
if k > 1 then distance points[k-1] points[k] else dontcollect
)
format " >> %\n" #(dd.count, amin dd, amax dd)
)
if scale is uniform it’s probably enough to make it work as expected
local isUniformScale = sp.scale[1] == sp.scale[2] and sp.scale[2] == sp.scale[3]
local factor = if isUniformScale then abs sp.scale[1] else 1
local len = curveLength sp * factorand the test
for i=1 to 4 do
(
c = circle radius:20
convertToSplineShape c
c.scale = [0.5 * i, 0.5 * i, 0.5 * i]
gc();t1=timestamp();hf = heapfree
pts = scatterPointsOnSpline c 3.0
for p in pts do point pos:p centermarker:on cross:off wirecolor:yellow
format "count %\n" pts.count
format "Time: %sec. Mem: %\n\n" ((timestamp()-t1)/1000 as float) (hf-heapfree)
)I can’t test it until tomorrow, but have you tried scaling Kostadin’s spline? Functions based on length doesn’t work fine generally when there’s a scale (check result distances).
If I remember well (I’m not in my desktop), take the second example spline and run the script with dist=300 & tolerance=0.01 (or lesser). Or the first example spline with dist=33 & tolerance=0.000001. Other combinations too.
With double precision it seems to work.