Blender Git Statistics -> Developers -> toctave

Octave C (toctave)

Total Commits : 1
Master Commits : 0
Branch Commits : 1
First Commit : October 13, 2020
Latest Commit : October 13, 2020

Commits by Month

DateNumber of Commits
October, 20201

Commit Distribution

PathNumber of Commits
arcpatch-D90191

Favourite Files

FilenameTotal Edits
ED_object.h1
graph_edit.c1
object_edit.c1
action_edit.c1
transform_convert_action.c1
transform_convert_graph.c1
transform_convert_nla.c1
transform_convert_object.c1

File Changes

ActionTotalPer Commit
Modified88.0

Code Changes

ActionTotalPer Commit
Lines Added149149.0
Lines Removed1111.0

Latest commits Feed

Revision 415910a by Octave C / Sybren A. Stüvel (arcpatch-D9019)
October 13, 2020, 11:11 (GMT)
Make the operators that change keyframe data update the motion paths

**Problem **

Right now, when auto-keying is on and and one transforms an object in the 3d view, its motion paths get updated. This makes it easy to iterate over an animation and make sure the object's trajectory looks right.

However, when the animation data is updated in any other way (e.g. through the graph editor, timeline, or action editor), the motion paths don't get updated right away, requiring an extra manual refresh on each incremental change.

**Proposed solution **

This patch makes sure that motion paths get updated whenever keyframe data changes, allowing for easier incremental changes. For now, the active object's motion paths are recomputed on every edit that triggers an "ND_KEYFRAME_PROP" notifier.

**Before**

{F8944697}

**After**

{F8944698}

Performance is fine now, there is no noticeable slow down with the Rain scene. Earlier it was slow because I was updating every point on the motion path as the mouse was moving, but now (as of diff 29494) only a single point is moved interactively and the whole path gets updated once the transform is confirmed, which matches what happens with viewport updates.

Here is a stress test, with a dozen motion paths having each 100 frames. I'm not an animator, so please excuse the wonkiness of it :)

{F8965509}

I've also tried moving around the keyframes in the timeline and dope sheet, and there isn't a noticeable slow down there either, which makes sense because the code that runs is almost the same each time (tiny bit of setup + a call to ED_objects_and_pose_recalculate_paths). For very large updates, say, selecting every single keyframe of every single bone and changing their handle type at once, there is a lag of about half a second (on a Ryzen 3600 with a debug build), which in my opinion is reasonable considering that this is an unusual scenario.

Reviewed By: looch

Differential Revision: https://developer.blender.org/D9019

MiikaHweb - Blender Git Statistics v1.06
By: Miika HämäläinenLast update: Nov-07-2014 14:18MiikaHweb | 2003-2021