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

Open
opened 2021-10-14 16:38:30 +02:00 by Demeter Dzadik · 58 comments
Member

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.
Author
Member

Added subscriber: @Mets

Added subscriber: @Mets
Demeter Dzadik self-assigned this 2021-10-14 16:42:37 +02:00
Author
Member

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

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

Added subscriber: @LucianoMunoz

Added subscriber: @LucianoMunoz

Added subscriber: @AndyCuccaro

Added subscriber: @AndyCuccaro

Added subscriber: @GeorgiaPacific

Added subscriber: @GeorgiaPacific

Added subscriber: @Phigon

Added subscriber: @Phigon

Added subscriber: @MaybeLamia

Added subscriber: @MaybeLamia
Member

Added subscriber: @PaoloAcampora

Added subscriber: @PaoloAcampora

Added subscriber: @L0Lock

Added subscriber: @L0Lock

Added subscriber: @RomboutVersluijs

Added subscriber: @RomboutVersluijs

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

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

Added subscriber: @HooglyBoogly

Added subscriber: @HooglyBoogly
Member

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.

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.
Author
Member

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: @ErickNyanduKabongo

Added subscriber: @Capitanblue89

Added subscriber: @Capitanblue89

Added subscriber: @Mamoun88

Added subscriber: @Mamoun88

Removed subscriber: @Mamoun88

Removed subscriber: @Mamoun88

Added subscriber: @rwman

Added subscriber: @rwman
Member

Added subscriber: @Jeroen-Bakker

Added subscriber: @Jeroen-Bakker

Added subscriber: @g-lul

Added subscriber: @g-lul

Added subscriber: @jeremybep

Added subscriber: @jeremybep

Added subscriber: @wevon-2

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

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: @pauanyu_blender

Added subscriber: @ArtemBataev

Added subscriber: @ArtemBataev

Added subscriber: @JohanTriHandoyo

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

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)
Contributor

Added subscriber: @RedMser

Added subscriber: @RedMser

Added subscriber: @Commander-Mustard

Added subscriber: @Commander-Mustard

Added subscriber: @Richard-Lee

Added subscriber: @Richard-Lee

Added subscriber: @zNight

Added subscriber: @zNight
Author
Member

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?
Contributor

Added subscriber: @Nika-Kutsniashvili

Added subscriber: @Nika-Kutsniashvili

Added subscriber: @leriaz

Added subscriber: @leriaz

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

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

Added subscriber: @Zophiekat

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

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
Contributor

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?

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?
Author
Member

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

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

Added subscriber: @BClark

Added subscriber: @BClark
Member

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.

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

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

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

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

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.
Author
Member

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?
Philipp Oeser removed the
Interest
Animation & Rigging
label 2023-02-09 14:35:29 +01:00
Member

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

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?
Author
Member

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

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.

Expy Kit Gizmos is working, and yes, closing the gizmos panel helped speed things up. Thank you.
Sign in to join this conversation.
No Label
Interest
Alembic
Interest
Animation & Rigging
Interest
Asset Browser
Interest
Asset Browser Project Overview
Interest
Audio
Interest
Automated Testing
Interest
Blender Asset Bundle
Interest
BlendFile
Interest
Collada
Interest
Compatibility
Interest
Compositing
Interest
Core
Interest
Cycles
Interest
Dependency Graph
Interest
Development Management
Interest
EEVEE
Interest
EEVEE & Viewport
Interest
Freestyle
Interest
Geometry Nodes
Interest
Grease Pencil
Interest
ID Management
Interest
Images & Movies
Interest
Import Export
Interest
Line Art
Interest
Masking
Interest
Metal
Interest
Modeling
Interest
Modifiers
Interest
Motion Tracking
Interest
Nodes & Physics
Interest
OpenGL
Interest
Overlay
Interest
Overrides
Interest
Performance
Interest
Physics
Interest
Pipeline, Assets & IO
Interest
Platforms, Builds & Tests
Interest
Python API
Interest
Render & Cycles
Interest
Render Pipeline
Interest
Sculpt, Paint & Texture
Interest
Text Editor
Interest
Translations
Interest
Triaging
Interest
Undo
Interest
USD
Interest
User Interface
Interest
UV Editing
Interest
VFX & Video
Interest
Video Sequencer
Interest
Virtual Reality
Interest
Vulkan
Interest
Wayland
Interest
Workbench
Interest: X11
Legacy
Blender 2.8 Project
Legacy
Milestone 1: Basic, Local Asset Browser
Legacy
OpenGL Error
Meta
Good First Issue
Meta
Papercut
Meta
Retrospective
Meta
Security
Module
Animation & Rigging
Module
Core
Module
Development Management
Module
EEVEE & Viewport
Module
Grease Pencil
Module
Modeling
Module
Nodes & Physics
Module
Pipeline, Assets & IO
Module
Platforms, Builds & Tests
Module
Python API
Module
Render & Cycles
Module
Sculpt, Paint & Texture
Module
Triaging
Module
User Interface
Module
VFX & Video
Platform
FreeBSD
Platform
Linux
Platform
macOS
Platform
Windows
Priority
High
Priority
Low
Priority
Normal
Priority
Unbreak Now!
Status
Archived
Status
Confirmed
Status
Duplicate
Status
Needs Info from Developers
Status
Needs Information from User
Status
Needs Triage
Status
Resolved
Type
Bug
Type
Design
Type
Known Issue
Type
Patch
Type
Report
Type
To Do
No Milestone
No project
No Assignees
31 Participants
Notifications
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: blender/blender#92218
No description provided.