Maniphest T48231

Constraint influence driven by bone doesn't work.
Closed, Archived
Actions

Assigned To
Sergey Sharybin (sergey)
Authored By
Mario Mey (mariomey)
Apr 21 2016, 9:09 PM
Tags
  • Game Animation
  • Game Engine
Subscribers
Mario Mey (mariomey)
Sergey Sharybin (sergey)

Description

System Information
Linux, Ubuntu-Mate 14.04, nVidia GT620

Blender Version
Broken: 2.77 (from page)

Short description of error
There's a bone with Action Constraint that its influence is driven by another bone. In normal play (Alt-A), the constraint is well driven (it goes to 0). But when entering in game engine, it doesn't do the same, the Influence is still at 1.

Exact steps for others to reproduce the error
Open the file, play the animation with Alt-A
Enter in BGE, the animation plays automatically.
Compare the movement of the bone "B" in both situations.

Here I use Action constraint, but I think that this happens also in other constraints.

90-action-const-influence.blend1 MBDownload

Related Objects

Event Timeline

Mario Mey (mariomey) created this task.Apr 21 2016, 9:09 PM
Mario Mey (mariomey) raised the priority of this task from to 90.
Mario Mey (mariomey) updated the task description.
Mario Mey (mariomey) added a project: Game Animation.
Mario Mey (mariomey) edited a custom field.
Mario Mey (mariomey) added a subscriber: Mario Mey (mariomey).
Mario Mey (mariomey) added a comment.Apr 21 2016, 9:21 PM

Maybe this is an oooold known system limitation... that I reported in 2010 (T22850)?

If yes... I'm really sorry, delete this report now!

Aaron Carlisle (Blendify) added a project: Game Engine.Apr 21 2016, 10:38 PM
Sergey Sharybin (sergey) changed the task status from Unknown Status to Unknown Status.Apr 22 2016, 6:17 PM
Sergey Sharybin (sergey) claimed this task.
Sergey Sharybin (sergey) added a subscriber: Sergey Sharybin (sergey).

You can not use a bone to drive something inside of the same armature, it's unsupported by the current dependency graph. We're working on solving limitations like that in a new system.

So thanks for the report, but it's not a bug.

Mario Mey (mariomey) added a comment.Apr 22 2016, 6:47 PM

@Sergey Sharybin (sergey), are you talking about Blender or the Game Engine?

Sergey Sharybin (sergey) added a comment.Apr 25 2016, 10:44 AM

Those behave in a similar way.

Mario Mey (mariomey) added a comment.Apr 25 2016, 9:02 PM

@Sergey Sharybin (sergey), why do you say that we can't drive something inside of the same armature? The file I uploaded here does not work in BGE, but it does in Blender (and shows no error messages).

That's why I asked you if you were talking about Blender or BGE.

Sergey Sharybin (sergey) added a comment.Apr 26 2016, 9:55 AM

I say that because i know how current dependency graph and pose solver works, apparently.

The issue here is that with current dependency graph pose bones gets sorted for evaluation based on their parent and constraint targets, without taking drivers into account. In fact, currently drivers are only evaluated once per all bones. This makes it so your armature might or might not be updated correct. It all depends on memory addresses and phase of the Moon. It's really something you can't predict.

Proper thing to do here is to sort bones for evaluation based on all drivers, constraint targets etc etc. it's something we do in the new dependency graph (enabled with --enable-new-depsgraph command line argument). However, new depsgraph is not fully finished and not hooked up to all the subsystems and some more work needed there.

Mario Mey (mariomey) added a comment.Apr 26 2016, 8:29 PM

When I just finished writing the report, I realized that I reported the same issue 5 years ago. Because of this, I forgot to say that when I did this file, I was using the new depsgraph (*). And yes, as I said in the report (and you deducted), with new depsgraph, this configuration does work...

But it does in Blender, not in BGE. Is there any plan to make it work also in Game Engine?

Understanding that this is the way the current depsgraph works and having in mind that the new one is still in development, we can close this report.

Thank you.

(*) I'm working with new-depsgraph for some time because it fixes some dependencies cycles that I had in my files. Also, I want to test it (I've already reported some bugs about this).