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 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.
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:
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?
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.
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?
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 .
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…