Crouch you are awsome!!! This looks really amazing!
Would it be even possible to grab the keyframes and position and time them to a different place/frame??? And bezier handles would be awsome for the keyframes, with that option it would be easy to make smooth arcs!!!
I think this should be suggested somewhere… I would love to see this feature nicely implemented in blender…
great and fast work Crouch 
this addition would be very handy and timesaving indeed
can it be also combined with grease pencil?
like sketching arcs/motion paths and also where to put keyframes (like intersections with shorter lines), then ‘bezierize’ the grease pencil sketch and finally tweak the curve with this lovely tool right in the viewport?
woow… great work Crouch and thanks for sharing this script that has huge potential
Crouch, Oh my good!
Jur!
Amazing stuff Crouch.
BTW, what’s the big deal with the Maya version? 
Crouch, this is freaking awesome… thanks for sharing yuor talent 
ndee: keyframe manipulation would be trivial to add. Bezier handles would be a bit more work, and would need a good proposal to start from, as you might get weird conflicts after moving time beads.
psychotron: the sky is the limit, though I think it would be easier to use an existing functionality: creating a curve, parent object to curve, follow path.
Thanks for all the nice posts
Wow this is amazing work dude!
Follow path doesn’t always come in handy (for example when working with particles), so this is a really handy addition. Hope someone finds the time to finish it up!
This looks really promising Crouch! I’ll also agree that the Follow path option is not a very ideal solution for most cases. Yes it works, but it’s not very intuitive.
@crouch
I’m not pretending to know how this is done in maya. I can’t write code, I don’t know blender internals and I don’t know maya. I’m not suggesting that you can’t achieve something similar in blender. But the more I think about it the more I doubt that it can be done in blender.
So please indulge me, while I explain my theory.
The basic problem.
When you modify an f-curve you change the speed and position. Wouldn’t it be great if you could change the speed without changing the position and wouldn’t it be good to change the position without changing the speed.
The solution.
Simply add speed and position constraints. Yeah? but wouldn’t that simply lock the curve. Well it would, but if you placed the curves in separate animation layers and blend down then you have a pretty elegant solution.
It goes like this;
Okay, I know on you-tube it says something like no f-curves were harmed in this demo and I’m tempted to say “you shouldn’t believe everything you read”. But perhaps a more apt expression would be “you shouldn’t imagine that the obvious interpretation is the correct one”. If you added an f-curve constraint in a new animation layer. The statement no f-curves were harmed would be just as valid. In fact you might imagine that you are being clever by giving an obvious clue, but not giving the game away entirely.
So I’m hoping you’ll consider my theory and let me know if you think this might be what they’re doing in the maya vid, and also whether you think this could be done in blender. If it could; how would it compare with your solution, i.e. would it be more or less cpu/memory intensive, would it be more or less adaptable to geometry or armatures and which would be easier to apply as a modifier.
I don’t know if I understand you correctly but I’ll try to explain.
The x-location of a keyframe in the F-curve editor determines the time and the y-location the position of an object. So the position and the timing are already uncoupled.
If you move a keyframe in the x-direction, in the F-curve editor, you change the the time at which a position is reached and not the position itself.
If you move a keyframe in the y-direction, you change the position but not the time at which this position is reached.
In both cases you affect the speed because that depends on both the position and the time. In the F-curve editor the speed is represented by the slope of the curve.
In the video of Crouch the position and the time are also uncoupled.
The position is represented by the motion path, which is controlled by the yellow points (keyframes). The changing of the motion path is not shown in the video, but Crouch stated in post #27 that it would be trivial to add.
The timing is controlled by the green ‘time beads’. This is shown in the video, if you look at the F-curves in the video, you see the keyframes move in the x-direction as the ‘time beads’ are moved.
It would be very inconvenient to lock the speed because then the position and timing are coupled, in other words, dependent on each other. For example, the position of your animated object would change if you change the timing of the keyframe. This could ruin a beautiful pose.
Maybe there are situations in which it would be handy but then it should be an optional feature.
Crouch dont take it the wrong way but did I tell you I love you?
@Wolter
Thank you for taking the time to explain but everything you described I already understand.
I can only conclude that you do not understand me at all.
But I’ll try to explain. An animation path is described with vectors. Vectors have two basic qualities, direction and speed. Vectors do not have a position except that they are given a co-ordinate system. So in a 2D co-ordinate system they have an x and y position and in a 3D co-ordinate system they have an x.y and z position. Changing the vector location in either system does not change the vector speed or direction. However it does change the curve shape. As you have already pointed out, when the co-ordinate system is an f-curve changing the curve shape by modifying the vector position affects the speed and location of the animated object over time.
Another way to change the curve shape, is to drag the vector handles to a new location, this does not change the vector position, but it can change the vector speed and direction ( depending on how you move it. ( because in dragging the vector handle you can keep the direction or the speed constant, but not both at the same time.) ).
To illustrate this.
Draw a curve in a 2D view with grease pencil. add a mesh sphere. keyframe it at the the beginning of the curve (frame 1) scrub to frame 60. ( set end frame ) move the sphere to the end of the curve and keyframe it. Scrub back to frame 30. position the sphere on the curve and keyframe it. Now if you you play the animation the sphere’s motion path should roughly approximate the drawn curve.
Open the graph editor. the curves should be selected and editable. press v on the keyboard and select vector.
on the x-curve choose the output vector handle for frame 1 or the input vector handle for frame 30 and drag it to a new position. you will see that the sphere changes speed.
However it also changes the animation path. To correct this select the corresponding vector handle on the z-curve and move it to the corresponding position, so that the z-curve mimics the x-curve. Now the sphere should follow the original path but the speed will be modified.
If you drag the output vector handle at frame 30 or the input handle at frame 60, you will again change the animation speed. and as you might imagine the animation path. To correct the path the z-curve needs to be a mirror of the x-curve, i.e. its like you take the x-curve and flip it over.
Now if you followed these steps you might imagine that there is some magical mathematical formulae that could be applied to the z-curve so that it automatically adjusts its shape, in order to maintain the original animation path, while you play around with the animation speed by adjusting the x-curves vector speeds and directions and you might, for want of a better term, call this a constraint.
If you follow my logic and you understand that, modifying vector handles changes not only the animation path but also the animation speed then you should be able to imagine a system of constraints that allow you to adjust one without adjusting the other.
I have already described a such a system in a previous post. Its not the system used in the maya video, but the underlying principles are not dissimilar, i.e. paths and constraints. Remember a path may wear a different hat, but whether its an f-curve or a nurbs path or a subdivided mesh, its still a group of linked vectors.
@Wolter
The only major difference between what I’m suggesting and the technology used in the maya vid is the possibility that in maya they are using animation layers. I don’t know if maya has animation layers. I know that motion builder has ( the last time I looked ) probably the best implementation of animation layers and that maya acquired motion builder before being bought by autodesk. So they certainly have the technology. Blender does not have animation layers. It has actions, and from my naive perspective I imagine that you could save the f-curves as temp actions and blend them on the fly. But I have absolutely no idea of whether this is possible or if there is a much better solution. I don’t believe they are using keyframes in the maya video. It’s definitely possible and with animation layers its more than possible. However I think that using vector speeds and directions is lest cpu and memeory intensive, especially when working with large scenes and lots of characters and so it seems to me, to be the more logical solution.
Crouch, you are a legend! I’ve been hoping for this for ages. A very welcome addition to the toolkit.
@sx-1, don’t like it? (or understand it?) then don’t use it.
@freen
Ouch!
first off, I’ve never said in any of my post that I don’t like it, actually it’s rather cute.
As for not understanding it. I think I understand it very well. Open up a graph editor use B,SX, GX. and set your curser anywhere you like, drag your mouse. It’s not rocket science . But look again at the maya video. Crouches script does not replicate the underlying behaviour and it only partially replicates the interface. He has already said that it can be modified to replicate this behaviour and I believe him. But when he suggest that this is proof that it can be done in blender I’m not so sure. Because there is nothing in the video to suggest that what is being demonstrated uses keyframes and without evidence its impossible to say that any interpretation constitutes proof. Therefore my interpretation of what is actually happening in the video is just as valid, until proven wrong.
P.S. Please note that in Crouches reply to psychotron he recommends that in some cases its better to use an existing functionality and describes a process which I already described in a previous post. So we are not in total disagreement.
It’s a great great news.
I’m a animation teacher, and I think it could become an unvaluable tool.
When you animate, you need to dissociate trajectory and velocity (or posing and timing). It’s the right way to do it, in the viewport, without that mathematicals F-curves.
Now, we have to think about a way to represent the rotation. I think it could be possible by showing the trajectory of the end of the bones.
That’s right, I didn’t understand you 
Maybe I misunderstand you again, so just to be clear, we both agree that the motion path is controlled by vectors on certain frames, which are therefore called keyframes.
If you mean the length of the vector handles determine the speed, then I think you’re wrong. The slope of the curve represent the speed, so the direction of the vector determines the speed on the keyframe.
The length of the handles determine the influence of the control point on the interpolated curve.
I think I’m beginning to understand what you mean. I’m going to try to write down what I think you mean, so you can correct me if I’m wrong.
By constraining the position, you mean that you want to be able to adjust a certain parameter, that influences the interpolation of a curve between two keyframes, in a way that the motion path doesn’t change. Am I correct?
Only the speed changes, though the average speed between the two points wouldn’t be changed, because the distance and time between them remains the same.
This might be a nice feature and you’re right that it looks like this is what is demonstrated in the maya video in the first post.
However I find it hard to imagine to change the position of a vector without changing the speed. I thought of two possible ways you may have meant it.
If you mean that you change the position of a vector in a motion path in 3D space, without changing the speed, it would mean that the time and position of the keyframe are coupled. If you would move a vector away from the vector on the prior keyframe the distance between them becomes larger, so the time between them has to be longer as well to keep the speed constant. You would also have to deal with the shape of the interpolated curves.
I think this would be a very inconvenient option.
But if you mean that you move a vector along the motion path without changing the shape of the motion path nor the speed of the object along the motion path, then it maybe could have some potential.
This would be equivalent to move a keyframe along a curve in the F-curve editor without changing the shape of the curve. It would have some limitations (because, for example, you can’t have a interpolated curve with three extrema) yet it would be nice.
But there isn’t such a feature in the 2D F-curve editor, let alone in this new motion path concept.
I like the concept of Crouch very much and I think the features described above are absolutely not essential. It would be just great to be able to directly adjust motion paths!
Most of you think about rigs here.
But for simple keyframe animations like in After Effects this would be a dream
because I see the path through the 3D view and do not need to play inside
the IPO window and guess how this would interact in 3D.
Crouch, thank you; a great poc demo. Motion path visualization is a great step in the right direction, but what I could really use is an onion-skinning (or ghosting) of a characters geometry. Much more useful for checking arcs.