Updated summary with what proper keyframing means.

Ok, I'll remove the extra function.

Is this what you had in mind?

2.93 is going to be another LTS release, and introducing such backward-incompatible changes could make it unusable for studios. I think Blender 3.0 may be a better release to put this fix into.

Can confirm, this was working in 2.79.

In D10401#269348, @Sybren A. Stüvel (sybren) wrote:

I accepted to soon.

This clearly is a mistake in the code, as it's indeed inconsistent with the other uses of the frame range. I'm just wondering how many files there are now that have set their modifier frame range slightly differently than they'd actually want, basically to counteract this bug. If we now fix it, that means potentially breaking the animation in those files.

I accepted to soon.

I think part of the problem is that insert only needed should not manual keying if it works only for keyssetby the autokey system, then problem solved.

Ok, from a chat on blender.chat, here is a proposal that could make Luciano's idea work.

Again I can't speak for the animation code. Seems fine from my side.

• Move code into armature_pose.cc and convert to C++

AFAIK operators aren't really meant for calling from Python, and are there for things like buttons, menu items, hotkeys, etc. This function is intended to be lower-level than that, as a building block for operators, and not for direct use by users.

just "someone could find it useful, maybe". Which is bad as we can't design software around "maybe useful" functionality.

LGTM.

Note: This does not add support for proper keyframe remapping.

• nlasnapshot_enable_all_remap_domain() is unused in this patch but seemed generally useful when using snapshots for remapping. D8867: Feature: NLA Merge Strips would be able to make use of it. Though I suppose that means that D8867 should also introduce it?

• remove unnecessary braces

Just to note here what was discussed in the Animation Module meeting (which is free for anyone to join): If no legitimate use case is provided soon to back up the Y/Z symmetry + Vertex Group X symmetry, we will most likely go ahead with the patch as it is.

So, since rB0f893656f4d1 is already on the list for backporting T85958: Potential candidates for corrective releases, I think we can close this report.

In T86163#1122072, @Falk David (filedescriptor) wrote:

I can confirm this for 2.92.0, but it works in master.

Any reason to do this as function, not as an operator? Looking at the function, I don't see a reason to do it this way off hand.

• Rename function to apply_pose_from_action, so that it's clear that only a single pose is applied, and not all animation in the given Action.

So this changed in rB0e85d701c654: Animation: Bake Action, improved discontinuity filter for bones, not sure what is intended here, @Sybren A. Stüvel (sybren) would have to comment here.

After disable all add-ons i think this crash cause by flip fluid add-on.

It is always preferable to not have full rigs as example files.
These of course are more complex to debug, please always try to put together a minimal example file:

• does this also happen without visual keying?
• does it only happen with these kinds of constraints?
• ...

yes!

5. Oh so baking to a new action should keep the nontransform animated channels? Can do.

I'm not sure how they are the same?, 6 does involve the improvement from 5 though.

I'll make test patch for the levels idea.

Any news ?

@Sybren A. Stüvel (sybren) Should this patch be abandoned now? I'm happy to update it to master otherwise.

That's why I think I'd work if there is an intermediate bone that doesn't have a key good then its not considered and only consider the ones that do.