Face maps removal for 4.0 #105317

New Issue

The "Face Maps" feature was added preemptively for further work that was meant to happen during 2.8 development. That work was never finished, and in the meantime the generic attribute system was added.

Since face maps are just integers, all face maps should be changed with versioning into generic integer attributes. Any features using face maps should either be removed or changed to use the generic attribute system. Since the whole face maps system never got much use, removal is probably preferable in most cases.

The "Face Maps" feature was added preemptively for further work that was meant to happen during 2.8 development. That work was never finished, and in the meantime the generic attribute system was added. Since face maps are just integers, all face maps should be changed with versioning into generic integer attributes. Any features using face maps should either be removed or changed to use the generic attribute system. Since the whole face maps system never got much use, removal is probably preferable in most cases.

A general face-map attribute may not be an adequate replacement for face-maps, at least that would have to be further developed which might mean adding support for things that face-maps can do.

Face maps can be named, reference a vertex group (for deformation) & be selected.
In general the ability to add new fields such as color, locking... etc is useful. So if a generic integer layer is used for face-map functionality, we will need a way to do these things - which likely means having a named list of items like we already have.

On the other hand, they got to a prototype stage and have not had much use, so I'm not especially pushing to keep them if there is no interest to develop or use this feature.

@dr.sybren do you know if artists in the studio are interested in using this feature?

A general face-map attribute may not be an adequate replacement for face-maps, at least that would have to be further developed which might mean adding support for things that face-maps can do. Face maps can be named, reference a vertex group (for deformation) & be selected. In general the ability to add new fields such as color, locking... etc is useful. So if a generic integer layer is used for face-map functionality, we will need a way to do these things - which likely means having a named list of items like we already have. On the other hand, they got to a prototype stage and have not had much use, so I'm not especially pushing to keep them if there is no interest to develop or use this feature. @dr.sybren do you know if artists in the studio are interested in using this feature?

This sounds like the possible thing to do:

Add a group index attribute.
Add group color attribute.
Weight float attribute.
With a common prefix about the name.

This sounds like the possible thing to do: - Add a group index attribute. - Add group color attribute. - Weight float attribute. _With a common prefix about the name._

I asked artists and developers at the studio about removing this feature a few times over the last couple years. The main feedback I got was that they haven't used it, that it wasn't usable or finished enough as is, and that something like this would make more sense as part of the generic attribute system where it could benefit from usability and features provided by geometry nodes development. That was a while ago though.. (there was also a consensus that removing it should wait for a breaking release).

Personally I know that we don't have the features to directly replace this right now. But I also feel strongly that this design just doesn't fit in Blender when we also have the generic attribute system, and I've heard that thought from others as well.

I asked artists and developers at the studio about removing this feature a few times over the last couple years. The main feedback I got was that they haven't used it, that it wasn't usable or finished enough as is, and that something like this would make more sense as part of the generic attribute system where it could benefit from usability and features provided by geometry nodes development. That was a while ago though.. (there was also a consensus that removing it should wait for a breaking release). Personally I know that we don't have the features to directly replace this right now. But I also feel strongly that this design just doesn't fit in Blender when we also have the generic attribute system, and I've heard that thought from others as well.

My understanding at the time this feature was being developed was that it would be used for a system that lets us click geometry to control rigs. I offered all I could to try and make that into a reality, and turn Face Sets into something useful, here. It never got any developer interest. I asked for help a million times and it was like pulling teeth.

I still think this feature has incredible potential! It could be at the very top of the 4.0 release notes page and on all the youtube thumbnails! But as far as I know, there is no interest or time to finish it. So, if that's the case, remove it </3.

Otherwise, I'd be very happy to help out however I can, in making this into something useful. But at the end of the day, it would need a lot of time from a skilled dev. And frankly at this point, I'm not even sure if my initial understanding of what this feature was meant to be, is even correct at all! >.>

My understanding at the time this feature was being developed was that it would be used for a system that lets us click geometry to control rigs. I offered all I could to try and make that into a reality, and turn Face Sets into something useful, [here](https://projects.blender.org/blender/blender/issues/92218). It never got any developer interest. I asked for help a million times and it was like pulling teeth. I still think this feature has incredible potential! It could be at the very top of the 4.0 release notes page and on all the youtube thumbnails! But as far as I know, there is no interest or time to finish it. So, if that's the case, remove it </3. Otherwise, I'd be very happy to help out however I can, in making this into something useful. But at the end of the day, it would need a lot of time from a skilled dev. And frankly at this point, I'm not even sure if my initial understanding of what this feature was meant to be, is even correct at all! >.>

What's concerning with removing this feature is there are some users who seem to really want it, then note that it's not finished. Is there any agreement on what a finished version of this feature would look like?

Personally I know that we don't have the features to directly replace this right now. But I also feel strongly that this design just doesn't fit in Blender when we also have the generic attribute system, and I've heard that thought from others as well.

If the only issue is not using a generic attribute system CD_FACEMAP could fairly easily be replaced by an integer layer.

@Mets

Are the problems you ran into an inherent limitation with using face-maps as gizmos?

You mention this needing to be a built-in / core feature. Early versions of face-maps worked this way, then there was a change of plan to implement it via Gizmo's for Python scripters & riggers to use - but this meant it was up to riggers to solve many details for how to integrate it into an animation workflow - which in retrospect might not have been a good direction as it increased the barrier of entry to using the feature significantly.
On the other hand - if the current gizmo implementation was improved (any issues you ran into resolved), would this be useful to riggers? Or do you consider face-maps-as-gizmos to be a dead-end?

What's concerning with removing this feature is there are some users who seem to really want it, then note that it's not finished. Is there any agreement on what a finished version of this feature would look like? > Personally I know that we don't have the features to directly replace this right now. But I also feel strongly that this design just doesn't fit in Blender when we also have the generic attribute system, and I've heard that thought from others as well. If the only issue is not using a generic attribute system `CD_FACEMAP` could fairly easily be replaced by an integer layer. ---- @Mets - Are the problems you ran into an inherent limitation with using face-maps as gizmos? You mention this needing to be a built-in / core feature. Early versions of face-maps worked this way, then there was a change of plan to implement it via Gizmo's for Python scripters & riggers to use - but this meant it was up to riggers to solve many details for how to integrate it into an animation workflow - which in retrospect might not have been a good direction as it increased the barrier of entry to using the feature significantly. - On the other hand - if the current gizmo implementation was improved (any issues you ran into resolved), would this be useful to riggers? Or do you consider face-maps-as-gizmos to be a dead-end?

@Mets

Are the problems you ran into an inherent limitation with using face-maps as gizmos?

I would say most of the problems were more so issues with the Gizmo API. But there was one aspect of face maps that I think was a design choice that also doesn't work perfectly for the gizmo use case; That each face can only be assigned to one face map at a time, like material slots. I understand the logic behind this, but when trying it out, I found it would actually be better to have the flexibility, even if it enables users to create cases of ambiguity; It should just be left up to the riggers to avoid that, because with the extra flexibility of being able to assign a face to multiple gizmos, riggers can make a layered system, where faces are only mutually exclusive to a gizmo within a single layer of controls.

You mention this needing to be a built-in / core feature. Early versions of face-maps worked this way, then there was a change of plan to implement it via Gizmo's for Python scripters & riggers to use - but this meant it was up to riggers to solve many details for how to integrate it into an animation workflow - which in retrospect might not have been a good direction as it increased the barrier of entry to using the feature significantly.

I agree, back then it was unclear what would be the best choice, but I think now that years have gone by without any add-on developer successfully implementing bone gizmos, and with my best shot at it only resulting in something sub-par that can only be seen as a prototype, I agree that it would make sense to target bone gizmos as a core Blender feature, rather than something to provide API for to craft from scratch.

I think the prototype is still great for providing a design direction towards something that most users will probably be very happy with. And of course, having a strong API can still enable a lot of customization of the system, like with any system.

On the other hand - if the current gizmo implementation was improved (any issues you ran into resolved), would this be useful to riggers? Or do you consider face-maps-as-gizmos to be a dead-end?

I will say that I think the Gizmo API could be useful for a lot of things, and it could be greatly improved in and of itself, even outside of the bone gizmo use case. But to stay strictly on topic, when it comes to face maps, I think they would only be useful as part of the bone gizmo system, and until that exists, it would make sense to remove the face maps.

Those are my 2 cents-es! :D

> @Mets > > - Are the problems you ran into an inherent limitation with using face-maps as gizmos? I would say most of the problems were more so issues with the Gizmo API. But there was one aspect of face maps that I think was a design choice that also doesn't work perfectly for the gizmo use case; That each face can only be assigned to one face map at a time, like material slots. I understand the logic behind this, but when trying it out, I found it would actually be better to have the flexibility, even if it enables users to create cases of ambiguity; It should just be left up to the riggers to avoid that, because with the extra flexibility of being able to assign a face to multiple gizmos, riggers can make a layered system, where faces are only mutually exclusive to a gizmo within a single layer of controls. > You mention this needing to be a built-in / core feature. Early versions of face-maps worked this way, then there was a change of plan to implement it via Gizmo's for Python scripters & riggers to use - but this meant it was up to riggers to solve many details for how to integrate it into an animation workflow - which in retrospect might not have been a good direction as it increased the barrier of entry to using the feature significantly. I agree, back then it was unclear what would be the best choice, but I think now that years have gone by without any add-on developer successfully implementing bone gizmos, and with my best shot at it only resulting in something sub-par that can only be seen as a prototype, I agree that it would make sense to target bone gizmos as a core Blender feature, rather than something to provide API for to craft from scratch. I think the prototype is still great for providing a design direction towards something that most users will probably be very happy with. And of course, having a strong API can still enable a lot of customization of the system, like with any system. > - On the other hand - if the current gizmo implementation was improved (any issues you ran into resolved), would this be useful to riggers? Or do you consider face-maps-as-gizmos to be a dead-end? I will say that I think the Gizmo API could be useful for a lot of things, and it could be greatly improved in and of itself, even outside of the bone gizmo use case. But to stay strictly on topic, when it comes to face maps, I think they would only be useful as part of the bone gizmo system, and until that exists, it would make sense to remove the face maps. Those are my 2 cents-es! :D

'Use case for face maps' - world streaming.

In the viewport we can place triangles - these triangles can have a facemap attribute assigned in the ui

using geometry nodes we can then use 'instance on point' can use the triangles normal, and P1-P2 as a rotation and its user set collection spawn index /facemap attribue to spawn something from a collection on the triangle.

we can use distance from a empty to control if things are spawned or not effectively 'streaming' - manipulating the triangles in the viewport manipulates its spawned instance.

not being able to use the UI to assign a value to a attribute has been a pain*

'Use case for face maps' - world streaming. In the viewport we can place triangles - these triangles can have a facemap attribute assigned in the ui using geometry nodes we can then use 'instance on point' can use the triangles normal, and P1-P2 as a rotation and its user set collection spawn index /facemap attribue to spawn something from a collection on the triangle. we can use distance from a empty to control if things are spawned or not effectively 'streaming' - manipulating the triangles in the viewport manipulates its spawned instance. not being able to use the UI to assign a value to a attribute has been a pain*

'Use case for face maps 2' - foundation label - generated content frequently can be stored as 'hint meshes' that hold information about what to generate at that point when the camera is near.

being able to encode 'Floor number' per face or 'texture offset' for a texture atlas can make procedural and hand made stuff tie in together.

'Use case for face maps 2' - foundation label - generated content frequently can be stored as 'hint meshes' that hold information about what to generate at that point when the camera is near. being able to encode 'Floor number' per face or 'texture offset' for a texture atlas can make procedural and hand made stuff tie in together.

here are 2 videos of a 'instance streamer'

when instances are realized - if they all have 1 material than it's 1 drawcall - which is nice too

in the video I use a second meshes vertex to store data until I can write a face map attribute / generic attribute in the viewport

here are 2 videos of a 'instance streamer' when instances are realized - if they all have 1 material than it's 1 drawcall - which is nice too in the video I use a second meshes vertex to store data until I can write a face map attribute / generic attribute in the viewport

2023-05-21 08-10-20.mp4

6.4 MiB

2023-05-21 08-12-17.mp4

8.3 MiB

I should clarify that by removing this code, the goal isn't to remove the possibility of having a feature like mapping bones to faces and providing selection gizmos. I think this is more of a sideways move in that respect. The current implementation, using a separate list of names stored on objects (crucially not on the mesh itself, where geometry is actually edited), and with a separate non-generic data type, is just very far away from how such a feature should be implemented now that we have the generic attribute system and geometry nodes. Especially with plans for node group operators and gizmos.

To properly implement this feature, I believe most of this code would be removed anyway. Especially considering the fundamental concerns @Mets raised above about the exclusive "single map" aspect of the current storage.

To go back even further, maybe unnecessarily, frankly I also take a bit of issue with the name "Face Maps" and parts of the design. For a feature design primarily for selecting bones for rigging, the name is very generic. A better way to organize this feature might be adding the ability to choose a attribute name (or name and value combo) for each bone in rig settings elsewhere. With the animation project coming up, it's a good time to reconsider the right way to do this anyway.

I should clarify that by removing this code, the goal isn't to remove the possibility of having a feature like mapping bones to faces and providing selection gizmos. I think this is more of a sideways move in that respect. The current implementation, using a separate list of names stored on objects (crucially *not on the mesh itself,* where geometry is actually edited), and with a separate non-generic data type, is just very far away from how such a feature should be implemented now that we have the generic attribute system and geometry nodes. Especially with plans for node group operators and gizmos. To properly implement this feature, I believe most of this code would be removed anyway. Especially considering the fundamental concerns @Mets raised above about the exclusive "single map" aspect of the current storage. To go back even further, maybe unnecessarily, frankly I also take a bit of issue with the name "Face Maps" and parts of the design. For a feature design primarily for selecting bones for rigging, the name is very generic. A better way to organize this feature might be adding the ability to choose a attribute name (or name and value combo) for each bone in rig settings elsewhere. With the animation project coming up, it's a good time to reconsider the right way to do this anyway.

Since this is a project is something that would be good to support (in principle) and may be picked up at some point I think it's good to note the likely reasons for failure (at least not gaining much traction).

This repeats some points already made by others.

The design was too technical, it relied on the rigger to make technical/workflow decisions that didn't fit into existing workflows.
There was not enough developer follow up (working with artists/riggers), which would have likely lead us to the decision to change the design. Instead, the feature was considered working - because a demo was possible - leaving the rigger with many workflow issues to overcome.
One gizmo per face-map made setting them up impractical.

As a final remark, I don't think it's necessarily a bad idea to add API's with the expectation technical artists will use them as building blocks to create their own systems. However, with Blender's key-maps, modes, selection ... etc. made this quite involved, so a future implementation should probably be implemented as core functionality instead of via API's.

Since this is a project is something that would be good to support (in principle) and may be picked up at some point I think it's good to note the likely reasons for failure (at least not gaining much traction). _This repeats some points already made by others._ ---- - The design was too technical, it relied on the rigger to make technical/workflow decisions that didn't fit into existing workflows. - There was not enough developer follow up (working with artists/riggers), which would have likely lead us to the decision to change the design. Instead, the feature was considered working - because a demo was possible - leaving the rigger with many workflow issues to overcome. - One gizmo per face-map made setting them up impractical. As a final remark, I don't think it's necessarily a bad idea to add API's with the expectation technical artists will use them as building blocks to create their own systems. However, with Blender's key-maps, modes, selection ... etc. made this quite involved, so a future implementation should probably be implemented as core functionality instead of via API's.

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Face maps removal for 4.0 #105317