Bone custom shapes: 'Override Transform' - Updating it's pivot point after mesh deformation

This discussion/request is in the context of updating the facial rigging workflow in Blender for the upcoming Studio Project: ‘Kid’ Character Asset.
This workflow contains different mesh deformation methods like armature, shapekeys, lattice deforms and others in order to perform believable/flexible facial animation in Blender.

A big component of combining these deformations into a facial rig is using Control Bones to drive the deformations. To avoid the dependency cycle of driving a deformation with a Bone that’s constrained to vertices on that same deformed mesh, we now use ‘Override Transforms’. This is simply a ‘viewport display override’ that updates the visual position/rotation/scale based on the ‘Custom Object selected’ in the Bone Properties/Viewport Display.

IN SHORT: Override Transform doesn’t update Gizmo/Pivot point after additional deformation (in pose mode). It would be great if this actually was the case!

This display option allows us to ‘glue’ bones to a mesh and attach control bones to them, perfectly following any mesh deformations without creating dependency cycles. This is great for facial rigging, where complex skin deformations and the requirement of bones to be visible and following the skin accordingly.

Now the issue with this method though, is the pivot point (and therefore the gizmo) of the Control Bone (in pose mode). When additional deformations are manipulating the mesh, (e.g.: using a lattice or additional shapekeys) the position of the Control Bone will be updated, however the pivot point (and gizmo) will not be updated to it’s evaluated location. Therefore manipulating the Control Bone with it’s Override Transform will be counter intuitive and rather cumbersome, defying the purpose and benefits of the Override Transform functionality.

  • My request/design proposal would be to calculate the evaluated mesh data when additional deformers are influencing the mesh, therefore updating the Gizmo to it’s evaluated position. This way the animator can rely on the position of their Control Bones, no matter how many deformers are calculated on the mesh.

  • Additionally, it would be fantastic if it would be possible to assign the Override Transform to other objects than bones. Currently it’s only limited to assign them to bones, which is a bit inconvenient. Any object with transformation (empty, mesh, etc) should be able to be used as an Override Transform?

EDIT: I will add additional video/images soon.
EDIT2: Here’s the issue displayed in a video. The gizmo is staying in world space when using the Override Transform

6 Likes

I believe this makes sense.

If I understand correctly, you are not suggesting that the pivot of the bone is actually moved but rather the visual representation and input gizmos move with it.

I think that is possible and makes sense to try.
My only concern is that it will work well with translation, but rotation and scale will result in really weird behavior.

1 Like

Yes that makes sense. I wondered if something like the 3d cursor behaviour would be similar (using the 3d cursor as the pivot point) But generally, location is most important for this particular workflow since it’s aiming to only drive shapekeys.

What if the rotation and scaling was handled by having the widget scaled and rotated by the local scale and orient matrix of the original bone? kinda as if there was a local copy rotation/scale constain. That would make it feel like your actaully rotating the widget from its own origen.

1 Like

This could also be useful for the global/local workflow. Deforming the local rig with a bone, but having the widget following the mesh, without cycle.

Here is a little test of what if currently looks like, I might have missed something putting this together quickly, But I added a copy rotate and scale constain from the deforming bone to the visual bone:

Global to local

Translation still has the local axis from the original bone, which is weird when the parent of the visual bone is rotated. and the gizmos still point to the original origin as well.

1 Like

I love this proposal! Could it be possible to further improve the operator to allow override channels individually? I’ve personally run into cases before where it too would be good to only override location for example