Change Details

**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. This is not optimal in regards to performance, but it matches current behaviour for transforms from the viewport when auto keying is on. I can see a few ways to mitigate performance issues for bigger scenes : a) Streamline the motionpath update code so that it doesn't take as long b) Let the user turn live motion path refresh on and off c) Do less work by only updating the very frames and object that need to be updated, with an approach à la dependency graph (this already happens to an extent, but it could be done with finer granularity) (c) is definitely the most reliable approach but it also requires the most in-depth change, and I'm not quite sure how to go about it because I don't know the code base enough yet. If someone here has more knowledge about this part of the code, I'd love to hear your input. EDIT : performance issues are not that big of a deal now, I've changed the code to use single frame updates when a transform is not confirmed **Before** {F8944697} **After** {F8944698}

**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. 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. **Before** {F8944697} **After** {F8944698}

**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. This is not optimal in regards to performance, but it matches current behaviour for transforms from the viewport when auto keying is on. I can see a few ways to mitigate performance issues for bigger scenes :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. a) Streamline the motionpath update code so that it doesn't take as long b) Let the user turn live motion path refresh on and off c) Do less work by only updating the very frames and object that need to be updated,Here is a stress test, with a dozen motion paths having each 100 frames. with an approach à la dependency graph (this already happens to an extentI'm not an animator, but it could be done with finer granularityso please excuse the wonkiness of it :) (c) is definitely the most reliable approach but it also requires the most in-depth change, and I'm not quite sure how to go about it because I don't know the code base enough yet. If someone here has more knowledge about this part of the code, I'd love to hear your input. EDIT : performance issues are not that big of a deal now, I've changed the code to use single frame updates when a transform is not confirmed{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. **Before** {F8944697} **After** {F8944698}