FollowPath Changes - 2.55 onwards

Recently I've been seeing quite a few complaints/confusion regarding some of the changes made with the FollowPath constraint and Path Animation in general in 2.5, in particular, since 2.55. So, if this sounds like you, read on!


2.4x Situation
As with many things in Blender's old animation system, the "path" animation method was quite a hack. The "speed" (this is really quite a misnomer, as "speed" implies "rate of movement", while actually the setting acted more as "evaluation time") value for curves was calculated specially everytime it was needed. That is, instead of having an IPO-Curve that corresponded to some actual property (which this effectively was), this value got recalculated everytime it was needed on the fly, and then disposed of after being used.

Now, if you had several objects following the same curve, they would therefore need this value calculated several times, with some special code needed to seek out the relevant setting.

Early 2.5
During the early stages of 2.5 while porting this back, I decided to try and tidy up the situation to resolve the issues I pointed out above. Namely:
1) Added "Evaluation Time" property to curves
2) Changed the name of this from "Speed" to "Evaluation Time" to better reflect the way it worked

By making this a proper property, this meant that it was handled by the animation system normally during animation evaluation, just like any other setting. Also, this paves the way for this setting to be driveable too.

However, there was one problem: we still needed a way so that "simple" path animation, where no speed adjustments are needed, could still work. In the old code, the way this used to be done is that an "automatic" time is calculated first (from current frame), and then the IPO-Curve was specially evaluated if it could be found. Adapting this method for the new system, this setting would get set on frame change, just before the animation for the curve was evaluated. In this way, the setting would always be updated on frame change, which is when we need it for animating the path. Problem solved...

2.55
... or so we thought, until we started getting bug reports where people had started doing weird things with curves: linking them in on weird frame numbers (or imported files were saved with varying frame numbers), but never animating them, and then finding that things would jump around on render because they hadn't changed the frame at any point (so the evaluation time would never get updated until that point).

If there's one thing I've learnt from manning the bug tracker over the years, is that the one thing (in theory) you imagine people won't try doing, they'll do. And they'll take that to the extreme, doing even wackier things that you didn't think they'd be trying to do. ;)

Anyways, getting back to today's story. After discussions with Campbell (who tried to solve a bugreport on the above a few times), it became clear that there were quite a few different weirdo scenarios that curves could be added such that we'd have weird problems like this. Although it might be possible to patch up some of these, there are many more that we cannot patch, and even some that we didn't think of yet.

So, taking things to the extreme, we decided to remove this automatic updating of this setting altogether. Personally, I was initially quite reluctant to adopt this solution as I (quite rightly as I'm typing this post now) predicted that someone out there would have trouble getting it to work. After all, there'll be people out there who "just want to make the camera fly around along a path". However, in relation to the number of cases where power users would potentially stumble across some rather unexpected and unwanted behaviour, this pales in comparison.

Having said that, we did still make sure that the follow-path animation process could still be relatively simple for the basic case. If you do the "obvious" (well, it used to be the obvious thing when everybody learnt from the old tutorials at least) of parenting the following object to the curve with Ctrl-P and choosing "Follow Path", then everything will be magically set up (as intended) for you. Just a word of warning here that this has a F-Modifier (of type "Generator") is applied by default to the created F-Curve, for simpler tweaking when you just want to quickly change the speed factor overall.

However, if you manually add a Follow Path constraint yourself, then you're going to have to go ahead and manually animate "Evaluation Time" property too.

---

A little side rant to conclude
I find it rather interesting why in recent years, there appears to be an ever increasing "allergy" towards parenting objects to each other.

For a while in the past few years, there were some people/tuts/I-don't-know-what that had the misguided idea that you had directly adding an Armature Modifier to a Mesh only (instead of parenting it) was "best" or "safest" way of making sure the mesh would get deformed. As a result, for the next few years, this approach began to be used wholesale, and quite possibly spawning the "parenting allergy". Fortunately, this disease was finally put out in a thread on BA by a few of us experienced riggers, where we debunked many of the myths that had been leading towards this view.