[Closed] lengthinterp : huge precision issue
I have a curve made of 4 knots, on the same sub spline, which length is ~11km (it’s a railroad track path).
I want to know the coordinates of the point on the curve, when the parameter changed by 1 meter, to create a kilometer table (well, more a “meter” table).
So i use lengthinterp() to get this. the parameter of the function is incremented to represent one meter :
-- Length of curve in meters (Max units are 1 unit = 1 cm)
_curveLength = ((curveLength p 1) /100.) as double
-- The normalized delta value. one delta represents a progression of one meter along the curve.
delta = (1./_curveLength) as double
for x = 0. to 1. by delta do point pos:(lengthInterp p x steps:100000) wirecolor:green name:"temp"
Now the problem is : If I use the optional parameter “steps” of lengthInterp(), and I set it to 100000, the returned values will be roughly progress by one meter (0.99< value < 1.01m, generally), BUT the last point will be more than 9 meters from the end of the spline !
If I don’t use the “steps” parameter, the returned values will go crazy, progressing from 0.4 to 1.3m roughly !
I suspect a floating point precision problem, but is there a solution to this ?
Yes. Don’t work in centimeter units in a 11-km wide scene, work in meters.
It doesn’t change anything. I switched to 1 unit = 1m, with and without scaling it down by 0.01, I still have the problem where the last point (parameter t = 1.0) is 10 units before the last control point. :hmm:
this is the same issue as http://forums.cgsociety.org/showthread.php?f=98&t=1062572
they are using fast but not accurate algorithm for path-to-length mapping. it could make sense 15 years ago but now with new computers it’s kinda silly.
try to use interpCurve3D which is much more accurate.
to get the same accuracy as interpCurve3D the lengthInterp algorithm needs increase the default steps count about 10 times. of course it makes the calculation ~10 times slower.
because there is no way to set-up the number of steps in the Spline IK Solver the solver always works bad.
The precision is sufficient for me (e.g the step is supposed to be 1 meter, and the samples are ~0.99-1.01, which is sufficient for my use. There is no problem of trimming, the samples goes from 0 to 1. And the function is much faster than lengthInterp()