Mesh-based armature interaction ("Mesh Gizmos", "Face Maps") #92218

New Issue

Preface

The current way of interacting with bones in a production environment is based on Custom Shape Objects, which can disappear inside the mesh, be at a completely different place from the area they control, and in general require a fair bit of design from the rigger and learning from the animator to efficiently use.

Using the Python Gizmo API, I created a prototype of an alternative system, where we can click on geometry on the deformed mesh itself to select bones and control said mesh.

The goals of this task are:

Gather feedback from animators and riggers.
Finalize a design, to the extent that is possible within the limitations of a Python prototype.
Find developers who could implement this in core Blender.

The Prototype: "Bone Gizmos" add-on

Video: Setting up a single bone gizmo
Video: The add-on in use

You can download the addon as part of the Blender Studio Pipeline. You have to download the whole repository from the repo's home page, then extract the bone_gizmos folder into your addons folder.

Features

A list of proposed features, partially working in the prototype, although there is plenty of space for UX discussions.

A gizmo's shape can be:
- An entire object (in the bone's local space, with the already existing transform offset options applied)
- A vertex group/face map/any attribute of an object (in world space).
Gizmo Colors:
- There are three states to worry about: Unselected, selected, hovered.
- Currently, user can specify two colors: Unselected and Selected. Hover-state is indicated by opacity ONLY. Having only one color, or three colors, is something to discuss.
- The colors can be taken from the bone group's colors, if the bone has a group assigned, or set uniquely on a per-bone basis.
- Colors should actually NOT be this customizable. Instead, users should be forced into a set of pre-defined colors, that can only be customized at the Theme level.
Gizmo Display:
- A gizmo's visibility is based on the bone's visibility; From user POV, a bone and its gizmo should be a single entity.
- If the selected object/vertex group cannot be used to construct any faces, draw the edges with line drawing instead.
Interaction:
- Since it's just a prototype, it's currently left-click only, and doesn't account for mouse drag threshold, which is very bad for auto-keying. In the final implementation, it should behave the same way as bones do now, except:
- Default transform mode: Translate/Rotate/Scale, including trackball rotation, rotating along view, and locking any transformation to 1 or 2 axes. These defaults are defined by the rigger on a per-bone basis, and can be bypassed by the animator with a button press, or in a nuclear fashion by disbaling them altogether as a user preference.
- Snapping: It is possible, only through Python, to specify an operator name and parameters that should be executed when a gizmo is touched. This can be used for automatic IK/FK snapping. But it would need an interface similar to a Keymap entry, where we can pick an operator and feed it parameters.

Design Questions:
While making the prototype, I ran into some design questions where the answers aren't so simple:

Ways to minimize set-up time? Currently, each gizmo needs a vertex group. That's fine, but may need workflow operators to quickly switch from Pose Mode to Edit Mode on the relevant mesh.
How to avoid overlapping gizmos? I think there are cases where they might be necessary, and a system that allows the rigger to create bone layers that are mutually exclusive, would be a potential solution.
If there is more than one way to deform some geometry (eg.: Shape Key, Armature, Lattice), how to communicate which out of several potential controls was used to achieve the current shape?

There might be no perfect answer to all of these, but they are things to keep in mind and mitigate.

Prototype Limitations

These issues are listed just to clarify that these behaviours are known, and would most likely be easy to fix/avoid in the final implementation, but can't really be addressed in the prototype:

- Mouse hovering does not take depth into account. This was fixed! [#94794]
Visual depth culling stops working when gizmo is being hovered. [#94792]
Transparent lines appear between the triangles. [#94791]
Currently the mouse movement threshold user preference is not being taken into account, which is terrible when trying to use the system with auto-keying enabled.
Performance is poor; Grabbing the vertex positions from the evaluated mesh takes about 2ms per gizmo.
Interaction is always with left click and cannot be customized.
Gizmo can not be visible during interaction.
When the mesh is modified, user must press a Refresh button to synchronize the gizmos.
Renaming bones will leave a gizmo orphaned, don't do it! :D

Feedback and discussion welcome! Also about how to structure this document.

# Preface The current way of interacting with bones in a production environment is based on Custom Shape Objects, which can disappear inside the mesh, be at a completely different place from the area they control, and in general require a fair bit of design from the rigger and learning from the animator to efficiently use. Using the Python Gizmo API, I created a prototype of an alternative system, where we can click on geometry on the deformed mesh itself to select bones and control said mesh. The goals of this task are: - Gather feedback from animators and riggers. - Finalize a design, to the extent that is possible within the limitations of a Python prototype. - Find developers who could implement this in core Blender. ### The Prototype: "Bone Gizmos" add-on [Video: Setting up a single bone gizmo](/attachments/56001974-6438-45ed-88ce-ce85a06ba413) [Video: The add-on in use](/attachments/0417c11e-e659-4e9f-b3ff-162d67f0be69) You can [download the addon](https://projects.blender.org/studio/blender-studio-pipeline/src/branch/main/scripts-blender/addons/bone_gizmos) as part of the Blender Studio Pipeline. You have to download the whole repository from the repo's home page, then extract the `bone_gizmos` folder into your addons folder. ### Features A list of proposed features, partially working in the prototype, although there is plenty of space for UX discussions. - A gizmo's shape can be: - An entire object (in the bone's local space, with the already existing transform offset options applied) - A vertex group/face map/any attribute of an object (in world space). - Gizmo Colors: - There are three states to worry about: Unselected, selected, hovered. - Currently, user can specify two colors: Unselected and Selected. Hover-state is indicated by opacity ONLY. Having only one color, or three colors, is something to discuss. - The colors can be taken from the bone group's colors, if the bone has a group assigned, or set uniquely on a per-bone basis. - Colors should actually NOT be this customizable. Instead, users should be forced into a set of pre-defined colors, that can only be customized at the Theme level. - Gizmo Display: - A gizmo's visibility is based on the bone's visibility; From user POV, a bone and its gizmo should be a single entity. - If the selected object/vertex group cannot be used to construct any faces, draw the edges with line drawing instead. - Interaction: - Since it's just a prototype, it's currently left-click only, and doesn't account for mouse drag threshold, which is very bad for auto-keying. In the final implementation, it should behave the same way as bones do now, except: - Default transform mode: Translate/Rotate/Scale, including trackball rotation, rotating along view, and locking any transformation to 1 or 2 axes. These defaults are defined by the rigger on a per-bone basis, and can be bypassed by the animator with a button press, or in a nuclear fashion by disbaling them altogether as a user preference. - Snapping: It is possible, only through Python, to specify an operator name and parameters that should be executed when a gizmo is touched. This can be used for automatic IK/FK snapping. But it would need an interface similar to a Keymap entry, where we can pick an operator and feed it parameters. **Design Questions**: While making the prototype, I ran into some design questions where the answers aren't so simple: - Ways to minimize set-up time? Currently, each gizmo needs a vertex group. That's fine, but may need workflow operators to quickly switch from Pose Mode to Edit Mode on the relevant mesh. - How to avoid overlapping gizmos? I think there are cases where they might be necessary, and a system that allows the rigger to create bone layers that are mutually exclusive, would be a potential solution. - If there is more than one way to deform some geometry (eg.: Shape Key, Armature, Lattice), how to communicate which out of several potential controls was used to achieve the current shape? There might be no perfect answer to all of these, but they are things to keep in mind and mitigate. ### Prototype Limitations These issues are listed just to clarify that these behaviours are known, and would most likely be easy to fix/avoid in the final implementation, but can't really be addressed in the prototype: - - [ ] Mouse hovering does not take depth into account. This was fixed! [#94794] - Visual depth culling stops working when gizmo is being hovered. [#94792] - Transparent lines appear between the triangles. [#94791] - Currently the mouse movement threshold user preference is not being taken into account, which is terrible when trying to use the system with auto-keying enabled. - Performance is poor; Grabbing the vertex positions from the evaluated mesh takes about 2ms per gizmo. - Interaction is always with left click and cannot be customized. - Gizmo can not be visible during interaction. - When the mesh is modified, user must press a Refresh button to synchronize the gizmos. - Renaming bones will leave a gizmo orphaned, don't do it! :D Feedback and discussion welcome! Also about how to structure this document.

2022-11-23_14-33-44.mp4

3.3 MiB

bone_gizmos-2021-10-14_15.35.48.mp4

9.7 MiB

Added subscriber: @Mets

Changed status from 'Needs Triage' to: 'Confirmed'

Added subscriber: @LucianoMunoz

Added subscriber: @AndyCuccaro

Added subscriber: @GeorgiaPacific

Added subscriber: @Phigon

Added subscriber: @MaybeLamia

Added subscriber: @PaoloAcampora

Added subscriber: @L0Lock

Added subscriber: @RomboutVersluijs

This looks like tha initial FaceMap idea, what happened to that?

I believe the initial setup was made to "be left to others".
Or rather, specifically the Face attribute/python-property was for that, and the selector thing (like here) was meant to just be a proof of concept, which either succeeded or was abandoned. If the goal was to just show it was possible/an example, it succeeded; if the goal was to have a basic practical/functional version, it was abandoned.

I believe the initial setup was made to "be left to others". Or rather, specifically the Face attribute/python-property was for that, and the selector thing (like here) was meant to just be a proof of concept, which either succeeded or was abandoned. If the goal was to just show it was possible/an example, it succeeded; if the goal was to have a basic practical/functional version, it was abandoned.

Added subscriber: @HooglyBoogly

I wasn't around when face maps were added, but everything I've seen makes me think that they should just be a generic integer attribute rather than a special thing with yet another list in mesh properties and its own operators, etc.

To make that work, I think we would just have to support assigning values to attributes in edit mode, which is something we have planned anyway.

I wasn't around when face maps were added, but everything I've seen makes me think that they should just be a generic integer attribute rather than a special thing with yet another list in mesh properties and its own operators, etc. To make that work, I think we would just have to support assigning values to attributes in edit mode, which is something we have planned anyway.

Just looked at face maps again and that earlier proposal seems to work out of the box by itself. This approach needs a user to set it up manual, if i understood the other one correct. Both seem to have the same goal.

In #92218#1251473, @RomboutVersluijs wrote:
Just looked at face maps again and that earlier proposal seems to work out of the box by itself. This approach needs a user to set it up manual, if i understood the other one correct. Both seem to have the same goal.

The way I read your post is: "The first addon already works as-is, and this just does the same thing but with more steps".

So I was wondering if maybe the addon was updated since I last tried it, and/or I was just completely using it wrong and misremembering it.
I wasn't. I forgot the exact problems but remembered correctly that it's not practical for usage......and crashes Blender. #51675 is that development page.

My problems started with it is there not being an automated way to transfer bone-vertex groups to face maps, and before I would bother creating a script/addon to do that, I would need to verify that I would use it.
Then I find out it only works in object mode, it doesn't register an undo, and the only method of interaction is click-drag, set to Translation and only does Rotation/Scale if the Location then Rotation is locked on the bone.
Then after getting tripped up with the undo and entering the rig to clear the transforms, soon Blender crashes.
It looks great to finally be able to pose bones by just selecting the mesh itself, and without using the slow Mask Modifier method but too instable and impractical to be used right now.

That's my current thoughts and it's my same thoughts from back in 2.80.

Relooking into it, apparently there were design decisions being discussed about making this possible, and then the dev decided to just make the addon as a proof-of-concept (as stated in the addon's warning), and that was the end of it; and that this was a little over 3 years ago. There was later another page #54989 about this stuff but supposedly it's aim was slightly different, and also 3 years ago. I didn't hear about that until today, and last info on that was it would also be scrapped, last year.

I have high hopes that this time it will get done, all the way, one way or another.

> In #92218#1251473, @RomboutVersluijs wrote: > Just looked at face maps again and that earlier proposal seems to work out of the box by itself. This approach needs a user to set it up manual, if i understood the other one correct. Both seem to have the same goal. The way I read your post is: "The first addon already works as-is, and this just does the same thing but with more steps". So I was wondering if maybe the addon was updated since I last tried it, and/or I was just completely using it wrong and misremembering it. I wasn't. I forgot the exact problems but remembered correctly that it's not practical for usage......and crashes Blender. #51675 is that development page. My problems started with it is there not being an automated way to transfer bone-vertex groups to face maps, and before I would bother creating a script/addon to do that, I would need to verify that I would use it. Then I find out it only works in object mode, it doesn't register an undo, and the only method of interaction is click-drag, set to Translation and only does Rotation/Scale if the Location then Rotation is locked on the bone. Then after getting tripped up with the undo and entering the rig to clear the transforms, soon Blender crashes. It looks great to finally be able to pose bones by just selecting the mesh itself, and without using the slow Mask Modifier method but too instable and impractical to be used right now. That's my current thoughts and it's my same thoughts from back in 2.80. Relooking into it, apparently there were design decisions being discussed about making this possible, and then the dev decided to just make the addon as a proof-of-concept (as stated in the addon's warning), and that was the end of it; and that this was a little over 3 years ago. There was later another page #54989 about this stuff but supposedly it's aim was slightly different, and also 3 years ago. I didn't hear about that until today, and last info on that was it would also be scrapped, last year. I have high hopes that this time it will get done, all the way, one way or another.

In #92218#1251400, @HooglyBoogly wrote:
I wasn't around when face maps were added, but everything I've seen makes me think that they should just be a generic integer attribute rather than a special thing with yet another list in mesh properties and its own operators, etc.

The downsides of vertex groups are:

When selecting 3 vertices on a quad, it will draw a triangle, since it doesn't know that there's no edge on the diagonal. Not a big problem, and could probably be avoided by smarter code.
One face can only be assigned to 1 face map, just like materials. This kind of makes sense for mesh-based selection, but I think it might be useful to assign one face to multiple selection widgets, when trying to achieve a layered system (Although this would work best if we could have groups of mutually exclusive layers, which we don't).
So I agree, the justification for the existence of Face Maps doesn't look too good.

In #92218#1251475, @Phigon wrote:
#51675 is that development page.
There was later another page #54989 about this stuff but supposedly it's aim was slightly different, and also 3 years ago
I have high hopes that this time it will get done, all the way, one way or another.

I didn't know about those threads, so thanks for digging them up! Indeed, both seem fairly abandoned, so you can consider this a revival of those. A lot of the ideas and the conclusions that people came to in those threads seem to align with what I did in the prototype addon, so that's lucky!

Apparently Ton wanted things to work in Object mode. The LilyGizmos addon does a fantastic job of this already, but I would consider this a separate system:
Gizmos for sliding floats != Gizmos for interacting with bones.

> In #92218#1251400, @HooglyBoogly wrote: > I wasn't around when face maps were added, but everything I've seen makes me think that they should just be a generic integer attribute rather than a special thing with yet another list in mesh properties and its own operators, etc. The downsides of vertex groups are: - When selecting 3 vertices on a quad, it will draw a triangle, since it doesn't know that there's no edge on the diagonal. Not a big problem, and could probably be avoided by smarter code. - One face can only be assigned to 1 face map, just like materials. This *kind of* makes sense for mesh-based selection, but I think it might be useful to assign one face to multiple selection widgets, when trying to achieve a layered system (Although this would work best if we could have groups of mutually exclusive layers, which we don't). So I agree, the justification for the existence of Face Maps doesn't look too good. > In #92218#1251475, @Phigon wrote: > #51675 is that development page. > There was later another page #54989 about this stuff but supposedly it's aim was slightly different, and also 3 years ago > I have high hopes that this time it will get done, all the way, one way or another. I didn't know about those threads, so thanks for digging them up! Indeed, both seem fairly abandoned, so you can consider this a revival of those. A lot of the ideas and the conclusions that people came to in those threads seem to align with what I did in the prototype addon, so that's lucky! Apparently Ton wanted things to work in Object mode. The [LilyGizmos](https://blendermarket.com/products/lily-gizmos) addon does a fantastic job of this already, but I would consider this a separate system: Gizmos for sliding floats __**!=**__ Gizmos for interacting with bones.

Added subscriber: @ErickNyanduKabongo

Added subscriber: @Capitanblue89

Added subscriber: @Mamoun88

Removed subscriber: @Mamoun88

Added subscriber: @rwman

Added subscriber: @Jeroen-Bakker

Added subscriber: @g-lul

Added subscriber: @jeremybep

Added subscriber: @wevon-2

Just a couple of ideas.
If the preselection were gradual as the cursor approaches the Face Maps, this could be done by progressively illuminating the contour of the Face Maps until the cursor is over the face group and the faces are already illuminated, in this way I think that The Christmas tree effect would be avoided.
Second, Vertex Maps could also be used to animate details. In the same way, when approaching the cursor to the vertex sets they could gain opacity.

I have made a video with a non-real face, to show the effect that could be produced when moving the cursor closer to certain vertices or edges. It is less blinking than with faces, although in a way everything is complementary.
kk300.mp4

Just a couple of ideas. If the preselection were gradual as the cursor approaches the Face Maps, this could be done by progressively illuminating the contour of the Face Maps until the cursor is over the face group and the faces are already illuminated, in this way I think that The Christmas tree effect would be avoided. Second, Vertex Maps could also be used to animate details. In the same way, when approaching the cursor to the vertex sets they could gain opacity. ![FaceMaps.png](https://archive.blender.org/developer/F12772253/FaceMaps.png) I have made a video with a non-real face, to show the effect that could be produced when moving the cursor closer to certain vertices or edges. It is less blinking than with faces, although in a way everything is complementary. [kk300.mp4](https://archive.blender.org/developer/F12780423/kk300.mp4)

Added subscriber: @pauanyu_blender

Added subscriber: @ArtemBataev

Added subscriber: @JohanTriHandoyo

Love the idea. I think this will avoid cluttered in rig and keep only the nearest and necessary controller visible at the same time +1

In #92218#1277276, @wevon-2 wrote:
Just a couple of ideas.
If the preselection were gradual as the cursor approaches the Face Maps, this could be done by progressively illuminating the contour of the Face Maps until the cursor is over the face group and the faces are already illuminated, in this way I think that The Christmas tree effect would be avoided.
Second, Vertex Maps could also be used to animate details. In the same way, when approaching the cursor to the vertex sets they could gain opacity.

I have made a video with a non-real face, to show the effect that could be produced when moving the cursor closer to certain vertices or edges. It is less blinking than with faces, although in a way everything is complementary.
kk300.mp4

Love the idea. I think this will avoid cluttered in rig and keep only the nearest and necessary controller visible at the same time +1 > In #92218#1277276, @wevon-2 wrote: > Just a couple of ideas. > If the preselection were gradual as the cursor approaches the Face Maps, this could be done by progressively illuminating the contour of the Face Maps until the cursor is over the face group and the faces are already illuminated, in this way I think that The Christmas tree effect would be avoided. > Second, Vertex Maps could also be used to animate details. In the same way, when approaching the cursor to the vertex sets they could gain opacity. > ![FaceMaps.png](https://archive.blender.org/developer/F12772253/FaceMaps.png) > > I have made a video with a non-real face, to show the effect that could be produced when moving the cursor closer to certain vertices or edges. It is less blinking than with faces, although in a way everything is complementary. > [kk300.mp4](https://archive.blender.org/developer/F12780423/kk300.mp4)

Added subscriber: @RedMser

Added subscriber: @Commander-Mustard

Added subscriber: @Richard-Lee

Added subscriber: @zNight

I've made some tweaks to the add-on, added a new video about how to set up a single bone gizmo, and re-structured the task description. I think it's clear to me now that this task shouldn't be about improving the Python Gizmo API (although that is still welcome). Instead, mesh gizmos NEED to be a core Blender feature to have a chance to shine, especially due to performance. So the task has been re-focused to present the add-on purely as a prototype/testing ground of a potential future system.

I would like to bring this up in a module meeting soon, and try to figure out what could be the next step from here and when that would be done and by whom. I think my main question will be this:
Do we do more in-depth design discussions and testing with this, or is this already good enough to throw a developer at it to come up with a technical roadmap or just really go ham and implement a better prototype in C/C++, and iterate from there?

I've made some tweaks to the add-on, added a new video about how to set up a single bone gizmo, and re-structured the task description. I think it's clear to me now that this task shouldn't be about improving the Python Gizmo API (although that is still welcome). Instead, mesh gizmos NEED to be a core Blender feature to have a chance to shine, especially due to performance. So the task has been re-focused to present the add-on purely as a prototype/testing ground of a potential future system. I would like to bring this up in a module meeting soon, and try to figure out what could be the next step from here and when that would be done and by whom. I think my main question will be this: Do we do more in-depth design discussions and testing with this, or is this already good enough to throw a developer at it to come up with a technical roadmap or just really go ham and implement a better prototype in C/C++, and iterate from there?

Added subscriber: @Nika-Kutsniashvili

Added subscriber: @leriaz

Yo @Mets How this project is going? You had some questions that it seems like there is no answer?

Added subscriber: @Zophiekat

i think it would be cool if we had more control over visibility, like having per bone options for disabling highlight blinking, per bone xray visiblity, and gizmo outline

Do you plan to work on this add-on until this becomes Blender feature (if ever)? It is amazing but has some bugs. And could there be a way to automatically select corresponding vertex group for all bones, and hence display it on all bones at once?

I'm currently not getting any interest from either my team of animators or any developers, to work on this further, either as a usable add-on or as a prototype for a core Blender feature.

I think as a prototype it already works okay, but until there is a developer who wants to and is able to and is available to implement it in core Blender, this will continue collecting dust in my backlog.

But still, if you find bugs that aren't listed under the "Prototype Limitations" paragraph in the post, feel free to describe them, I would be curious and might get around to fixing them sometime.

I'm currently not getting any interest from either my team of animators or any developers, to work on this further, either as a usable add-on or as a prototype for a core Blender feature. I think as a prototype it already works okay, but until there is a developer who wants to and is able to and is available to implement it in core Blender, this will continue collecting dust in my backlog. But still, if you find bugs that aren't listed under the "Prototype Limitations" paragraph in the post, feel free to describe them, I would be curious and might get around to fixing them sometime.

That is an absolute shame. This is one of the most anticipated feature in Blender. Literally every blender video on YouTube about future of animation includes your video. People are hyped and its a shame if we'll be left disappointed. Shows the gap in priorities between developers and artists in the community.

I would advise you to upload the addon on GitHub, GumRoad or someplace else and spread the word about it a little, post it on blenderartists. Very few know that they can already have this feature. If developers don't appreciate it community will.

As for the bugs, two I noticed is that parts of the mesh (in forms of triangles) are sometimes visible through highlight. I guess offset option could be used to fix that.
And second is that updating colors in the panel doesn't update automatically in the viewport. I need to change line thickness in the add-on settings for it to update.

That is an absolute shame. This is one of the most anticipated feature in Blender. Literally every blender video on YouTube about future of animation includes your video. People are hyped and its a shame if we'll be left disappointed. Shows the gap in priorities between developers and artists in the community. I would advise you to upload the addon on GitHub, GumRoad or someplace else and spread the word about it a little, post it on blenderartists. Very few know that they can already have this feature. If developers don't appreciate it community will. As for the bugs, two I noticed is that parts of the mesh (in forms of triangles) are sometimes visible through highlight. I guess offset option could be used to fix that. And second is that updating colors in the panel doesn't update automatically in the viewport. I need to change line thickness in the add-on settings for it to update.

Added subscriber: @BClark

Well I wouldn't say it isn't getting any interest, it is part of the main animation push, improving selection and mesh based selection possibly. I didn't know it was already this far along and so I just shared it back and will remind people in the Animation Module this exists. No timeline or promises but feedback on a working prototype would be great for moving it into core of Blender.

Added subscriber: @JasonSchleifer

I agree with Brad - it's definitely got interest! I'm super interested in it! Let's set up a session to talk about it & give you feedback!

I still cannot figure out how to install it. I have a folder on my computer with the 7 .py files and placed it in my add on folders. That did not work. The directions "just extract the files into your Blender add ons folder" does not explain how to get the bone_gizmos folder from github! PLEASE HELP!!! What am I doing wrong? I wish I could just download a zip and put it in my add ons in preferences like all other add ons. Can someone please show me how to download the file ? Any help is super appreciated. Thanks.

Hi, I have am adding bone_gizmos to Expy Kit, my add-on for quick character setup. If you want to try it, please download and install the attached add-on: it's an early test but it seems to work:

Expy-Kit-expy_gizmos_0122.zip
https://github.com/pKrime/Expy-Kit/tree/expy_gizmos

If you are using Rigify, then in Pose Mode:

Right Click (or W), to open the context menu
From the Controls menu, select Setup Gizmos from ExpyKit
Pick Rigify Controls in the parameters on the left-botton corners

Here's an instant setup on SF-girl, a CC-by model by Stan that I downloaded from sketchfab
https://sketchfab.com/3d-models/sf-girl-a219070284e64ddd8a51f69c207cc81b
https://sketchfab.com/Stas_SayHallo

Expy_Pizmo_Example.mp4

Expy Kit supports other humanoid rigs, like Unreal Mannequin and Mixamo. If you are using a non supported rig, you can still set up your own, more info in my videos (sorry, no manual yet)

https://youtu.be/auTkEEK6Dmo

if you have installed @Mets's original add-on from the Blender Studio Tools it must be disabled or removed: Expy Kit contains a copy of it and there is no compatibility at the moment.

I have also noticed a weird offset in blender 3.2, not sure where it comes from.

enjoy!

Hi, I have am adding bone_gizmos to Expy Kit, my add-on for quick character setup. If you want to try it, please download and install the attached add-on: it's an early test but it seems to work: [Expy-Kit-expy_gizmos_0122.zip](https://archive.blender.org/developer/F14185320/Expy-Kit-expy_gizmos_0122.zip) https://github.com/pKrime/Expy-Kit/tree/expy_gizmos If you are using Rigify, then in Pose Mode: - *Right Click* (or *W*), to open the context menu - From the **Controls menu**, select **Setup Gizmos from ExpyKit** - Pick **Rigify Controls** in the parameters on the left-botton corners Here's an instant setup on SF-girl, a CC-by model by Stan that I downloaded from sketchfab https://sketchfab.com/3d-models/sf-girl-a219070284e64ddd8a51f69c207cc81b https://sketchfab.com/Stas_SayHallo [Expy_Pizmo_Example.mp4](https://archive.blender.org/developer/F14185328/Expy_Pizmo_Example.mp4) Expy Kit supports other humanoid rigs, like Unreal Mannequin and Mixamo. If you are using a non supported rig, you can still set up your own, more info in my videos (sorry, no manual yet) https://youtu.be/auTkEEK6Dmo if you have installed @Mets's original add-on from the Blender Studio Tools it must be disabled or removed: Expy Kit contains a copy of it and there is no compatibility at the moment. I have also noticed a weird offset in blender 3.2, not sure where it comes from. enjoy!

Added subscriber: @AdamEarle

I know I'm giving away my trade secrets here, so here it is. If you expose the vertex matrix so it can be keyed framed without the AnimAll addon it makes for really great use being able to finalize your polish pass.

The idea here once you have your animation down. you can then come back in over the top and use the sculpt brush to keyframe the verts for cleaning. This is a much faster process than creating a shape key. The only downside is you can't keyframe mesh data in the pose library.

I mention this because I'm not sure how this is going affect the current system that is being implemented, and it's something that should be considered.

I know I'm giving away my trade secrets here, so here it is. If you expose the vertex matrix so it can be keyed framed without the AnimAll addon it makes for really great use being able to finalize your polish pass. The idea here once you have your animation down. you can then come back in over the top and use the sculpt brush to keyframe the verts for cleaning. This is a much faster process than creating a shape key. The only downside is you can't keyframe mesh data in the pose library. I mention this because I'm not sure how this is going affect the current system that is being implemented, and it's something that should be considered.

In #92218#1478341, @AdamEarle wrote:
If you expose the vertex matrix so it can be keyed framed without the AnimAll addon it makes for really great use being able to finalize your polish pass.

What do you mean by vertex matrix?

> In #92218#1478341, @AdamEarle wrote: > If you expose the vertex matrix so it can be keyed framed without the AnimAll addon it makes for really great use being able to finalize your polish pass. What do you mean by vertex matrix?

just bumping this thread. Vertex matrix means being able to animate the vertex directly like the animall addon allows.

I found the Expy kit, it is a bit sluggish on my system. I still cannot find the bone gizmo add on though, does anyone have the link?

I found the Expy kit, it is a bit sluggish on my system. I still cannot find the bone gizmo add on though, does anyone have the link?

Updated links in the post.

> I found the Expy kit, it is a bit sluggish on my system. I still cannot find the bone gizmo add on though, does anyone have the link? Updated links in the post.

Hi @Richard-Lee, did you manage to find the Gizmos branch? It's very close to inclusion. Also, I have kind of made the UI faster for the next release, until then, please hide the Expy tab during playbacks.

cheers!
p.

Hi @Richard-Lee, did you manage to find the Gizmos branch? It's very close to inclusion. Also, I have kind of made the UI faster for the next release, until then, please hide the Expy tab during playbacks. cheers! p.

Expy Kit Gizmos is working, and yes, closing the gizmos panel helped speed things up. Thank you.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mesh-based armature interaction ("Mesh Gizmos", "Face Maps") #92218

Preface

The Prototype: "Bone Gizmos" add-on

Features

Prototype Limitations