Face maps removal for 4.0 #105317
Labels
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
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
18 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: blender/blender#105317
Loading…
Reference in New Issue
No description provided.
Delete Branch "%!s(<nil>)"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
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.
Thomas Dinges referenced this issue2023-03-07 11:07:33 +01:00
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:
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.
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: #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?
If the only issue is not using a generic attribute system
CD_FACEMAPcould 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?
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.
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.
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 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
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.
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.
I agree with all Hans said in the above comment. There's definitely interest from the Animation & Rigging module in mesh-based gizmos/interaction, and having such a system integrated well with the current development of the mesh layer structure seems pivotal.
As for the current implementation, I'd be hesitant to remove it until there is something better to replace it. Unless it's significantly in the way of other development, of course.
Sometimes (when modeling or cleaning up a purchased model) I need to save a complex selection of faces and load that selection later. Reloading a Vertex Group rarely returns exactly the same face selection I need. Face Maps on the other hand worked absolutely perfectly.
People familiar with Selection Sets or clusters or other such things in other software would use this feature exactly as they used selection sets in Maya instead of complaining in the forums every few weeks about how Vertex Groups can't properly save and reload face selections. A studio that's been using Blender for years and just putting up with the lack of a way to save a face selection probably doesn't know what they were missing.
All the rigging related stuff never even crossed my mind. I honestly assumed this feature was added because long-time Maya users complained endlessly about not having a way to save face and edge selections as easily as saving vertex selections with Vertex Groups.
Right, that's an important use case and isn't covered well in the UI. However, stored as integers internally, face maps weren't great for that. Using face maps means it's not possible to have multiple selections with faces in common. Boolean attributes are a better solution technically, and can be added on any domain (faces, edges, vertices) in the "Attribute" list. From edit mode, you can use the "Set Attribute" operator to do the same thing basically.
What's missing is a way to restore that selection. That's a trivial feature to add, we just need to find the best way to do it. It could be an operator "Selection from Attribute".
It could also be practically the same UI it had previously.
Agreed. "Vertex Groups" is somewhat obvious in workflow - I select a group of vertexes, press +, and make a group.
If using the attribute list, I must now ...
(And obviously, cannot not restore this selection as noted above, needs a feature add)
The previous feature with the simple "chart list of faces" was fine; just duplicate the "Vertex Groups" UI, change it to "Face Groups", and there it is.
Noted, but bone layers don't allow a bone to be in multiple layers... nonetheless, bone layers haven't been removed as a feature.
I am working on a game and we have been using face maps as a way of masking different areas/groups of faces of a mesh to change their colours without affecting any other areas/groups of faces.
We had to edit the gltf exporter to actually get face maps to export with the model and we were hoping that at some point, they would just be something that was exported with the model by default.
Changing face maps to an attribute sounds like something that will be exclusive to geometry nodes/shader editor and will completely brick this feature of the game we're making, so I'd really like to see it changed to something like thorn-neverwake mentioned. A similar feature to vertex groups, but way more useful for selecting and manipulating bigger portions of a mesh.
Don't worry, attributes are not exclusive to anything. UVMaps are already Attributes.
The old Face Maps implementation could already be re-implemented in pure Python, with a UIList and 4 operators that manage an integer attribute on the face domain. I think it would be nice to have it as a built-in add-on that's disabled by default, since I think most people won't use it. (Compared to something like UVMaps)
In any case, it is inevitable that you will have to tweak your GLTF exporter to grab the data from somewhere else.
vanilla glTF exporter can export attributes
Yes without this i dont wanne us 4.0 ....
I am also a character Artist. I us Face Maps for sculpt poses and way more in Cloth Sculpting. Also i us in sculpt Mode "Initialize Face Sets -> By Face Maps"
Thx @ all devs Great Work :)
I'd like to add that I also use the face map system as an equivalent for selection sets from 3DS Max in my addon. While I've already put in the work to build a replacement system I don't see why this needs to be removed. Attributes do not look like a good alternative.
Another person in this thread mentioned you can rebuild the entire thing in Python but is that without compromise? I'm not sure it's possible to transfer all the necessary data when joining objects. I store the names for my face map replacement in a collection property and that's lost when I join objects. There's also not being able to set the default value for attributes and having to go out of your way to handle syncing all the indices yourself.
Is it really necessary to do this? Especially with no good alternatives? I get that if this remained in then it would have likely changed and would no longer fit the job requirements here but still. The workflow went from being reasonably smooth to me having to set up an operator that transfers the data properly since I can't extend the functionality of the built in join operator.
Addon I use facemaps for:
Halo Asset Blender Development Toolset
Most points I'm hearing are about people storing selections for later.
A boolean attribute on faces corresponds exactly to a selection (in fact that's exactly how selections are stored internally). So I think all we need is a way to set the selection from an attribute, and possibly a more convenient way to an attribute based on the selection (besides the existing "Set Attribute" operator).
That's not how selection sets in 3DS works though and the overlap basically makes it unusable in instances where each face needs a single unique identifier. This is very important for creating content for games like Halo since that's how they section off different parts of the mesh.
Also doesn't solve the bit I mentioned about losing data when using the built in join operator. Something that didn't happen with facemaps
I think this is mostly what my built-in add-on suggestion above was about.
This is a good point though, which the add-on solution doesn't address... Now, if we could extend built-in operators with add-ons, on the other hand... I think that would address this, and have a lot of other use cases! ;) (By hooking into the Join operator and defining how the add-on data should be merged)
There's also losing data when copying objects from one scene to another. I've already made an alternative to the facemaps system in my addon already in preparation for losing the setup but it's not ideal. Works the same for the most part besides joining objects through the join operator and copying from one Blend scene to another. I couldn't see a way to join collection properties without iterating through it either.
From 2023-08-01 blender admins meeting.
@ideasman42 Was there a follow-up ?
@HooglyBoogly any news on :
?
Sorry for the delay. There were some things in a way, and some stuff slipped through the cracks.
From the admin meeting perspective the agreement was basically that it is not very good to remove functionality without providing good replacement for it. During the admin meeting it also seemed that reverting the removal could still fit into the release cycle, assuming it is well isolated piece of code.
Hans and I spent quite some time looking into practical way forward. While revert will solve some aspects of the confusion here, it also brings ricks of introduced bugs, and makes some further development more complicated.
Unfortunately, it does not seem that we can do "lossless" replacement of the Face Maps on the UI level. Mainly because there is no easy way to "extract" face set attributes and display them in a dedicated UI list. Mitigation for this is the sorting in the Attributes list which already groups attributes by domain and type.
The rest of missing functionality is related on the selection. Turns out we already have "Set Attribute" operator! It can be found in the Mesh -> Set Attribute menu. It operates on the current active attribute.
The "Selection from Attribute" is still missing, but is easy to implement. And this is what Hans will implement. It will likely be at the bottom of the Select menu.
The fact that face maps are not intrinsically exclusive when done as boolean selection attributes seems to actually open opportunities to use face maps for rigging. Maybe even other use-cases. The exclusivity can be achieved even with the boolean attribute, although it will not be automatic. It is easy to do with a script. Not sure if such script is something we want to have out-of-the-box.
The join operator works naturally for boolean attributes, as it joins attributes by name (checking domain and type, of course).
For those who needs to be able to have a list of face maps for IO the heuristic would be to consider any boolean face attribute as a face map.
We've also discussed possible change to the do-versioning code. Currently it converts face map to a single integer attribute, which matches the internal storage of face maps, but loses name information. It is also not how we imagine face maps to be replicated with attributes when "created from scratch". The idea we have is to additionally convert face maps to boolean attributes with proper names.
Hopefully this makes sense :)
The short term is:
Long term improvement list could be very long :) Something from just the top of my head:
Hi Sergey,
I was experimenting with the attributes system yesterday to see how it works and came to the exact same conclusions you pointed out here.
It really does seem to be a better version of face maps! Am I correct in assuming that this means that any particular face or group of faces which has been assigned to an attribute with the boolean type can belong to more than one boolean attribute?
Thanks for testing this.
Yes, an arbitrary number of boolean attributes can be "true" for a single face. Or in other words, a face can belong to many different boolean attribute selections.
I want to point out one particular case, which is initiating Face Sets from Face Maps. That's mostly how I use this feature in 3.6. I know since this is just converting attributes it is possible with new node tools, and I can recreate that, but I would suggest adding that node tool as asset in 4.0. It will allow people to keep same workflow without having to adjust, and also familiarize concept of node tools to users.
Thanks for the follow up .
I would like to emphasize that the "old" method was consistent with the familiar way of working with the same user interface and operator type of Vertex Groups.
the "old UI" allowed Assigning or Removing from new and existing Face Maps as well as selecting or deselecting from existing/active selection.
Let's just remove the Vertex groups UI !
I'm all for moving forward with 'change to the do-versioning code' and all that, but with UI and features parity of the old Face Maps.
Yes, moving face Maps to attributes is a good thing. But not with so many losses along the way when using Blender 4.0.
In addition to a Selection by Attribute operator, could we also get an operator to remove Selected geometry from an Attribute?
And also maybe an operator to create a copy of an Attribute so we don't have to input the domain and data type every time we want to make a new one if it's going to be the same domain and data type but have a different name and Selection of geometry?
to bridge the gap for some (including myself :-) I created a tiny add-on. Details here, GPL code on GitHub.
Think it wouldn't be that crazy to add Face Sets from Selection Attributes operator. @HooglyBoogly thoughts about this?
Its a trade-off. Surely, it will be much easier topic if the UI for grouping attributes and few other tweaks were implemented. But this is planned for the 4.x series and will be a good improvement overall. You also have better integration with geometry nodes (meaning, it is possible to use te feature outside of a couple of hardcoded use-cases). If we keep the feature, it means we would need to invest time and resources ensuring it works until Blender 5.0. Wouldn't be that big of a deal, but some design decisions of the feature are getting in a way of other well-wanted improvements (i.e., the fact that names of the Face Sets are on object level).
Isn't this possible with "Set Attribute" and set the value to False?
It's the UI/UX issue I think. Currently it's very easy, you can just select faces and click either Assign or Remove, or Select. New method while keeping the same functionality introduces more necessary clicks. Nothing too much, but in general some convenient UI is very needed for attributes. assign/remove/select, maybe ability to display them in edit mode (why not allow face set overlay or vertex weights?), filtering by domain, etc.
If anyone needs a replacement I just ended up making something that works almost exactly like face maps did previously.
https://github.com/General-101/Halo-Asset-Blender-Development-Toolset/blob/master/io_scene_halo/global_ui/region_ui.py
Only issue is that the collection property gets lost when joining objects or copying objects from Blender instant to Blender instance. If that's a no go for your then just go with boolean attributes. Code as is doesn't work with the face map attribute generated from older files because the code is 0 indexed since attributes can't have a default value and always start at 0. You need to add 1 to all the values in the attributes for it to be usable with this.
Hi! I just looked this thread up, when I needed my face maps UI to link face maps in my modeling workflow. I was kinda surprised to see it gone, and just learned that it was removed in 4.0 for some reason. I don't use geometry nodes, still didn't have time to learn it, I don't even know what the whole attribute thing is. Any real reason to see it gone? Was it like impacting performance or something? I'll have to probably roll back my version if I won't find an alternative...
Ok I actually found a stupid easy workaround. Just create two new materials, and assign the selected faces to the second material.
This change has just severely broken an addon I have been maintaining and building for the last year. Seriously not happy :(
A Boolean attribute on the Face domain should be able to store equivalent data as what a face map used to. So it should be possible to tweak your add-on to use Attributes instead. If that isn't the case, you can mention any lacking Python API that needs to be added.
@DrewTNBD if you want you can have a peek at the code I linked a few comments back. As Demeter indicated, it isn't super complicated or anything, and I personally think having one unified way of working with attribute layers is actually a good thing, even if it breaks some things (I've been there myself 😄)