I just lost a couple of hours to this. Vinterp to Constant requires extremely high input values on “interp speed” for it to have any noticeable effect. In my case I found it needed to be a value around 40,000x higher than the similar “Vinterp to” node in order to get a similar outcome.
At “reasonable” values it appears to just output the Current value unchanged, as if it’s not working at all.
I wasn’t sure that I should tag this as a “bug report.” I am new here so treading lightly. But this is at best an extremely misleading function, one which cost me valuable time.
It doesn’t matter what is being set here in the exec nodes as I tested it with line traces as well. The only difference I see is that the first one has a length element, so maybe that is somehow the culprit?
One of the reasons I posted this thread is I found a few other past examples of people posting comments about this node not working for them until they put in a big value. So it was clearly not limited to my code/experience.
The 1st example is a tad strange. Is it ticking? Is this supposed to constant acceleration for a projectile?
The 2nd one seems fine providing it’s running on Tick.
Regarding people saying something is not working… bugs exist, sure thing; but it’s often simple user error. All interpolation relies on previous samples. Crap comes in, crap comes out
It is ticking. They’re both wired up one after the other. The first code takes the current velocity vector of a projectile and interpolates it with a vector pointing towards a target location, with the second vector multiplied to represent a desired speed. So in simple terms, a speed (or length) and direction lerped with a speed and direction.
In the second example the lengths are the same and only the direction changes. My suspicion is that larger differences in lengths between vectors disproportionately affect the rate of interpolation with the linear version. With the non-linear (smooth) version it does not seem to matter.
I’ve had a think about this and here is my theory. Sometimes with these things there’s some ambiguity with the terminology. In this case the node is described as working “at a constant rate.” It’s not clear just from reading what exactly is “constant.” Personally, I would intuitively expect it would take a constant amount of time to move from a starting value to the target value, similar to the function of the “non-constant” version, just without the smoothing. I may be wrong but I feel like most people would expect it to behave similarly to the other, given similar naming and identical inputs.
What I think is actually happening is that the numerical change over time is what is being kept constant, even if the input changes. What would this be for? For positions. Otherwise known as locations. If, for some reason, you wanted to interpolate between one location and another and have your thing move through space at a “constant” rate, that’s probably what this is. Think of moving between two points on a map. If the points are far away, it will take a long time.
Here I am trying to interpolate between velocities and rotations (technically normalized vectors) because it is labeled for vectors! What I’m doing doesn’t even make sense! But there’s nothing at all unreasonable about the approach at the surface level, based on the information presented.
They really ought to rename this, or update the description at the very least.
Edit: if it matters to anyone, I bet you could multiply the value going into Interp Speed by the difference (distance) between the two input vectors to normalize the interpolation time and make it function the way I thought it would. They also ought to have a proper node that does that.
