Have just checked last 2.8 build - blender-2.80-f1e3e50-win64. The bug is still there. I am not in a hurry just to keep in mind it)

that is accurate. in 2.7 it doesnt work like this, but this isnt useful at all, as an animator you want to see in the path the keyframes of the currently selected object that affects it,
example: the path is set to the head control, but i have the hip selected, the path should show the keys of the hip, because that´s what im modifiying that will ultimately affect the path because of the hierarchy (you should try to confirm with hjalti, he knows exactly what im talking about)

@Luciano Muñoz Sessarego (looch)
I don't understand. Keyframes are only showed when there is keys are on the motion path, which is baked from an object/bone.

its important to show the keyframes in the motion path of the selected object, which is not necesarilly the object from which the motion path is calculated.

Is there a reason not to tag the baked motion path verts if there are on a keyframe? It would simplify the whole drawing a lot.
Also I don't see the point of showing synced keyframe marker but at the baked position.

@Daniel Paul (DaPaulus)

• Auto calculation is a separate topic - it's not related to the drawing.
• The main interesting features of that mockup are the explicit display of the start/end frames. Otherwise, it's actually pretty much just the standard display
• "Tangent editing" or just general motion path editing is actually a lot harder than it looks - especially in everything other than the most basic case. Unfortunately, you can't just support that simple case, as people will want the others too. Anyway, again this is separate from the issue of just getting drawing code working

Im not sure if i overlooked something in the description above,
but will the motion paths be calculated automatically.
So we dont have to set the framerange, only a max and min frame value would be nice.

in regards to drawing, maybe there could be an option to randomize colors for them, so each new path gets a different color, though they should probably go in order, Ie, 1 gets red, the second one gets green, the third one gets blue and so on, much easier to see, and the thicknes definitelly should be like what in 2.79 wa 2 px or so.

oh cool, sorry for spamming the wrong thread, if you want to point me in the right direction it Id be happy to contribute :)

@Luciano Muñoz Sessarego (looch) That is a separate topic - Calculation of motion paths is not the same as the drawing code (which this task focusses on restoring).

Please consider an option to offset the motion path!, example, i create a motion path on the head bone but i want to offset it to the forehead, or to the tip of the ear (which are directly moved by the head joing)

Offloading to @Clément Foucault (fclem) who can probably do this faster, while I deal with nasty Copy-on-Write issues.

@Sybren A. Stüvel (sybren) Didn't note the exact revision, but it one from was Monday (14 May) afternoon, (from around 4-5:30pm). I should probably run it again (maybe daily) to check if things have changed with the DM/modifier cleanups since.

Profiling suggests that the main costs are still just modifier evaluation (> 60%)

Fantastic stuff. Thanks everyone.

Regarding PyController Removal + Drivers/Custom Properties Creation Script thing , even though the rig works without it, I realized that the animations in 2.79 are keying these api defined properties, so I should add the script with the drivers trick anyway so that animations work properly.