[Bug + Steps] SplineLocation along distance is inaccurate

Reproduce Step :

Make an actor with spline. Put it to 0,0,0 in the world.
Duplicate spline point 0 in X-axis.
Now you have 2 points. 0 and 1 with the same X-axis with an undefined length.
Setup a loop function to print out values at each interval distance ( i use 100 )
The location seems to be somewhere near 100 but not 100.
I assume this is incorrect? If I’m wrong please tell me

I believe you are correct, had that issue before. It calculates the distance based on the spline curves and those do not seem 100% accurate.

If your splines are straight between points (no tangent manipulation), you can try doing this:

FVector GetWorldLocationAtDistanceAlongSpline(USplineComponent *Spline, float Distance)
{
	if (!IsValid(Spline))
		return FVector::ZeroVector;

	float StartDistance, EndDistance;
	FVector StartLocation, EndLocation;

	// First Point
	if (Distance == 0)
		return Spline->GetWorldLocationAtSplinePoint(0);
	
	for (int i = 0; i < Spline->GetNumSplinePoints(); i++)
	{
		float d = Spline->GetDistanceAlongSplineAtSplinePoint(i);

		if (d >= Distance)
		{
			StartDistance = Spline->GetDistanceAlongSplineAtSplinePoint(i - 1);
			EndDistance = Spline->GetDistanceAlongSplineAtSplinePoint(i);
			StartLocation = Spline->GetWorldLocationAtSplinePoint(i - 1);
			EndLocation = Spline->GetWorldLocationAtSplinePoint(i);

			float lerp = (Distance - StartDistance) / (EndDistance - StartDistance);

			return FMath::Lerp(StartLocation, EndLocation, lerp);
		}
	}

	// Beyond last point
	return Spline->GetWorldLocationAtSplinePoint(Spline->GetNumSplinePoints() - 1);
}

I actually need it for a curved spline. Just made this example to simplify it. I did find a solution eventually using.time. A very inelegant work around.

Thoguht id report this if epic isn’t aware.

Thanks.for your solution tho.

Hi ,

Does this occur at larger values or is it always at the smaller scale? At present, this looks like it may be related to a float point error, which unfortunately is something that occurs in computations in general. More information on which can be found here:

In my case the spline had a length of < 10000 units. The error was ~30 units and changed slightly depending on the spline distance.

The error gets in larger spline too. U can test it out. The one I check has about 2000 in length in total . the error.is about 10% disrepency.

Do you have a sample asset that I can see this occurring in? Is the error margin constantly increasing as the asset location increases along the spline or does it remain constant?

EDIT : I just deleted my previous comment. I found the bug again.

here are the files. video and project files… move the second point and you’ll see how much error it gets. about 5-10% which is a lot.

Move the second spline point and you’ll see it interactively

link text

Unfortunately using the spline asset provided I am not seeing any changes in the debug sphere behavior when I move the spline point. They remain at the same distance despite moving the second point several thousand units away on multiple axis locations. The distance along the spline and between each sphere remains constant, only changing direction if the Y or Z axis is changed. Do you have any other steps I can take to reproduce this error on my end?

Oddly enough, I opened the project a second time and it started occurring immediately. I do not know what I did differently to cause the error to occur, but I was able to easily reproduce this and have entered a bug report, UE-27979, to be assessed by the development staff.

link text

ehh that’s weird… r u moving them in this manner? download and view the video . i

I just did a quick test and it appears to only happen if the points are set to Linear.

Here’s the blueprint:

And here’s the printout:

LogBlueprintUserMessages: [NewBlueprint_90] Spline length: 2100.0
LogBlueprintUserMessages: [NewBlueprint_90] X=0.000 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=91.743 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=183.486 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=267.805 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=349.106 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=429.771 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=506.107 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=582.443 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=658.346 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=733.534 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=808.722 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=885.271 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=962.791 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1040.310 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1123.529 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1207.563 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1296.505 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1393.592 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1496.296 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1619.753 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=1776.604 Y=0.000 Z=0.000
LogBlueprintUserMessages: [NewBlueprint_90] X=2100.000 Y=0.000 Z=0.000

This is still an issue. The aproximation is really bad when dealing with curved splines.

See also this post, specifically the second problem, showing that with a spline using differently-spaced points will bunch and spread the points returned by Get Point at Distance Along Spline for equal requested distances:

This is still a big issue. When the tangents are manipulated, it creates significant inaccuracies, that aren’t even consistent along the spline.
Here’s a video I made where I show how to reproduce the problem:
https://www…com/watch?v=HMSg7qX_gGw .
The issue UE-27979 is marked as Cannot Reproduce, but clearly it can be reproduced. Can someone take a look at it, please?

Please see my comment below, this issue has not been fixed and can be reproduced.

That’s exactly the behaviour I found. Can a staff member please reopen UE-27979.
It makes for really buggy results when trying to move meshes along the spline. Here’s an example video: https://youtu.be/5_BQ2LmhZKo .

Is this a joke ? You can but in the report you can’t ? And that was 2 years ago…

I’ve found the same problem. Attached is a zipped project that demonstrates it.

To reproduce the bug, simply open NewMap, select the SplineBug object therein, and press the Print Distances button. The Output Log should display that the “Sum of Delta Distances” is 1438.82, and that the “Actual Spline Length” is 1438.80. Scrolling up to “Current Time: 0.986” should show a Delta Distance Ratio of 1.46.

The PrintDistances function sums up the series of distances between discrete points on the spline - points which should be evenly spaced apart - and prints that sum, along with other data about the points themselves. For example, each Delta Distance Ratio describes how far these points are from actually being evenly spaced. If a point has a DDR of 0.95, it is only 95% as far away as one would expect from the previous point. If it has a DDR of 1.10, it’s 110% as far away as one would expect.

If you play with the points a lot and heavily distort the tangents - which appear to be the source of the problem - you should be able to get somewhat greater inaccuracies. These don’t seem significant in aggregate, but individually, a DDR of 1.46 (or worse!) can cause problems. In my case, I’ve been trying to have an enemy follow the spline over time, but fall off of it when it becomes de-synced with its expected position, i.e. if the player knocks it out of the way. However, this is occurring without any external interference, causing jittery movement as the enemy tries to return to the spline upon which it’s already standing.

2019 here with 4.21, still having this issue, I’ve reported it via the bug system in the hope it will be re-opened, but really annoyed that this accuracy issue still occurs, currently breaking a core game mechanic and I’m currently looking into potential solutions…