This post says that “The energy of a goal is the half the squared distance of its particles from their rest state, multiplied by the weighting of that goal”. Relating it to the source code, does this mean that it is the Move vector that gets squared?
That would make sense to me if I look at the wider scope of goals like those related to loads where it doesn’t make sense to have a rest state. When I give the Load component a vector, I assume then that this vector is taken directly as the Move vector, with some imaginary target x distance away where x is the magnitude of the input vector. The energy is again half the square of the magnitude of this Move vector, and the weighting is just an additional scalar way of adjusting the energy.
I’m not entirely sure I understand the Move vector for the Length/Spring goal though. How are the expressions for the “stretch factor” and the “spring move” related to physical behaviour?
Yes, you’ve understood that correctly. The Move vector is squared when you want to calculate the potential energy, and for things like load where it’s not exactly moving towards a rest state*, it’s a target some distance away in the direction of the load, and adjusting this distance away vs adjusting the weighting are 2 ways of adjusting the same thing (changing one vs the other shouldn’t change what it converges to, for convex problems at least, but it will slightly affect the path taken to get there).
*actually we could consider load as an attraction force towards the center of the earth, so it does have a rest state, it’s just that for most practical purposes we can ignore the change of weight with height, so it makes sense to treat it as a constant offset!
As for the ‘stretch factor’ expression in the spring calculation, it works out exactly equivalent to the vector you get doing it by calculating the more obvious way (for example as shown here), it just cancels out a unitization step to reduce the amount of computation.
Thank you very much for the clarification. The goal script does make more sense. It looks like each point in the spring is moved, in opposite directions, the same half-distance required to get to the rest length. It is interesting to see how this type of spring movement shows up in all sorts of other goals like Collider in their own variations.
Yes, indeed - many of the goals can be seen as essentially variations of a spring. This sort of quadratic energy is simple to calculate, nice to optimise, and corresponds to Hookean elasticity, so matches well lots of physical phenomena.
Sphere collision is like a spring with only the compression part (because when they are pressed together they push apart elastically, but there’s nothing pulling them back towards each other). OnMesh is like a spring connecting a point to the closest point on a mesh, CoCircular is like springs pulling each point towards the best fit circle, Floor is like a spring pulling points below the plane back up to it etc…
I think of OnMesh as more of an anchor, but I guess anchors are just springs too, just with one end fixed!