Indeed, I'd be very surprised if this was related to T51971.

Is this only for the new depsgraph? Testing with the old depsgraph seems fine here.

Sorry I could not dig into coding, busy days. The way I see it, if there is interest in keeping this feature but there is no way to make sure it behaves properly, it should definetely be an optional setting. This way the user can willingly activate non uniform scaling, and renounce the benefit of the animation tools in exchange.

hi, we need some resolve here, people are waiting for this to be fixed.
Thanks

No reply over a week, and can't be created using current master by @Bastien Montagne (mont29) , therefore closing for now.

Looks like you've just got a messed-up Pose Library action.

Just to reiterate a note I made in the commit -- You'll need to manually click on the start and end frame properties of the Stepped FModifier to flush the relevant changes.

Committed fix, though the case of buttons force-exiting drag isn't well supported (undo pushes aren't made for eg).

This is a known limitation of old dependency graph, which is addressed by the new dependency graph.

Do not set priority of tasks yourself, especially not to high priorities!

Strange... investigating now...

I think D2088 changed two things:

• Non-uniform scale is no longer inherited when applying the IK transforms, to match the IK solver normalizing the matrix and making the scale uniform.
• IK stretch no longer affects the X and Z axes. I think this was an unintentional change. This is demonstrated in ik-stretch.blend, but not necessarily the reason the scripts and tools are broken.

Not that familiar with this feature, it is implemented by @Campbell Barton (campbellbarton).

Cannot confirm that with current master, please:

• Try the latest build from our buildbot.
• Try to start Blender in factory settings (--factory-startup commandline option) (this will ensure whether this is a userpref or addon issue or not).

Not sure how much we could support that… @Joshua Leung (aligorith) another one for you to check I guess?

This is evaluation issue… Some notes:

• Looks like is the differential movement between two frames was applied twice. That’s why constrained bone goes back to its place after few frames without any movement.
• With old depsgraph, enabling Extra Data Update for the proxy and the instancing group fixes the issue.

Seems in your area @Bastien Montagne (mont29).

Ok Thank you ;)

Thanks for the report, but I think this is working as designed even if it's arguably what the best behavior is. You need to select the node with the keyframe to make it visible.

An update:
So this seems to happen when you move the keyframe past the other keyframes, triggering the keyframe sorting (sort_time_fcurve()) . Disabling that step solves the crash here, but is kindof undesirable in that the curve doesn't get resorted/recalculated.

The task is still actual. The patch is still working for me. Could anyone take a look?

I understand, but as explained scaling this high is necessary to export to .fbx for Unreal Engine... Though it's possible to reduce the scale, would have been nice to handle these high scale units...

Your object is 12252.83 by 7.568 by 21773.992 blender units (the metric preset thingie is purely interface, internally everything is stored in Blender Units!) which ruins all precision of the IK solver which uses single precision floating point types.

Thanks for the report, but this is more a known limitation currently than a bug, as you said bands are only identified by their ordered-index, which means they cannot cross each other in animation…

In T51675#437833, @Joshua Leung (aligorith) wrote:

Hmm... it's a bit unclear atm what is intended here regarding what modes these will be available in. On one hand, it sounds like you're saying that facemaps will always be available in object mode, but then, in the next paragraph/section, you mention stuff about these activating corresponding bones and allowing tools like keyframing/breakdowner/pose-library/motion paths/etc. to be used as if the bone was selected.

Hmm... it's a bit unclear atm what is intended here regarding what modes these will be available in. On one hand, it sounds like you're saying that facemaps will always be available in object mode, but then, in the next paragraph/section, you mention stuff about these activating corresponding bones and allowing tools like keyframing/breakdowner/pose-library/motion paths/etc. to be used as if the bone was selected.