Implement motion path drawing code in draw engine
Closed, ResolvedPublic

Description

Motion path drawing code (drawanimviz.c) is not currently implemented in 2.8, meaning that old files with motion paths and/or files where motionpaths have been freshly calculated do not show up.

Branch / Current Code: tmp-b28-motionpath-drawing

Design Notes:

  • This should work as an overlay (visible in the overlays popover), so that it can be turned on/off independent of other stuff we draw in the viewport. It should not be tied to manipulator/relationship line visibility.
  • Motion paths work with both objects and bones. They can either be defined on Object Level (e.g. ob->mpath), or Bone Level (e.g. pchan->mpath)
  • The old drawing methods use immediate mode. Could/should be optimised.
  • Appearance could be updated a bit - for example, thicker/nicer line quality + shading, different ways of visualising the keyframe positions (e.g. with lines perpendicular to path - similar to what animators use for timing charts - [ 1, 2 ]

Details

Type
To Do
Joshua Leung (aligorith) moved this task from Short Term Backlog to Doing on the Code Quest board.
Joshua Leung (aligorith) triaged this task as Normal priority.

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

Current WIP code can be found in the tmp-b28-motionpath-drawing branch.

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)

@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).

Regarding what you're talking about - we have been discussing ideas for allowing calculation of paths for arbitrary geometry points instead of just objects/bones (e.g. using the derived center-of-gravity for a body part for instance). But, again, that's a separate topic, to be tackled separately/later once we get back basic functionality (with maybe a slight cosmetic upgrade).

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

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.

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.

Im not sure how dificult this is, but it would be a nice way to diplay the motion path.
Also the tangent editing is nice.

@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

@Joshua Leung (aligorith)

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.

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.

@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.
I don't even think that's possible to show the selected object keyframe on another path in 2.7.

Also for the record, I talked with @Joshua Leung (aligorith) IRL and he told me it was ok to bake the keyframes into the motionpath verts.

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)

Dalai Felinto (dfelinto) closed this task as Resolved.Jun 4 2018, 10:25 AM