Page MenuHome

FaceMaps Phase 1: bone selection & bone display
Open, NormalPublic


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) triaged this task as Normal priority.

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 Type from To Do to Design.
Brecht Van Lommel (brecht) closed this task as Archived.
Brecht Van Lommel (brecht) reopened this task as Open.

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