Animation: Replacing bone layers + groups with bone collections #108941

New Issue

Sybren A. Stüvel · 2023-06-13T17:08:37+02:00

Sybren A. Stüvel commented

2023-06-13 17:08:37 +02:00

This design describes the replacement of armature bone layers & bone groups with a new bone collections system.

Implementation is in #109976 and #112271, with feedback from Demeter in #116795.

Goals

Named collections, instead of numbered layers, should give a better indication as to what the collection contains / is for.
Increased flexibility in number of collections.
More similarity to the scene object collections, including features like 'not selectable' which can increase clarity of how to use a rig by animators.
Compatibility with library overrides, so that new shot-specific bone collections can be added.
Unification of numbered bone layers (for organisation) and named bone groups (for coloring).

Properties of the System

Armatures have one or more bone collections.
- If there is only one collection it cannot be removed.
Every bone is in zero or more bone collections.
Bone collections cannot be nested. At least not for 4.0, can be added later.
Bone collections must have a unique name within the armature.
Library Overrides:
- New bone collections can be added.
- Existing ones cannot be reordered / removed.
Bone collections have the following properties:
- Name
- Selectable: 'set' wins over 'cleared'
- Visible: 'set' wins over 'cleared'
- IDProperties (aka Custom Properties) for use by add-ons.
Bones will get individual color properties.
- The color system of bone groups will be used, which allows selection of 'default', 20 theme-defined colors, and a custom RGB value.
- Bones have a color defined as part of the armature data. Here 'default' is the default grey color.
- Pose Bones have a color defined as part of the object/pose data. Here 'default' means 'uncolored', and will thus show the edit bone color.

Operations

These operations can be performed on/with bone collections:

(De)select one or more collections themselves
(De)select all bones in active collection
(De)select all bones in collections containing the currently selected bones
Create a new collection
Delete a collection. Bones in the collection that are now 'orphaned' are assigned to the 'default' collection.
Move collection up/down in the list.
Move selected bone(s) to a collection.
Select Bones of Same Color.

User Interface

For Blender 4.0 the UI is kept intentionally simple. I'm thinking of reusing the Bone Groups interface, with the addition of a few per-collection icons (visible, selectable, color palette) as well as an indicator of which collection(s) contain the selected bone(s).

Conversion from Old to New

Layers converted to Layer {NUM} collections.
Bone groups converted to {name} collections.
Selection Sets converted to SelSet {name} collections.
Maybe even automatically merge these when they contain the same bones?

Uses of the Current System

Bone Layers

Visibility
Logical grouping

Bone Groups

Coloring of logical groups
Set by rigger

Edit Mode vs. Pose Mode

This describes Blender's current behavior:

Property / Action	Edit	Pose
Name Bone	✅	✅
Set Bone Layers	✅	✅
See Bone in Group Color	❌ ¹⁾	✅
Create / Assign Bone Group	❌ ¹⁾	✅
Select Bones in Group	❌ ¹⁾	✅
Set Bone Group Color	✅	✅
Set Armature Viewport Display options	✅	✅
Set Bone Viewport Display options	❌ ²⁾	✅

¹⁾ The new system should allow these in Edit mode too.
²⁾ Bones can only be hidden, which is separated between edit mode & pose mode.

Future Work

These are ideas for future improvements / extensions:

Nestable bone collections.
Integration with the Outliner.
Per-collection option whether bones are deforming or not (rather than setting that per bone)
Per-collection viewport display mode (octo, line, bbone, etc)
Possibly unification of Selection Sets as well.

Code Location

This work will kickstart a new module in source/blender/animrig. This will become the place for new animation/rigging related code. The intention is that also a subset of the already-existing animation-related code from both blenkernel and editors is going to move there, to help clean up the API and make it more consistent.

Ongoing Work

Targets for 4.0-bcon1: tracked in #109976

Targets that could be pushed back to 4.0-bcon2:

Add ID Properties support to bone collections, including a UI.
Removal of bone group RNA access & UI
Ensure that library overrides can add new bone collections & assign bones to them (#112271)
Removal of bone groups from the UI, including the Ctrl+G menu
Add bone collections to the outliner (replacing the current list of bone groups)
Operators to move/add selected bones to a collection:
- move to collection (similar to 'm' for objects & collections, from viewport)
- add to collection (similar to 'shift+m' for objects & collections, from viewport)
Select Similar operator (by collection, by color) / Shift+G menu
Fixing the Collada I/O, as that also handles bone layers (83306754d4).
Make bone collections on linked-but-not-overridden armatures usable. The object itself may be overridden, so changing the active bone collection should work (even when it cannot be saved), and then 'Select Bones' and 'Deselect Bones' operators should work.

Potential push back to later:

Add selectability toggles to bone collections (only for pose mode)
Add armature-global override to selectability, so that a rigger can still opt to select all the bones, then lock them down for animators.
Managing bone assignments to collections from the outliner.

This design describes the replacement of armature _bone layers_ & _bone groups_ with a new _bone collections_ system. Implementation is in #109976 and #112271, with feedback from Demeter in #116795. ## Goals - Named collections, instead of numbered layers, should give a better indication as to what the collection contains / is for. - Increased flexibility in number of collections. - More similarity to the scene object collections, including features like 'not selectable' which can increase clarity of how to use a rig by animators. - Compatibility with library overrides, so that new shot-specific bone collections can be added. - Unification of numbered bone layers (for organisation) and named bone groups (for coloring). ## Properties of the System - Armatures have one or more bone collections. - If there is only one collection it cannot be removed. - Every bone is in zero or more bone collections. - Bone collections **cannot be nested**. At least not for 4.0, can be added later. - Bone collections must have a **unique name** within the armature. - Library Overrides: - New bone collections can be added. - Existing ones cannot be reordered / removed. - Bone collections have the following properties: - Name - Selectable: 'set' wins over 'cleared' - Visible: 'set' wins over 'cleared' - `IDProperties` (aka Custom Properties) for use by add-ons. - Bones will get individual color properties. - The color system of bone groups will be used, which allows selection of 'default', 20 theme-defined colors, and a custom RGB value. - Bones have a color defined as part of the armature data. Here 'default' is the default grey color. - Pose Bones have a color defined as part of the object/pose data. Here 'default' means 'uncolored', and will thus show the edit bone color. ## Operations These operations can be performed on/with bone collections: - (De)select one or more collections themselves - (De)select all bones in active collection - (De)select all bones in collections containing the currently selected bones - Create a new collection - Delete a collection. Bones in the collection that are now 'orphaned' are assigned to the 'default' collection. - Move collection up/down in the list. - Move selected bone(s) to a collection. - Select Bones of Same Color. ## User Interface For Blender 4.0 the UI is kept intentionally simple. I'm thinking of reusing the Bone Groups interface, with the addition of a few per-collection icons (visible, selectable, color palette) as well as an indicator of which collection(s) contain the selected bone(s). ## Conversion from Old to New - Layers converted to `Layer {NUM}` collections. - Bone groups converted to `{name}` collections. - Selection Sets converted to `SelSet {name}` collections. - Maybe even automatically merge these when they contain the same bones? ## Uses of the Current System ### Bone Layers - Visibility - Logical grouping ### Bone Groups - Coloring of logical groups - Set by rigger ### Edit Mode vs. Pose Mode This describes Blender's **current** behavior: | Property / Action | Edit | Pose | |---------------------------------------|------|------| | Name Bone | ✅ | ✅ | | Set Bone Layers | ✅ | ✅ | | See Bone in Group Color | ❌ ¹⁾ | ✅ | | Create / Assign Bone Group | ❌ ¹⁾ | ✅ | | Select Bones in Group | ❌ ¹⁾ | ✅ | | Set Bone Group Color | ✅ | ✅ | | Set Armature Viewport Display options | ✅ | ✅ | | Set Bone Viewport Display options | ❌ ²⁾ | ✅ | ¹⁾ The new system should allow these in Edit mode too. ²⁾ Bones can only be hidden, which is separated between edit mode & pose mode. ## Future Work These are ideas for future improvements / extensions: - Nestable bone collections. - Integration with the Outliner. - Per-collection option whether bones are deforming or not (rather than setting that per bone) - Per-collection viewport display mode (octo, line, bbone, etc) - Possibly unification of Selection Sets as well. ## Code Location This work will kickstart a new module in `source/blender/animrig`. This will become the place for new animation/rigging related code. The intention is that also a subset of the already-existing animation-related code from both `blenkernel` and `editors` is going to move there, to help clean up the API and make it more consistent. ------------------------- ## Ongoing Work **Targets for 4.0-bcon1: tracked in #109976** **Targets that could be pushed back to 4.0-bcon2:** - [x] Add ID Properties support to bone collections, including a UI. - [x] Removal of bone group RNA access & UI - [x] Ensure that library overrides can add new bone collections & assign bones to them (#112271) - [x] Removal of bone groups from the UI, including the Ctrl+G menu - [x] Add bone collections to the outliner (replacing the current list of bone groups) - [x] Operators to move/add selected bones to a collection: - [x] move to collection (similar to 'm' for objects & collections, from viewport) - [x] add to collection (similar to 'shift+m' for objects & collections, from viewport) - [x] Select Similar operator (by collection, by color) / Shift+G menu - [x] Fixing the Collada I/O, as that also handles bone layers (83306754d48). - [x] Make bone collections on linked-but-not-overridden armatures usable. The object itself may be overridden, so changing the active bone collection should work (even when it cannot be saved), and then 'Select Bones' and 'Deselect Bones' operators should work. **Potential push back to later:** - [ ] Add selectability toggles to bone collections (only for pose mode) - [ ] Add armature-global override to selectability, so that a rigger can still opt to select all the bones, then lock them down for animators. - [ ] Managing bone assignments to collections from the outliner.

🎉 5 🚀 1

Sybren A. Stüvel added the

labels 2023-06-13 17:08:42 +02:00

Sybren A. Stüvel added this to the 4.0 milestone 2023-06-13 17:08:46 +02:00

Sybren A. Stüvel added this to the Animation & Rigging project 2023-06-13 17:08:49 +02:00

Sybren A. Stüvel self-assigned this 2023-06-13 17:08:54 +02:00

Christoph Lendenfeld commented

2023-06-13 18:05:24 +02:00

if collections are used for coloring
and a bone can be in multiple collections
what defines the color of the bone

if collections are used for coloring and a bone can be in multiple collections what defines the color of the bone

Brecht Van Lommel commented

2023-06-13 18:46:13 +02:00

This all seems reasonable.

Some questions that spring to mind:

Does this mean there are no plans to turn bones into objects? Because that would make this work redundant. Personally I prefer to keep bones as they are, as a type of geometry that could potentially be manipulated by geometry nodes in the future.
In the outliner bones are display with parenting hierarchy now. I wonder if that will change to use collections, or if there will be some option to switch, or even have a way to display both combined as we do for objects.
For meshes there is the concept of face sets, for hair there was a plan to add curve sets. In that sense, grouping of subsets of geometry could consistently be called sets. Though this also seems more similar to object collections, so I think that name is fine.

This all seems reasonable. Some questions that spring to mind: * Does this mean there are no plans to turn bones into objects? Because that would make this work redundant. Personally I prefer to keep bones as they are, as a type of geometry that could potentially be manipulated by geometry nodes in the future. * In the outliner bones are display with parenting hierarchy now. I wonder if that will change to use collections, or if there will be some option to switch, or even have a way to display both combined as we do for objects. * For meshes there is the concept of face sets, for hair there was a plan to add curve sets. In that sense, grouping of subsets of geometry could consistently be called sets. Though this also seems more similar to object collections, so I think that name is fine.

👍 1 ❤️ 1

Nathan Vegdahl commented

2023-06-13 19:19:52 +02:00

Does this mean there are no plans to turn bones into objects? Because that would make this work redundant. Personally I prefer to keep bones as they are, as a type of geometry that could potentially be manipulated by geometry nodes in the future.

There's no current plan. That's more a personal fantasy of mine. Realistically, I doubt that will happen for Animation 2025.

I still have hopes that it could happen some time post-Animation-2025, but you're certainly right that there are trade-offs involved there that would need serious consideration.

> Does this mean there are no plans to turn bones into objects? Because that would make this work redundant. Personally I prefer to keep bones as they are, as a type of geometry that could potentially be manipulated by geometry nodes in the future. There's no current plan. That's more a personal fantasy of mine. Realistically, I doubt that will happen for Animation 2025. I still have hopes that it could happen some time post-Animation-2025, but you're certainly right that there are trade-offs involved there that would need serious consideration.

Sybren A. Stüvel commented

2023-06-15 11:50:37 +02:00

Does this mean there are no plans to turn bones into objects?

As Nathan said, this would require quite a bit of design work, as we'd still want to keep the 'namespacing' aspects of armatures, as well as the reusability between different characters. What we are pondering on is more unification of tooling, and maybe expose new APIs to make such tooling easier, so that what's now limited to pose mode/bones (like 'blend to neighbour') can be applied to objects as well.

The animation workshop in 1½ weeks should end in a presentation about more concrete plans for the project, which should clear up confusions like this.

Because that would make this work redundant. Personally I prefer to keep bones as they are, as a type of geometry that could potentially be manipulated by geometry nodes in the future.

👍

In the outliner bones are display with parenting hierarchy now. I wonder if that will change to use collections, or if there will be some option to switch, or even have a way to display both combined as we do for objects.

I'll include that in the 'Future Works' section, as that's indeed something we've discussed, but not yet come to a concrete design/plan for yet.

For meshes there is the concept of face sets, for hair there was a plan to add curve sets. In that sense, grouping of subsets of geometry could consistently be called sets. Though this also seems more similar to object collections, so I think that name is fine.

We'll have a think about this, maybe before we actually get around to merging we rename things to 'bone sets' instead.

> * Does this mean there are no plans to turn bones into objects? As Nathan said, this would require quite a bit of design work, as we'd still want to keep the 'namespacing' aspects of armatures, as well as the reusability between different characters. What we are pondering on is more unification of tooling, and maybe expose new APIs to make such tooling easier, so that what's now limited to pose mode/bones (like 'blend to neighbour') can be applied to objects as well. The animation workshop in 1½ weeks should end in a presentation about more concrete plans for the project, which should clear up confusions like this. > Because that would make this work redundant. Personally I prefer to keep bones as they are, as a type of geometry that could potentially be manipulated by geometry nodes in the future. :+1: > * In the outliner bones are display with parenting hierarchy now. I wonder if that will change to use collections, or if there will be some option to switch, or even have a way to display both combined as we do for objects. I'll include that in the 'Future Works' section, as that's indeed something we've discussed, but not yet come to a concrete design/plan for yet. > * For meshes there is the concept of face sets, for hair there was a plan to add curve sets. In that sense, grouping of subsets of geometry could consistently be called sets. Though this also seems more similar to object collections, so I think that name is fine. We'll have a think about this, maybe before we actually get around to merging we rename things to 'bone sets' instead.

Sybren A. Stüvel referenced this issue

2023-06-15 12:29:35 +02:00

Breaking changes for 4.0 #105523

Sybren A. Stüvel commented

2023-06-15 12:43:23 +02:00

About the name, I just had a little back-and-forth with @JulianEisel and he made a good point: with face sets the hierarchy doesn't matter, it's just a flat list of 'this set contains these faces'. This 'there is no hierarchy' aspect for him maps to the term 'sets', whereas the intention here is to have (eventually) a hierarchy. This matches the existing 'collections' concept better. On top of that, the operations (set selectability, visibility) matches the scene collections.

So let's keep the 'bone collections' name.

About the name, I just had a little back-and-forth with @JulianEisel and he made a good point: with face sets the hierarchy doesn't matter, it's just a flat list of 'this set contains these faces'. This 'there is no hierarchy' aspect for him maps to the term 'sets', whereas the intention here is to have (eventually) a hierarchy. This matches the existing 'collections' concept better. On top of that, the operations (set selectability, visibility) matches the scene collections. So let's keep the 'bone collections' name.

👍 2

Sybren A. Stüvel referenced this issue

2023-07-11 17:49:52 +02:00

Replace Bone Layers+Groups with Bone Collections #109976

Sybren A. Stüvel commented

2023-07-24 10:56:27 +02:00

After various discussions (mostly in A&R module meetings) we've come to the following changes:

No more implicit 'default' bone collection. This simplifies the data model, and also makes things more predictable when working with library overrides. For example, when a liboverride adds new bone collections, bones can be added to those without influencing any original bone collections.
No more colors on the bone collections. Colors are going to be stored on the armature bones, and as a separate property on the pose bones. The 'default' color for pose bones will simply show the armature bone's color. 'Copy to Selected' will be supported, just as a 'Select Bones of Same Color' operator.
An Armature-global option will be added, to enable/disable the per-collection selectability. This is like a switch to toggle between 'rigger mode' (everything is selectable) and 'animator mode' ('selectable' setting of their collections is in effect).

After various discussions (mostly in A&R module meetings) we've come to the following changes: - No more implicit 'default' bone collection. This simplifies the data model, and also makes things more predictable when working with library overrides. For example, when a liboverride adds new bone collections, bones can be added to those without influencing any original bone collections. - No more colors on the bone collections. Colors are going to be stored on the armature bones, and as a separate property on the pose bones. The 'default' color for pose bones will simply show the armature bone's color. 'Copy to Selected' will be supported, just as a 'Select Bones of Same Color' operator. - An Armature-global option will be added, to enable/disable the per-collection selectability. This is like a switch to toggle between 'rigger mode' (everything is selectable) and 'animator mode' ('selectable' setting of their collections is in effect).

Sybren A. Stüvel referenced this issue

2023-07-27 14:51:34 +02:00

Refactor: Anim, abstractions for armature layers #110533

Sybren A. Stüvel referenced this issue from a commit

2023-07-27 14:57:23 +02:00

Refactor: Anim, abstractions for armature layers

Adam Earle commented

2023-07-28 04:08:55 +02:00

@dr.sybren I have nothing really to offer except curiosity.

Grease Pencil use to have a way of assigning colors to layers (Not intuitive and kinda hidden). It was basically a simple swatch of color when clicked that would bring up a color picker menu. The Grease pencils feature didn't color the layer in properties, however, the color would show up in the dope sheet (was incredibly handy).

A similar system may be able to be used for bones simplifying the process. Users could select multiple bones then the user would alt-click the swatch to change the colour to change multiple bones colors at a time. Making the colors visible in the dopesheet and the curve editor as an option would be super handy as well.

@brecht having bones be a geometry would make setting up handles for rigs way easier to deal with. The user would be able to cut up their geometry, separate it by parts, and then join it to the bone. This would make the armature look like the bone. This might also improve weight painting as well because the bone is the mesh you are rigging. Still a lot of steps in the setup but handy to have around.

I wonder if Facemaps could be utilized in this area?

@dr.sybren I have nothing really to offer except curiosity. Grease Pencil use to have a way of assigning colors to layers (Not intuitive and kinda hidden). It was basically a simple swatch of color when clicked that would bring up a color picker menu. The Grease pencils feature didn't color the layer in properties, however, the color would show up in the dope sheet (was incredibly handy). A similar system may be able to be used for bones simplifying the process. Users could select multiple bones then the user would alt-click the swatch to change the colour to change multiple bones colors at a time. Making the colors visible in the dopesheet and the curve editor as an option would be super handy as well. @brecht having bones be a geometry would make setting up handles for rigs way easier to deal with. The user would be able to cut up their geometry, separate it by parts, and then join it to the bone. This would make the armature look like the bone. This might also improve weight painting as well because the bone is the mesh you are rigging. Still a lot of steps in the setup but handy to have around. I wonder if Facemaps could be utilized in this area?

Adam Earle commented

2023-07-28 04:39:32 +02:00

here is where you can find the grease pencil channel colors

here is where you can find the grease pencil channel colors ![image](/attachments/e0b33d0c-c2b5-4187-97dc-226971f218d9)

image.png

433 KiB

Demeter Dzadik commented

2023-07-31 19:25:54 +02:00

I wonder how we can provide the ability for users to change the colors of a set of already similarly colored bones at the same time, like they can do today.

An operator to "force the selection" of bones with similar colors won't really do the trick, since bones can be unselectable.

So, a better solution would be a pop-up menu operator with color pickers that affect all bones with a similar color as the active bone at the time the operator is invoked. As we change the colors in the pop-up, we see live feedback in the 3D view. Hidden and un-selected bones are also affected. And this last sentence hurts a bit, because that is not really how Blender usually works, which makes this sound more like an add-on behaviour.

But I do think we should be able to have all the power of the old behaviour without having to enable add-ons, which is why I think this should be a built-in operator. Perhaps make it explicit in the operator UI that this is affecting all bones, not just the selected ones.

(De)select all bones in collections containing the currently selected bones

This is similar to today's "Select Similar (Shift+G) -> Layer" operator, which has a big problem: If your bone is in many layers, this operator will always select more things than you would ever intend.

I would propose this should instead provide a list of the collections that the bone is in, and have the user specify just one of those, which they want to select.

This could then have some settings; Do you just want to select the bones in this collection that are already visible? Or do you want to unhide the ones that are hidden (even if that means un-hiding some collections)? What about hiding bones that aren't part of this collection?

If all those options can be supported (and perhaps more), then we don't need SelectionSets anymore, either. And my sentiments from earlier apply here too: I hope these (imo basic) things can be a part of core Blender, instead of having to enable an add-on.

I attached a video of some custom UI that I've been using for years to manage my bone groups. May it inspire. I won't embed it since it's not really relevant, it really is just meant as a vague inspiration.

I wonder how we can provide the ability for users to change the colors of a set of already similarly colored bones at the same time, like they can do today. An operator to "force the selection" of bones with similar colors won't really do the trick, since bones can be unselectable. So, a better solution would be a pop-up menu operator with color pickers that affect all bones with a similar color as the active bone at the time the operator is invoked. As we change the colors in the pop-up, we see live feedback in the 3D view. Hidden and un-selected bones are also affected. And this last sentence hurts a bit, because that is not really how Blender usually works, which makes this sound more like an add-on behaviour. But I do think we should be able to have all the power of the old behaviour without having to enable add-ons, which is why I think this should be a built-in operator. Perhaps make it explicit in the operator UI that this is affecting all bones, not just the selected ones. -------- > (De)select all bones in collections containing the currently selected bones This is similar to today's "Select Similar (Shift+G) -> Layer" operator, which has a big problem: If your bone is in many layers, this operator will always select more things than you would ever intend. I would propose this should instead provide a list of the collections that the bone is in, and have the user specify just one of those, which they want to select. This could then have some settings; Do you just want to select the bones in this collection that are already visible? Or do you want to unhide the ones that are hidden (even if that means un-hiding some collections)? What about hiding bones that aren't part of this collection? If all those options can be supported (and perhaps more), then we don't need SelectionSets anymore, either. And my sentiments from earlier apply here too: I hope these (imo basic) things can be a part of core Blender, instead of having to enable an add-on. -------- I attached a video of some custom UI that I've been using for years to manage my bone groups. May it inspire. I won't embed it since it's not really relevant, it really is just meant as a vague inspiration.

2023-07-31 18-47-53.mp4

1.4 MiB

Sybren A. Stüvel commented

2023-08-17 16:48:45 +02:00

A similar system may be able to be used for bones simplifying the process. Users could select multiple bones then the user would alt-click the swatch to change the colour to change multiple bones colors at a time. Making the colors visible in the dopesheet and the curve editor as an option would be super handy as well.

I've just committed support for 'Copy to Selected' behaviour. The bone colours aren't just a colour swatch though, but allow selection from a set of themable colours. That way individual artists can tweak the colours to their taste / needs (for example to compensate for colour blindness).

@brecht having bones be a geometry would make setting up handles for rigs way easier to deal with.

Altering what bones are & how they are stored is out of scope for this PR.

> A similar system may be able to be used for bones simplifying the process. Users could select multiple bones then the user would alt-click the swatch to change the colour to change multiple bones colors at a time. Making the colors visible in the dopesheet and the curve editor as an option would be super handy as well. I've just committed support for 'Copy to Selected' behaviour. The bone colours aren't just a colour swatch though, but allow selection from a set of themable colours. That way individual artists can tweak the colours to their taste / needs (for example to compensate for colour blindness). > @brecht having bones be a geometry would make setting up handles for rigs way easier to deal with. Altering what bones are & how they are stored is out of scope for this PR.

Sybren A. Stüvel commented

2023-08-17 16:53:39 +02:00

I wonder how we can provide the ability for users to change the colors of a set of already similarly colored bones at the same time, like they can do today.

An operator to "force the selection" of bones with similar colors won't really do the trick, since bones can be unselectable.

So, a better solution would be a pop-up menu operator with color pickers that affect all bones with a similar color as the active bone at the time the operator is invoked. As we change the colors in the pop-up, we see live feedback in the 3D view. Hidden and un-selected bones are also affected. And this last sentence hurts a bit, because that is not really how Blender usually works, which makes this sound more like an add-on behaviour.

But I do think we should be able to have all the power of the old behaviour without having to enable add-ons, which is why I think this should be a built-in operator. Perhaps make it explicit in the operator UI that this is affecting all bones, not just the selected ones.

Those are good points, I'd have to think about a good solution here.

I would propose this should instead provide a list of the collections that the bone is in, and have the user specify just one of those, which they want to select.

Sounds good.

This could then have some settings; Do you just want to select the bones in this collection that are already visible? Or do you want to unhide the ones that are hidden (even if that means un-hiding some collections)? What about hiding bones that aren't part of this collection?

If all those options can be supported (and perhaps more), then we don't need SelectionSets anymore, either. And my sentiments from earlier apply here too: I hope these (imo basic) things can be a part of core Blender, instead of having to enable an add-on.

Again, good points.

I attached a video of some custom UI that I've been using for years to manage my bone groups. May it inspire. I won't embed it since it's not really relevant, it really is just meant as a vague inspiration.

That looks pretty nice.

For now I'm trying to get the basics of the basics in, with the right data-model and versioning code to make sure files are converted properly. After that we can definitely do a less-vague inspiration session to see what kind of nice tooling we can build on top of this.

> I wonder how we can provide the ability for users to change the colors of a set of already similarly colored bones at the same time, like they can do today. > > An operator to "force the selection" of bones with similar colors won't really do the trick, since bones can be unselectable. > > So, a better solution would be a pop-up menu operator with color pickers that affect all bones with a similar color as the active bone at the time the operator is invoked. As we change the colors in the pop-up, we see live feedback in the 3D view. Hidden and un-selected bones are also affected. And this last sentence hurts a bit, because that is not really how Blender usually works, which makes this sound more like an add-on behaviour. > > But I do think we should be able to have all the power of the old behaviour without having to enable add-ons, which is why I think this should be a built-in operator. Perhaps make it explicit in the operator UI that this is affecting all bones, not just the selected ones. Those are good points, I'd have to think about a good solution here. > I would propose this should instead provide a list of the collections that the bone is in, and have the user specify just one of those, which they want to select. Sounds good. > This could then have some settings; Do you just want to select the bones in this collection that are already visible? Or do you want to unhide the ones that are hidden (even if that means un-hiding some collections)? What about hiding bones that aren't part of this collection? > > If all those options can be supported (and perhaps more), then we don't need SelectionSets anymore, either. And my sentiments from earlier apply here too: I hope these (imo basic) things can be a part of core Blender, instead of having to enable an add-on. Again, good points. > I attached a video of some custom UI that I've been using for years to manage my bone groups. May it inspire. I won't embed it since it's not really relevant, it really is just meant as a vague inspiration. That looks pretty nice. For now I'm trying to get the basics of the basics in, with the right data-model and versioning code to make sure files are converted properly. After that we can definitely do a less-vague inspiration session to see what kind of nice tooling we can build on top of this.

Nathan Vegdahl referenced this issue from a commit

2023-08-29 14:31:31 +02:00

Anim: move bone colors from bone groups to individual bones

Nathan Vegdahl referenced this issue from a commit

2023-08-29 14:31:31 +02:00

Anim: replace Bone Groups & Armature Layers with Bone Collections

Alexander Gavrilov commented

2023-08-31 21:19:27 +02:00

Some python API addition ideas:

Maybe bone.collections.clear() to remove the bone from all collections (although it's redundant to set([])).
bone.collections.set([...]) to replace the collection list, mainly so you can do bone1.collections.set(bone2.collections) instead of bone1.layers = bone2.layers, but obviously also allow a python list argument. Maybe also allow set([...], replace=False) (or append=True) to support batch add.
Some kind of collection.bones to retrieve all bones belonging to the collection - they seem to actually already have that data, although it's not up to date in edit mode (maybe check the mode and throw an exception then?..).

Some python API addition ideas: * Maybe `bone.collections.clear()` to remove the bone from all collections (although it's redundant to `set([])`). * `bone.collections.set([...])` to replace the collection list, mainly so you can do `bone1.collections.set(bone2.collections)` instead of `bone1.layers = bone2.layers`, but obviously also allow a python list argument. Maybe also allow `set([...], replace=False)` (or `append=True`) to support batch add. * Some kind of `collection.bones` to retrieve all bones belonging to the collection - they seem to actually already have that data, although it's not up to date in edit mode (maybe check the mode and throw an exception then?..).

👍 2 ❤️ 1

Sybren A. Stüvel referenced this issue from a commit

2023-09-07 16:52:19 +02:00

Anim: add bone collection custom properties sub-panel

Sybren A. Stüvel referenced this issue from a commit

2023-09-08 12:18:21 +02:00

Anim: remove RNA access to bone groups

Sybren A. Stüvel referenced this issue

2023-09-12 10:46:13 +02:00

WIP: Bone Collections library override support #112271

Sybren A. Stüvel referenced this issue

2023-09-22 11:16:40 +02:00

Bone Collections: UI Improvements #112710

Apraxas commented

2023-09-28 10:50:04 +02:00

Hello there! Thank you for the work on the new bone collections.

In blender 3.6 and earlier, you are able to hide all layers but the one you need by simply clicking on it, and you can make several layers visible or not with ctrl or shift.

However, I can't find a way to reproduce this behavior with the new system in 4.0

If I have 10 bone collections and I want to see only collection 6 for example, how do I hide all the others collections without having to click the eye for each and every one?

I know it is possible to slide the mouse over the eyes on all groups while holding click to disable them quickly, but this wouldn't really work when the groups I want to see are separated.

Hello there! Thank you for the work on the new bone collections. In blender 3.6 and earlier, you are able to hide all layers but the one you need by simply clicking on it, and you can make several layers visible or not with ctrl or shift. However, I can't find a way to reproduce this behavior with the new system in 4.0 If I have 10 bone collections and I want to see only collection 6 for example, how do I hide all the others collections without having to click the eye for each and every one? I know it is possible to slide the mouse over the eyes on all groups while holding click to disable them quickly, but this wouldn't really work when the groups I want to see are separated.

Sybren A. Stüvel commented

2023-09-28 14:40:08 +02:00

In blender 3.6 and earlier, you are able to hide all layers but the one you need by simply clicking on it, and you can make several layers visible or not with ctrl or shift.

However, I can't find a way to reproduce this behavior with the new system in 4.0

Good point, that was an oversight. It's there now:

> In blender 3.6 and earlier, you are able to hide all layers but the one you need by simply clicking on it, and you can make several layers visible or not with ctrl or shift. > > However, I can't find a way to reproduce this behavior with the new system in 4.0 Good point, that was an oversight. It's there now: ![image](/attachments/e9739793-1480-4049-9905-44f182f76122)

image.png

12 KiB

👍 1 🎉 2

Nika Kutsniashvili commented

2023-09-28 16:54:56 +02:00

In Pose mode Ctrl-~ (tilda) shortcut is still there for enabling all layers, but doesn't work on collections and expects old RNA.

I would also suggest changing it to other shortcut since Ctrl-~ is toggle gizmos in 3D viewport, and quite an useful shortcut, comes into conflict with this. Perhaps since Shift-M is for collections Alt-M could be the key, similar to Alt-H - reveal all.

In Pose mode Ctrl-~ (tilda) shortcut is still there for enabling all layers, but doesn't work on collections and expects old RNA. I would also suggest changing it to other shortcut since Ctrl-~ is toggle gizmos in 3D viewport, and quite an useful shortcut, comes into conflict with this. Perhaps since Shift-M is for collections Alt-M could be the key, similar to Alt-H - reveal all.

Sybren A. Stüvel commented

2023-10-02 12:08:59 +02:00

In Pose mode Ctrl-~ (tilda) shortcut is still there for enabling all layers, but doesn't work on collections and expects old RNA.

This was fixed in d6b86f278b, thanks for reporting.

I would also suggest changing it to other shortcut since Ctrl-~ is toggle gizmos in 3D viewport, and quite an useful shortcut, comes into conflict with this. Perhaps since Shift-M is for collections Alt-M could be the key, similar to Alt-H - reveal all.

The toggling of gyzmos is a single click in the 3D viewport header, so I don't think it's that important to have a hotkey for it. For this particular case I feel it might be better to keep the hotkeys as similar to what they were, to keep people's muscle memory intact.

> In Pose mode Ctrl-~ (tilda) shortcut is still there for enabling all layers, but doesn't work on collections and expects old RNA. This was fixed in d6b86f278b606f9046ef383c52eda897133c48e3, thanks for reporting. > I would also suggest changing it to other shortcut since Ctrl-~ is toggle gizmos in 3D viewport, and quite an useful shortcut, comes into conflict with this. Perhaps since Shift-M is for collections Alt-M could be the key, similar to Alt-H - reveal all. The toggling of gyzmos is a single click in the 3D viewport header, so I don't think it's *that* important to have a hotkey for it. For this particular case I feel it might be better to keep the hotkeys as similar to what they were, to keep people's muscle memory intact.

Sybren A. Stüvel referenced this issue

2023-12-08 12:15:25 +01:00

Hierarchical Bone Collections #115934

Demeter Dzadik referenced this issue

2024-01-04 17:59:46 +01:00

Nested Bone Collections 4.1 Notes #116795

Sybren A. Stüvel commented

2024-01-09 14:38:22 +01:00

Since this has all landed and was targeting Blender 4.0, I'll close this. Further work will use its own tracking tasks.

🎉 2

Sybren A. Stüvel closed this issue

2024-01-09 14:38:29 +01:00