Maniphest T48234

Bone Action Constraints with shared Action leads to glitches
Closed, Resolved
Actions

Assigned To
None
Authored By
Paul R (intracube)
Apr 22 2016, 4:49 AM
Tags
  • BF Blender
  • Animation & Rigging
Subscribers
Bastien Montagne (mont29)
Campbell Barton (campbellbarton)
Paul R (intracube)
Sergey Sharybin (sergey)

Description

System Information
Suse Leap 42.1
NVidia GTX 560ti (official drivers)

Blender Version
Broken: 2.77a
Worked: -

Short description of error
If Bone Action Constraints are assigned to bones in different armatures and all share the same Action, the animation will usually glitch if two or more targets are moved at the same time. Affects view-port and final renders.

Example video:
https://www.youtube.com/watch?v=uYD3E5xaJag&t=41

Exact steps for others to reproduce the error

  • open .blend
    blender_bone_action_constraints_bug.blend88 KBDownload
  • select all Empties
  • move slowly along Z axis
  • bone animations will glitch

Workaround

  • create copies of the original Action - one for each bone/constraint (looks like Blender might be caching the Action positions?)

Revisions and Commits

rB Blender
rBc6cc59931189 Fix T48234: Glitch w/ action constraints sharing an action

Related Objects

Event Timeline

Paul R (intracube) created this task.Apr 22 2016, 4:49 AM
Paul R (intracube) raised the priority of this task from to 90.
Paul R (intracube) updated the task description.
Paul R (intracube) added projects: BF Blender, Animation & Rigging.
Paul R (intracube) edited a custom field.
Paul R (intracube) added a subscriber: Paul R (intracube).
Bastien Montagne (mont29) lowered the priority of this task from 90 to 50.Apr 22 2016, 1:06 PM
Bastien Montagne (mont29) added subscribers: Sergey Sharybin (sergey), Bastien Montagne (mont29).

This is a threading issue (running Blender mono-threaded, with -t 1 command line option, shows no problem). We are evaluating the same action in parallel for different frames, fiddling with its update flags, etc. No good.

@Sergey Sharybin (sergey) from quick look, think we can either:

  • Lock around action evaluation itself (last part of what_does_obaction(), or maybe even in constraint exec itself).
  • Make temp copy of action for its evaluation (but would expect this to be overkilling?).
  • Change depsgraph to check this situation??? Doubt this is really doable or desired though.

First solution sounds simpler one to me, but likely not the optimal one…

Paul R (intracube) added a comment.May 7 2016, 12:40 PM
In T48234#371151, @Bastien Montagne (mont29) wrote:

This is a threading issue (running Blender mono-threaded, with -t 1 command line option, shows no problem).

Ah, thanks.

Can confirm that -t 1 fixes the issue with all my armature/constraint setups.

Campbell Barton (campbellbarton) added a subscriber: Campbell Barton (campbellbarton).EditedJun 3 2016, 10:25 AM

We could move away from using FCurve.curval.
This patch fixes the bug for me: P364

... just makes some local changes to avoid using FCurve.curval.

Campbell Barton (campbellbarton) changed the task status from Unknown Status to Resolved by committing rBc6cc59931189: Fix T48234: Glitch w/ action constraints sharing an action.Jun 3 2016, 4:57 PM
Campbell Barton (campbellbarton) added a commit: rBc6cc59931189: Fix T48234: Glitch w/ action constraints sharing an action.
Paul R (intracube) added a comment.Jun 15 2016, 3:04 PM

It's now working as expected. Thanks for the fix!