Bone won't deform mesh #59848

New Issue

pranavjit virdi · 2018-12-25T20:08:25+01:00

pranavjit virdi commented

2018-12-25 20:08:25 +01:00

System Information
Operating system: Win10_64
Graphics card: gtx1050ti

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

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:-
2018-12-26 00-20-42.flv

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

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:-
Characters1.blend
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:-
2018-12-26 00-30-41.flv

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.

**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:- [2018-12-26 00-20-42.flv](https://archive.blender.org/developer/F6068895/2018-12-26_00-20-42.flv) **Exact steps for others to reproduce the error** heres the .blend [Characters2.blend](https://archive.blender.org/developer/F6068918/Characters2.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:- [Characters1.blend](https://archive.blender.org/developer/F6068936/Characters1.blend) 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:- [2018-12-26 00-30-41.flv](https://archive.blender.org/developer/F6068961/2018-12-26_00-30-41.flv) 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.

pranavjit virdi commented

2018-12-25 20:08:25 +01:00

Added subscriber: @PranavjitVirdi

Sebastian Parborg commented

2018-12-27 15:18:46 +01:00

Added subscribers: @angavrilov, @ZedDB

Sebastian Parborg commented

2018-12-27 15:18:46 +01:00

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

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

I've create a very simple .blend for the issue: [bone_shrink.blend](https://archive.blender.org/developer/F6085977/bone_shrink.blend) @angavrilov I'm guessing this might be a known limitation. Or is this a dependency cycle that is not handled?

Jacques Lucke commented

2019-01-28 18:11:06 +01:00

Added subscribers: @Sergey, @JacquesLucke

Jacques Lucke commented

2019-01-28 18:11:06 +01:00

@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.

@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.

Alexander Gavrilov commented

2019-01-28 18:52:20 +01:00

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.

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.

Alexander Gavrilov commented

2019-01-28 18:57:26 +01:00

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.

Sergey Sharybin commented

2019-02-15 18:49:26 +01:00

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.

Alexander Gavrilov commented

2019-02-19 14:56:17 +01:00

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.

Sergey Sharybin commented

2019-02-19 15:11:13 +01:00

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.

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.

Alexander Gavrilov commented

2019-04-18 10:31:35 +02:00

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.

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.

blender-admin commented

2019-04-24 15:24:53 +02:00

This issue was referenced by 0470818411

This issue was referenced by 047081841113da73d7a13886218f5a56cfc62de6

Alexander Gavrilov was assigned by Sebastian Parborg

2019-04-25 10:33:44 +02:00

Sebastian Parborg commented

2019-04-25 10:33:44 +02:00

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

Alexander Gavrilov commented

2019-04-29 19:57:42 +02:00

Changed status from 'Open' to: 'Resolved'

Alexander Gavrilov closed this issue

2019-04-29 19:57:42 +02:00

Alexander Gavrilov commented

2019-04-29 19:59:31 +02:00

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.

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.

pranavjit virdi commented

2019-05-27 20:15:58 +02:00

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

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Bone won't deform mesh #59848