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
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.
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.
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:
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.
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
If no-one’s working on it, I’ll try to take a jab at the first one sometime this week. I need to relearn the PR process. This is hopefully a good re-introduction into it.
(no audio)
Before I start the PR process, is this the desired behavior?
The transform gizmos use the bone’s custom transform only when the pivot is Individual Origins (other pivots are problematic as they can translate the owner bone during a rotation operation). The gizmo pivot is only calculated at the start of the transform operation.
This only applies when the armature is displaying custom shapes (see end of video, where I disable the toggle so the pivot goes back to traditional).
The rotation and scale origin is at the new gizmo pivot. This helps with getting the intuitive rotation direction (clockwise vs counter clockwise) based on the mouse-vs-gizmo_pivot position. (I believe this is what you wanted @jornboven )
I haven’t made a PR yet, but here’s the commit/branch if you wanna build it yourself and check that everything works as expected:
@Sebs Do you have a concrete example rig? Is it tedious to do already?- I think you can achieve it with a CopyRotation on the custom xform bone that copies the original/owner’s rotation. Let me know if I’m missing something.
Sure, then I could match the PR’s example video with the new behavior. I looked at a handful of my downloaded rigs and none of them had custom shape transforms, including Blender Cloud Mikassa and Spring. So, Suzanne it was. Though, feel free to make a short example video yourself. I’ve never done face rigging nor face animation, so you would demo it better than I can.
I have had trouble building the branch here, would it be possible to make it a PR? That way it’s somewhat more convenient for me to test your build. The behavior seems to be correct, I wanna try it myself to see if it works on my facial rig setup, and if there’s a way to adjust the scale and rotation pivot by using the 3d cursor as a temporary pivot.
Gizmo behavior when using the 3d cursor as the pivot is the same as before. The new behavior only applies when you’re using Individual Origins as the pivot. I can update it for 3d cursor (and others by that point), but you’ll have to explain what the expected behavior is. What should happen when the 3d cursor is located at the origin of an xform override? What should happen if it’s not exactly there but offset a little? What happens if a mixture of bones with/without xform overrides are xformed together (both rotated and translated simultaneously)?
For the pull request and testing the build, i’ve replied there :). For the 3d Cursor, I’ve not been clear enough, apologies. For now the 3d cursor is behaving as expected, so no need to adjust the behavior of this.
@GuiltyGhost here’s an example of when we ran into this limitation at our studio, we had to work-around by using CopyRotation on another bone to get the updated visual, where it would’ve been useful to not override the widget’s rotation in this case
! Should be fine 
