Page MenuHome

Bone won't deform mesh
Closed, ResolvedPublic


System Information
Operating system: Win10_64
Graphics card: gtx1050ti

Blender Version
Broken: Blender 2.8, 2018-12-24, 6d89337257b6

Short description of error
My bone won't deform the part of the mesh that it is assigned, i have been sitting on this problem for days hoping for something to be wrong on my end but here we are. Video1:-

Exact steps for others to reproduce the error
heres the .blend

  1. go into pose mode and try to move Eye_L or Eye_R, i've checked to the best of my ability of something being done wrong on my end.

here's an earlier version of the same file:-

This one has the same setup for Eye_L but an incomplete setup for Eye_R, so the Eye_L one has the same problem as the file above but the Eye_R doesn't. Video2:-

I am guessing it has something to do with the fact that the child of this bone has a shrinkwrap modifier/bone constraint, since that is the only difference from what i've tested. Sorry for the 4mb video files. also sorry if this doesn't turn out to be a bug but n error on my part.

Event Timeline

Sebastian Parborg (zeddb) triaged this task as Confirmed, Medium priority.

I've create a very simple .blend for the issue:

@Alexander Gavrilov (angavrilov) I'm guessing this might be a known limitation. Or is this a dependency cycle that is not handled?

@Sergey Sharybin (sergey), should the depsgraph support this kind of dependency?

The final mesh depends on Bone Armature.bone1.
Armature.bone2 depends on final Mesh.

I don't think so.

Well, the problem here is that Armature modifier always depends on all bones, without taking the vertex groups into consideration at all. Thus to support this (very realistic and useful) use case, it is necessary to use a workaround:

Specifically, it's necessary to create a new armature that only contains the actually relevant bones, make them follow the main armature bones with Copy Transforms, and use that proxy armature for the modifier. This should decouple the dependency loop.

It could be useful to e.g. have a checkbox in the modifier to specifically limit the dependencies to relevant bones (it would be more expensive performance wise than depending on everything, but nowhere as much as a separate armature), but supporting that would likely require some careful refactoring of the modifier code.

While there are ways to support this in theory, we currently don't support such level of granularity. Longer term solution would be nodes i think, where it becomes more explicit what goes where.

How are nodes relevant? The problem here is the armature modifier depends on evaluation of the whole armature, instead of just the relevant bones (i.e. the set based on vertex group names). In the majority of cases that is correct, and probably more efficient (fewer graph links to process), but in some specific use cases it is a problem.

With nodes it's more clear to control what depends on what, without going all those "masking" things using groups or things like that.
Just more versatile solution, similar to shader nodes.

Nobody is going to like having to explicitly connect all bones in a rig to their mesh, if that's what you are trying to say. The Armature modifier with vertex weights already knows exactly which bones it actually needs from the vertex group list, but for coding convenience and depsgraph building efficiency it depends on the whole armature. There's also the cache thing, which is built at the armature level, but by this point only caches the double quats for non-bbones.

This issue would be resolved by either making the modifier always use the real dependencies, or adding an option to do that where needed to keep the possible performance benefits in the default case.

@Alexander Gavrilov (angavrilov) I'll go ahead and assign this to you as you have already posted a patch.

Now you can resolve the shrinkwrap dependency cycles in this test by deleting the unnecessary Pupil_L and Pupil_R vertex groups from the body mesh to let the modifier know that these bones aren't needed.

However it also has a silent cycle due to the head bone both being the target and a child of the IK chain. This leads to jitter and can be fixed by unparenting the bone.

HEllo!, just wanted to say Thanks a lot for fixing this! works like magic now.