I don’t believe there is a built-in property type corresponding to an entity’s acceleration. However, this value should be fairly straightforward to evaluate.
What’s the use case here? Are you looking to display the value, or is the use case a bit more complex?
In fact, I think it’s possible to evaluate the VelocityVectorProperty of the entity’s VelcoityVectorProperty in order to compute the acceleration– Here’s a quick example.
Thanks - I don’t think that example is producing valid values for acceleration though. (E.g. 382270749m/s^2). Looking through the code it looks like it should work though.
Ah, I think it doesn’t work because VelocityVectorProperty.getValue isn’t re-entrant. The scratch variables (position1Scratch…) used to store velocities get corrupted with positions (when accelerationVectorProperty.getValue() calls velocityVectorProperty.getValue()).
Besides the issue of the scratch... variables, there is also a… conceptual question.
In the example (and in many cases), the position is a sampled position property with linear interpolation. This means that the velocity between two sampling points is constant. And the acceleration between these points is zero, with “infinite spikes” at the times where the velocity changes:
There are different ways of avoiding that, depending on the data source. But for the example, one can use SampledPositionProperty#setInterpolationOptions. (Note that this will compute some derivatives (i.e. the velocity and acceleration in this case) internally, but there is no way to access this. So the following is probably not the most efficient solution, strictly speaking, but a relatively easy one).
The next issue, about the scratch variables, could/can be solved by … avoiding these scratch variables. This is not directly possible with the VelocityVectorProperty. But … It would be easy to generalize that VelocityVectorProperty. In the following, I just created a class called DerivativeVectorProperty (because that’s what it is).
An aside: This property does not have that normalized functionality. But that shouldn’t be a parameter of the property to begin with. If someone wants normalization, then it should be possible to “wrap” these properties, like
const position = create();
const normalizedPosition = new NormalizingProperty(position);
However, here’s a full sandcastle, showing this as an example. This is just quickly thrown together, based on the “Manually Controlled Animation” one, but shows one possible approach:
It’s hard to guess from the screenshots. But in general, and very roughly speaking, “noise can cause things like this during the interpolation”. There might be ways to alleviate that - maybe something like a sliding window/moving average could already reduce that “wiggling” that is visible in the second screenshot. (The scatter charts really don’t look that noisy, so so maybe there’s something else - beyond the noise - that causes this…)
