FaceMaps Phase 1: bone selection & bone display #54989

New Issue

William Reynish · 2018-05-07T15:49:57+02:00

William Reynish commented

2018-05-07 15:49:57 +02:00

The first phase of integrating the FaceMaps feature, is to make it work as an alternative way of displaying and selecting bones.

The user sets it up this way:

For each bone, we will have a display option called 'Face Map'. The user can enable it for all the bones he/she wants to use it
When enabled, it looks for Face Maps with the same name as the bone.

That's it. Users can then manipulate their rigs just like today, but bones will look as if you are selecting and manipulating the mesh itself.

The first phase of integrating the FaceMaps feature, is to make it work as an alternative way of displaying and selecting bones. The user sets it up this way: - For each bone, we will have a display option called 'Face Map'. The user can enable it for all the bones he/she wants to use it - When enabled, it looks for Face Maps with the same name as the bone. That's it. Users can then manipulate their rigs just like today, but bones will look as if you are selecting and manipulating the mesh itself.

Campbell Barton was assigned by William Reynish

2018-05-07 15:49:57 +02:00

Luciano Muñoz Sessarego commented

2018-08-13 18:43:14 +02:00

Any chance you see that facemaps would be able to drive other types of properties via drivers or something without it going trough bones?
for instance i want to drive a shapekey, o i want to drive a property of a bone not the bone (like the curve options and te like)

Any chance you see that facemaps would be able to drive other types of properties via drivers or something without it going trough bones? for instance i want to drive a shapekey, o i want to drive a property of a bone not the bone (like the curve options and te like)

Brecht Van Lommel closed this issue

2018-11-19 13:29:20 +01:00

Brecht Van Lommel reopened this issue

2018-11-19 13:29:38 +01:00

Brecht Van Lommel commented

2018-12-04 14:31:55 +01:00

Even in that case there should be a bone in between the face and the shape key. There needs to be something that you can select/deselect along with all the other bones, and that indicates along which axis and how far it can/should be transformed.

If it's a new type of data to interact with that complicates things a lot, while being less flexible than bones. If usability is an issue it may be better to create an operator for easy set up of a shape key mapping.

Even in that case there should be a bone in between the face and the shape key. There needs to be something that you can select/deselect along with all the other bones, and that indicates along which axis and how far it can/should be transformed. If it's a new type of data to interact with that complicates things a lot, while being less flexible than bones. If usability is an issue it may be better to create an operator for easy set up of a shape key mapping.

bassam kurdali commented

2019-02-13 17:01:02 +01:00

It looks like facemaps-> bone selection is pending design changes to precisely allow tying them to custom widgets - https://developer.blender.org/T51675
So you can ignore my comment :)

It might be okay to use bones for that use case, but use some kind of custom widgets (activated on facemap/bone selection) to easily manipulate custom properties on a bone, or another none transform property.

This is consistent with transformation widgets, and other tool widgets, but I don't have a lot of answers for usability; it might be nicer for animators to get custom widgets without having to ask for them explicitly in the toolbar, by e.g. just selecting the relevant facemap/bone.

It looks like facemaps-> bone selection is pending design changes to precisely allow tying them to custom widgets - https://developer.blender.org/T51675 So you can ignore my comment :) > It might be okay to use bones for that use case, but use some kind of custom widgets (activated on facemap/bone selection) to easily manipulate custom properties on a bone, or another none transform property. > > This is consistent with transformation widgets, and other tool widgets, but I don't have a lot of answers for usability; it might be nicer for animators to get custom widgets without having to ask for them explicitly in the toolbar, by e.g. just selecting the relevant facemap/bone.

William Reynish commented

2019-02-13 17:20:56 +01:00

@BassamKurdali Well, that task is the 'original' Face maps topic.

The way I see it is, that original topic tried to tackle two very different things. One of which solves a concrete and simple problem, and the other one being a rather vague issue.

The original Face Maps task was really about two different things:

Bone display & selection by clicking on the mesh itself
Intelligent widget-based interaction and rag doll manipulation of rigs in Object Mode

If you look at Pixar's Presto software, it has both of these things. It has an easy way to select bones directly by clicking on the mesh elements (the animators use this), and it also has a way to pull puppets around using full body IK with advanced constraints, without requiring any tools. (which apparently none of the animators use btw)

The truth is that those two things are actually quite unrelated. One does not actually depend much on the other at all. I think it's actually a mistake to even consider these two things part of the same topic & system. They are entirely independant features.

The 1st topic related to the display and selection of bones on top of the mesh itself has, IMO, by far the biggest impact and benefit for animators. This solves a real problem, which is that bones are visually distracting when viewed on top of your mesh, and impossible to select when they are viewed inside the mesh. This problem is relatively easy to implement a solution for.

The 2nd topic, which is much more elusive and generic, is about an abstracted widget-based way to manipulate rigs. This kind of thing is cool, but 1, doesn't solve a very concrete problem and 2, is very broad a vague. The topic was getting out of hand, and the way the widgets would interact with rigs and armatures was not well defined or completely clear.

This is why I proposed to split apart these two things, so we could start by doing the simple thing that solves a very clear and concrete problem (#1) before doing #2.

@BassamKurdali Well, that task is the 'original' Face maps topic. The way I see it is, that original topic tried to tackle two very different things. One of which solves a concrete and simple problem, and the other one being a rather vague issue. The original Face Maps task was really about two different things: - Bone display & selection by clicking on the mesh itself - Intelligent widget-based interaction and rag doll manipulation of rigs in Object Mode If you look at Pixar's Presto software, it has both of these things. It has an easy way to select bones directly by clicking on the mesh elements (the animators use this), and it also has a way to pull puppets around using full body IK with advanced constraints, without requiring any tools. (which apparently none of the animators use btw) The truth is that those two things are actually quite unrelated. One does not actually depend much on the other at all. I think it's actually a mistake to even consider these two things part of the same topic & system. They are entirely independant features. The 1st topic related to the display and selection of bones on top of the mesh itself has, IMO, by far the biggest impact and benefit for animators. This solves a real problem, which is that bones are visually distracting when viewed on top of your mesh, and impossible to select when they are viewed inside the mesh. This problem is *relatively* easy to implement a solution for. The 2nd topic, which is much more elusive and generic, is about an abstracted widget-based way to manipulate rigs. This kind of thing is cool, but 1, doesn't solve a very concrete problem and 2, is very broad a vague. The topic was getting out of hand, and the way the widgets would interact with rigs and armatures was not well defined or completely clear. This is why I proposed to split apart these two things, so we could start by doing the simple thing that solves a very clear and concrete problem (#1) before doing #2.

Campbell Barton commented

2019-09-27 04:43:07 +02:00

For each bone, we will have a display option called 'Face Map'.

This seems inconvenient, why not just use the face-map if there is one with a matching name?

The chance you don't want to use the face-map that exists with a matching name seems low. Unless you don't want to see face-maps at all. In that case there can be an armature level display option which you can toggle if you want use face-maps or not.

> For each bone, we will have a display option called 'Face Map'. This seems inconvenient, why not just use the face-map if there is one with a matching name? The chance you don't want to use the face-map that exists with a matching name seems low. Unless you don't want to see face-maps at all. In that case there can be an armature level display option which you can toggle if you want use face-maps or not.

Brecht Van Lommel commented

2019-09-27 15:35:10 +02:00

In #54989#784543, @ideasman42 wrote:

For each bone, we will have a display option called 'Face Map'.

This seems inconvenient, why not just use the face-map if there is one with a matching name?

The chance you don't want to use the face-map that exists with a matching name seems low. Unless you don't want to see face-maps at all. In that case there can be an armature level display option which you can toggle if you want use face-maps or not.

It can be a boolean enabled by default, like "Bone.use_deform". For some cases you may want to exclude specific bones.

This is probably not very important now since every face can only be assigned to one face map, and face maps mainly serve one purpose. It would be more important with general face groups. But it's also a very simple option to add.

> In #54989#784543, @ideasman42 wrote: >> For each bone, we will have a display option called 'Face Map'. > This seems inconvenient, why not just use the face-map if there is one with a matching name? > > The chance you don't want to use the face-map that exists with a matching name seems low. Unless you don't want to see face-maps at all. In that case there can be an armature level display option which you can toggle if you want use face-maps or not. It can be a boolean enabled by default, like "Bone.use_deform". For some cases you may want to exclude specific bones. This is probably not very important now since every face can only be assigned to one face map, and face maps mainly serve one purpose. It would be more important with general face groups. But it's also a very simple option to add.

William Reynish commented

2019-09-27 15:37:22 +02:00

@brecht yes, I guess that makes sense, and still keeps @ideasman42's idea of making it more automatic by default.

bassam kurdali commented

2019-09-28 00:04:15 +02:00

I agree, it also fits with e.g. how use_deform and vertex groups currently work

Joseph Brandenburg commented

2019-09-29 02:23:54 +02:00

I wonder if face maps could be a part of the Viewport display panel in the bone properties panel?

You could select the mesh as the Custom Object, and there would be an option for face maps with a drop-down menu that lets you choose which one you want. And it would choose like names by default. You could turn them on and off by enabling and disabling custom shapes.

I wonder if face maps could be a part of the Viewport display panel in the bone properties panel? ![view_panel.PNG](https://archive.blender.org/developer/F7779100/view_panel.PNG) You could select the mesh as the Custom Object, and there would be an option for face maps with a drop-down menu that lets you choose which one you want. And it would choose like names by default. You could turn them on and off by enabling and disabling custom shapes.

Campbell Barton commented

2019-10-03 16:29:34 +02:00

Posting a link to another proposal: #51675 (Face-Map 2.8 Proposal) for reference.

This was based on the idea that face-maps wouldn't be restricted to bones/pose mode.
So you could - for example, use this as a generic to interact with objects (click on a door handle to open the door for example), use for interactive mode, etc.
This is something Ton was interested to have working and is currently supported via gizmos which can draw using face-maps already.

While this proposal goes in a different direction, we can keep support for using face-maps from gizmos, so face-maps can still support more flexible (non pose mode) features in the future.

Posting a link to another proposal: #51675 (Face-Map 2.8 Proposal) for reference. This was based on the idea that face-maps wouldn't be restricted to bones/pose mode. So you could - for example, use this as a generic to interact with objects (click on a door handle to open the door for example), use for interactive mode, etc. This is something Ton was interested to have working and is currently supported via gizmos which can draw using face-maps already. While this proposal goes in a different direction, we can keep support for using face-maps from gizmos, so face-maps can still support more flexible (non pose mode) features in the future.

Brecht Van Lommel commented

2020-09-08 17:18:22 +02:00

For a visual example of what this could look like, see at 0:40 in this demo of Presto. There are no bones visible, parts of the mesh are highlighted and selected.
https://vimeo.com/90687696

For a visual example of what this could look like, see at 0:40 in this demo of Presto. There are no bones visible, parts of the mesh are highlighted and selected. https://vimeo.com/90687696

Sybren A. Stüvel commented

2020-09-08 17:22:26 +02:00

@brecht thanks for the video.

Are there any milestones defined somewhere? Or a plan of who's going to work on it?

@brecht thanks for the video. Are there any milestones defined somewhere? Or a plan of who's going to work on it?

Brecht Van Lommel commented

2020-09-08 19:36:54 +02:00

No, there's currently no plan for a specific developer to work on this, or for when it will be worked on.

Regarding milestones, I think this functionality is small enough that it would just be implemented all at once. At least I'm not sure what would be in a second milestone, maybe user testing would reveal additional changes that are needed.

No, there's currently no plan for a specific developer to work on this, or for when it will be worked on. Regarding milestones, I think this functionality is small enough that it would just be implemented all at once. At least I'm not sure what would be in a second milestone, maybe user testing would reveal additional changes that are needed.

Sybren A. Stüvel commented

2020-09-10 11:11:35 +02:00

Part of the implementation of the feature has already been committed to master, so it's not being implemented at once. This means that somebody thought "this is a good chunk of work, we've reached something, let's merge it to master", which to me sounds like a milestone was reached. This should mean that there is also a more fleshed-out design, and an indication as to how this feature fits into the bigger picture. Maybe this is all defined somewhere, but I'm missing it at the moment. The parent task having no description and being closed as "Invalid" doesn't help much either.

#51675 (Face-Map 2.8 Proposal) has more detail, but also contains:

Development Plan
Currently an open topic - at which step would we consider merging into 2.8 acceptable.

There are no commits linked to either this task or #51675, yet there is a panel "Face Maps" currently in Blender. d888453244 seems to have introduced this panel, but it doesn't seem to have had any review, and doesn't mention any Task.

@brecht @ideasman42 What is the current status? Which (sub)features of Face Maps are usable for artists now?

Part of the implementation of the feature has already been committed to master, so it's not being implemented at once. This means that somebody thought "this is a good chunk of work, we've reached something, let's merge it to master", which to me sounds like a milestone was reached. This should mean that there is also a more fleshed-out design, and an indication as to how this feature fits into the bigger picture. Maybe this is all defined somewhere, but I'm missing it at the moment. The parent task having no description and being closed as "Invalid" doesn't help much either. #51675 (Face-Map 2.8 Proposal) has more detail, but also contains: > **Development Plan** > Currently an open topic - at which step would we consider merging into 2.8 acceptable. There are no commits linked to either this task or #51675, yet there is a panel "Face Maps" currently in Blender. d888453244 seems to have introduced this panel, but it doesn't seem to have had any review, and doesn't mention any Task. @brecht @ideasman42 What is the current status? Which (sub)features of Face Maps are usable for artists now?

Brecht Van Lommel commented

2020-09-10 12:02:23 +02:00

I think the implementation using widgets and the add-on from #51675 should be discarded, and it should be implemented as described in this task instead. For the reasons described by William in #54989#619950.

Face maps were committed into the Blender 2.8 branch, as were many other incomplete features. I think that in hindsight, it should have been disabled before making that branch master.

I think the implementation using widgets and the add-on from #51675 should be discarded, and it should be implemented as described in this task instead. For the reasons described by William in #54989#619950. Face maps were committed into the Blender 2.8 branch, as were many other incomplete features. I think that in hindsight, it should have been disabled before making that branch master.

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

FaceMaps Phase 1: bone selection & bone display #54989