Page MenuHome

FaceMaps Phase 1: bone selection & bone display
Confirmed, NormalPublicDESIGN

Description

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.

Event Timeline

William Reynish (billreynish) lowered the priority of this task from 90 to Normal.May 7 2018, 3:49 PM

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 (brecht) changed the task status from Unknown Status to Unknown Status.Nov 19 2018, 1:29 PM
Brecht Van Lommel (brecht) changed the task status from Unknown Status to Unknown Status.
Brecht Van Lommel (brecht) edited a custom field.

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.

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.

@bassam kurdali (bassamk) 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:

  1. Bone display & selection by clicking on the mesh itself
  2. 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.

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.

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.

@Brecht Van Lommel (brecht) yes, I guess that makes sense, and still keeps @Campbell Barton (campbellbarton)'s idea of making it more automatic by default.

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

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.

Posting a link to another proposal: T51675: 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.

miles (miles) rescinded a token.
miles (miles) awarded a token.

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

@Brecht Van Lommel (brecht) thanks for the video.

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

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.

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.

T51675: 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 T51675, yet there is a panel "Face Maps" currently in Blender. rBd88845324430 seems to have introduced this panel, but it doesn't seem to have had any review, and doesn't mention any Task.

@Brecht Van Lommel (brecht) @Campbell Barton (campbellbarton) What is the current status? Which (sub)features of Face Maps are usable for artists now?

I think the implementation using widgets and the add-on from T51675 should be discarded, and it should be implemented as described in this task instead. For the reasons described by William in T54989#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.