Feature Request - auto tweak/analyse curves for fast moves

[rider-rebooted]

I would love a way to select a range of IK keyframes and click a button in Mimic to automatically tweak the curves - finding the right balance to eliminate jerk and velocity errors (when possible).

This would save a lot of time!

I’m probably dreaming, but if you don’t ask...

[evanatherton]

This one would definitely be challenging. I think it's possible, but don't think I'd be able to take it on in the near future. Hopefully someone else could take it on. I don't think it'd require that much knowledge of the Mimic codebase, so that's a plus for what that's worth

[rider-rebooted]

It would be an unbelievable time saver.

Doing a task like this is frustrating when you know that, in theory, it could be automated :-)

[hsouders]

I've thought about implementing this in the past, but I'm not sure of the best solution.

As a very simple example, let's assume you have multiple keyframes: A, B, C.
Let's say you hit a limit around keyframe B.
How to do you determine which keyframe(s) to modify?
Let's say you can you can resolve the issue by just modifying keyframe B, but B is your most important keyframe. So you don't want to modify it. Assuming the problem can be solved by modifying A or C, which one do you modify? You need some method of hinting to the algorithm what keyframes are most important, or you make an algorithm the modifies all keyframes a little and just cross your fingers.

This is a pretty naive example, but it makes me wonder if the real answer to this issue is that the animator should be given better feedback/tools when creating the animation?

[evanatherton]

@hsouders makes some good points. I tend to think think this wouldn't be as necessary once we get realtime vel, accel, jerk readouts in the viewport during animation. That way you can slide keyframes around, albeit a more manually, but get instant feedback without doing a post-process. And that one is pretty high on my personal list of features I'd like to see

[rider-rebooted]

Hi @hsouders

I wouldn’t want/expect this solution to move keyframes around.

If it his a jerk limit on or near keyframe B, then the script would flatten the curve at that keyframe a little to reduce acceleration, then analyse again. Repeating the process iteratively until there are no jerk errors at keyframe B.

The flatter you make the curves at keyframes to reduce jerk errors, the steeper the curve will be between keyframes as the velocity has to increase. If the script eliminates the jerk error at keyframe B but introduces a velocity error between keyframe B and C then it should warn the user that a solution is not possible and that the time between B and C keyframes should be increased. The user spaces them out by an extra frame and initiates the script again.

Of course there could be an option to allow it to add that space automatically but I don’t think a user would like that enabled by default. They might prefer to reduce the range of motion instead.

@evanatherton The real-time read out in the hud certainly sounds interesting!!! 😍

[rider-rebooted]

It should be pretty easy to identify which sets of keyframes are causing issues...

If keyframe B is at 25 frames and the jerk error is at 26 frames then it is the movement between B and C that is causing the issue. If the jerk error is at 24 frames then it’s the movement between keyframe A and B.

Granularity could be increased for slower analysis but smaller tweaks. Although getting too close to the nominal limits in Mimic can cause real world problems as I’ve discovered 😂.