Page MenuHome

Disable Constraint and Keep Transform
ClosedPublic

Authored by Sybren A. Stüvel (sybren) on Apr 12 2019, 5:43 PM.

Details

Summary

I added a 'Disable and Keep Transform' button for constraints. This allows animators to disable a constraint without moving the constrained object/bone, making it easier to toggle constriants on and off without any visual consequence. Typical usage would be a character picking up an object (enable 'Copy Transform' constraint) and placing it somewhere else (disable the constraint).

Note that there could still be movement when there are muliple constraints active. For example, when using this constraint stack

  • #1: Copy Transform from Empty.001
  • #2: Copy Rotation from Empty.002

and disabling constraint #2, constraint #1 is still active and will still modify the visual transform of the object. According to our in-house animators, this is expected behaviour.

Diff Detail

Repository
rB Blender

Event Timeline

Sybren A. Stüvel (sybren) updated this revision to Diff 14714.
  • Shortened operator description by Dalai's request
  • Handle case where the context does not have a constraint attribute
Campbell Barton (campbellbarton) requested changes to this revision.Apr 14 2019, 2:30 PM

Works nicely.

This is nearly the same as 'Apply Visual Transform' - for both pose and object mode, then setting the influence to zero, nevertheless it's manual hassle and not so obvious.

release/scripts/startup/bl_operators/constraint.py
84–85

Single quotes reserved for enums.

96

The object could be pinned, if a constraint exists there is no need to check object/pose.

The execute function can access context.object which accounts for pinning, then get the pose bone from that if the properties view is showing pose constraints.

102

This isn't a reliable way to detect pose/object constraint, if this is only running in the properties space it could check view.context.

111–114

We should have a way to auto-key from Python (for operators that change transformation).

release/scripts/startup/bl_ui/properties_constraint.py
43–49

If this shows on all constraints the operator should support temporarily disabling constraints after the active one.

OTOH not sure this is a common use case?

This revision now requires changes to proceed.Apr 14 2019, 2:30 PM

This can use a better name, I took me a while to understand what this was doing.

"Disable Constraint and Keep Transformation" is consistent with clear parent and makes it clear it's not just about moving / translation.

release/scripts/startup/bl_operators/constraint.py
102

What is view in that case?

111–114

Yes, definitely. I talked with Bastien about this, and he said it required some more work in Blender's internals, so I left auto-keying out of the scope of this patch.

release/scripts/startup/bl_ui/properties_constraint.py
43–49

I think our animators generally only use a single constraint on any particular bone, but I don't know how our studio's workflow generalizes to Blender users in general. Also, it would be failry easy to construct a set of constraints that make it perfectly fine to use this operator on any constraint; for example, it would work fine when using on the middle or last constraint when you have 'copy translation; copy rotation; copy scale' as three separate constraints.

If this shows on all constraints the operator should support temporarily disabling constraints after the active one.

I'm not sure why you'd want to disable the constraints *after* the active one. It's the constraints *before* the active one that cause movement when you press the "disable without movement" button.

This can use a better name, I took me a while to understand what this was doing.
"Disable Constraint and Keep Transformation" is consistent with clear parent and makes it clear it's not just about moving / translation.

Sounds good to me. Users don't even see the name in the UI the way it's made now (so only when searching with F3), but a clearer name is always better.

  • Feedback from Campbell
  • Hide 'disable without moving' for certain constraint types
  • Renamed to 'Disable and Keep Transform'
  • Use context.space_data.context to determine bone/regular constraint
Sybren A. Stüvel (sybren) marked 5 inline comments as done.Apr 17 2019, 9:41 AM

I've noticed that the operator doesn't work well for IK and SPLINE_IK constraints. After all, applying those would require updating more than just the bone the constraint is defined on. To keep things simple, I've added some code to hide the button for those constraints.

All feedback has been incorporated into the code now.

Notes on supporting pinning.

release/scripts/startup/bl_operators/constraint.py
93

Shouldn't this be getattr(context, "constraint", None) ? - if the purpose is to prevent an exception when the context doesn't have a constraint (when poll is called from the operator search for eg).

100–102

This doesn't support pinning, using context.object instead of context.active_object to get the data which respects pinning. Then get the active pose-bone from the object.

release/scripts/startup/bl_operators/constraint.py
73

Can be Operator only since it's already imported.

74–82

Don't think there is a good reason to keep detailed comments on internal limitations in __doc__, can be made into normal code-comment for people who read the source.

release/scripts/startup/bl_operators/constraint.py
93

You're absolutely right -- not the first time I've been bitten by this inconsistency (dict.get('key') is a similar function, which does have an implicit None as 2nd parameter).

Sybren A. Stüvel (sybren) marked an inline comment as done.Apr 30 2019, 2:31 PM
Sybren A. Stüvel (sybren) added inline comments.
release/scripts/startup/bl_operators/constraint.py
100–102

How do you get the active pose-bone from the object? There is no mention of any active pose bone in the documentation for Object, Pose, or PoseBone.

  • Merge branch 'master' into temp-sybren-disable-constraint
  • Use getattr(…, …, None) to prevent AttributeError
  • Make the operator work with object pinning
Sybren A. Stüvel (sybren) marked 2 inline comments as done.May 7 2019, 2:15 PM
Sybren A. Stüvel (sybren) added inline comments.
release/scripts/startup/bl_operators/constraint.py
74–82

Given that an explicit bl_description is set, is there any downside to keeping the docstring this descriptive? When it comes to a description as to the behaviour of the function/class, I'm in favour of keeping it in the docstring (where it can be shown in an IDE as tooltip, or in generated documentation), rather than code comments.

  • Use Operator instead of bpy.types Operator
Sybren A. Stüvel (sybren) retitled this revision from Disable Constraint Without Moving to Disable Constraint and Keep Transform.May 7 2019, 2:18 PM
Sybren A. Stüvel (sybren) edited the summary of this revision. (Show Details)

Minor notes inline, otherwise fine.

release/scripts/startup/bl_operators/constraint.py
74–82

The down sides are there are two docstrings, it sets an odd precedent, if a developers sees only __doc__ they might miss out on information in bl_description - they can get out of sync... etc.

112

Should be context.object

This revision is now accepted and ready to land.May 8 2019, 6:40 AM
Sybren A. Stüvel (sybren) updated this revision to Diff 15201.
  • Final remarks by Campbell
Sybren A. Stüvel (sybren) marked 3 inline comments as done.May 8 2019, 10:55 AM
This revision was automatically updated to reflect the committed changes.