Batch Rename Operator's lacking additional features for user-defined organisation of numerical (e.g., 001, 002) reassignment on the Bones in the Selection #109142

New Issue

Pxy-Gnomes · 2023-06-19T23:07:35+02:00

Pxy-Gnomes commented

2023-06-19 23:07:35 +02:00

System Information
Operating system: Windows-10-10.0.22621-SP0 64 Bits
Graphics card: AMD Radeon(TM) Graphics ATI Technologies Inc. 4.5.0 Core Profile Context 23.4.3.230420

Blender Version
Broken: version: 3.3.7, branch: master, commit date: 2023-05-22 12:03, hash: 659c307f2502
Worked: Never developed feature I guess.

Short description of error
This problem arises when we are trying to Batch-Rename a bigger Selection of Bones, and we want to assign numerical naming to them (such as Bone.001, Bone.002, Bone.003...), but, additionally, we want to logically order/reorder which Bone will start with "001" and which other Bones in 3D space will then get the other names "002", "003", etc.

Particularly, when we Batch Rename the same Selection of Bones (all the Bones in given file) with the follow settings:
Selected: Bones
Type: Set Name
Method: New
Name: e.g., Bone.001 or Bone
and that we want to order these number names to 'swap' between the Bones in different, useful orders (for example, imagine, opening the file, that we just want to Batch Rename the Bones so that they are named Bone.001 to Bone.007, but on an inverse order: that is, in the 3D Viewport, from right to left instead of from left to right). So, what I've learned by accident is taht we can actually Batch Rename [Ctrl+F2] the same Bone Selection, with exactly the same settings, applied over and over again (iterations of the Batch Rename Operator); and this will make those number names to swap (and sometimes this is very helpful in [re]organising a project), however, if we keep doing that (iterations), what we see is the emergence of a strange cyclic pattern, that is actually very specific and hard to understand at first; unfortunately, this pattern is not that useful for multiple reasons in reorganisation, as it seems to be controlled only by (what I assume could be) the Bones' Indices ("IDs"), which are not very accessible nor very controllable, and we certainly do not have features in Batch Rename which relate in a clear and directive way to the Bone's Indices. Originally, I did expect Bone Parenting hierarchy, if any, would help in some sort, in terms of smart automation, of the Batch Rename feature; or, perhaps, the order in which the Bone Selection was made for a current use of the Batch Rename Operator would have an effect; or, at least, the Active element in that Bone Selection would have and influence. However, apparently, none of these factors seem to apply or be consistent: only the order in which the Bones were originally Added to the Armature Object [so, an ID/Index thing for the Bones?] seems to have an effect in the pattern which emerges from the iteration of the Batch Rename Operator on such settings for the same Bone Selection.
Moreover (annother very peculiar and annoying limitation): the "001" will NEVER swap place! differently from the other number names. So, to give the name "Bone.001" to, for exemple, the Bone on the opposite side (which is not the 1st Bone with the earliest Index in my file), we can't just Batch Rename to get this job done (especially not, if there is already a Bone named "Bone.001" name in the Armature Object and that we want to keep this exact Name structure "Bone.###").

Exact steps for others to reproduce the error

Please, open the Blend file.
Select All the Bones and Batch Rename with the following settings:
Selected: Bones
Type: Set Name
Method: New
Name: give something like Bone.001 (could be just Bone) or Test.001 (could be just Test)
OK on the Operator, see how the Bones were Renamed;
Once again, command another Batch Rename Operator [Ctrl+F2], keeping exactly the same settings (so this time just press OK);
Observe the output;
Keep re-iterating, and try to understand the pattern that shall emerge from it (is this really about Bones' Indices/ID only? Can we spot this data for Bones in the UI? Can't we swap Bones' Indices as well between themselves?). See if the Bones' Names 'swapping' could attend to different, some very specific reordering that we might wish to obtain in an automated way (like, in my example of an inverse ordering.

So, in clonclusion: it took me months to come up with an hypothesis about the emerging pattern and to finally assume it might be relevant to Report it as... 'something odd and worth Reporting'. I understand it is probably not a bug after all, but originally it sounded very random. But most importantly I thinl: whatever logic the pattern is based upon, it is not a versatile pattern in relation to all the cool possibilities the Batch Remame Operator on a Multi-Selection can do; so it does look like it could require some assessment. Thank you for your attention and sorry for the excessive amount of information on such very specific use of the feature.

**System Information** Operating system: Windows-10-10.0.22621-SP0 64 Bits Graphics card: AMD Radeon(TM) Graphics ATI Technologies Inc. 4.5.0 Core Profile Context 23.4.3.230420 **Blender Version** Broken: version: 3.3.7, branch: master, commit date: 2023-05-22 12:03, hash: `659c307f2502` Worked: Never developed feature I guess. **Short description of error** This problem arises when we are trying to Batch-Rename a bigger Selection of Bones, and we want to assign numerical naming to them (such as Bone.001, Bone.002, Bone.003...), but, additionally, we want to logically order/reorder which Bone will start with "001" and which other Bones in 3D space will then get the other names "002", "003", etc. Particularly, when we Batch Rename the same Selection of Bones (all the Bones in given file) with the follow settings: **Selected: Bones Type: Set Name Method: New** **Name:** e.g., **Bone.001** or **Bone** and that we want to order these number names to 'swap' between the Bones in different, useful orders (for example, imagine, opening the file, that we just want to Batch Rename the Bones so that they are named Bone.001 to Bone.007, but on an inverse order: that is, in the 3D Viewport, from right to left instead of from left to right). So, what I've learned by accident is taht we can actually Batch Rename [Ctrl+F2] the same Bone Selection, with exactly the same settings, applied over and over again (iterations of the Batch Rename Operator); and this will make those number names to swap (and sometimes this is very helpful in [re]organising a project), however, if we keep doing that (iterations), what we see is the emergence of a strange cyclic pattern, that is actually very specific and hard to understand at first; unfortunately, this pattern is not that useful for multiple reasons in reorganisation, as it seems to be controlled only by (what I assume could be) the Bones' Indices ("IDs"), which are not very accessible nor very controllable, and we certainly do not have features in Batch Rename which relate in a clear and directive way to the Bone's Indices. Originally, I did expect Bone Parenting hierarchy, if any, would help in some sort, in terms of smart automation, of the Batch Rename feature; or, perhaps, the order in which the Bone Selection was made for a current use of the Batch Rename Operator would have an effect; or, at least, the Active element in that Bone Selection would have and influence. However, apparently, none of these factors seem to apply or be consistent: only the order in which the Bones were originally Added to the Armature Object [so, an ID/Index thing for the Bones?] seems to have an effect in the pattern which emerges from the iteration of the Batch Rename Operator on such settings for the same Bone Selection. Moreover (annother very peculiar and annoying limitation): the "001" will NEVER swap place! differently from the other number names. So, to give the name "Bone.001" to, for exemple, the Bone on the opposite side (which is not the 1st Bone with the earliest Index in my file), we can't just Batch Rename to get this job done (especially not, if there is already a Bone named "Bone.001" name in the Armature Object and that we want to keep this exact Name structure "Bone.###"). **Exact steps for others to reproduce the error** 1) Please, open the Blend file. 2) Select All the Bones and Batch Rename with the following settings: **Selected: Bones Type: Set Name Method: New** **Name:** give something like **Bone.001** (could be just **Bone**) or **Test.001** (could be just **Test**) 3) OK on the Operator, see how the Bones were Renamed; 4) Once again, command another Batch Rename Operator [Ctrl+F2], keeping exactly the same settings (so this time just press OK); 5) Observe the output; 6) Keep re-iterating, and try to understand the pattern that shall emerge from it (is this really about Bones' Indices/ID only? Can we spot this data for Bones in the UI? Can't we swap Bones' Indices as well between themselves?). See if the Bones' Names 'swapping' could attend to different, some very specific reordering that we might wish to obtain in an automated way (like, in my example of an inverse ordering. 7. So, in clonclusion: it took me months to come up with an hypothesis about the emerging pattern and to finally assume it might be relevant to Report it as... 'something odd and worth Reporting'. I understand it is probably not a bug after all, but originally it sounded very random. But most importantly I thinl: whatever logic the pattern is based upon, it is not a versatile pattern in relation to all the cool possibilities the Batch Remame Operator on a Multi-Selection can do; so it does look like it could require some assessment. Thank you for your attention and sorry for the excessive amount of information on such very specific use of the feature.

BatchRenamingBoneIndice.blend

921 KiB

Pxy-Gnomes added the

labels 2023-06-19 23:07:35 +02:00

Pratik Borhade commented

2023-06-20 06:46:16 +02:00

Hi, thanks for the report. Can confirm the naming inconsistency. Will check from code side how renaming is handled.

Pratik Borhade commented

2023-06-20 08:16:30 +02:00

This is indeed working as expected, codewise.

as it seems to be controlled only by (what I assume could be) the Bones' Indices ("IDs")

Bones are itterated as the sequnence shown in outliner.
In code, list of bones is accessed with this code block: https://projects.blender.org/blender/blender/src/branch/main/scripts/startup/bl_operators/wm.py#L2735

>>> for ob in C.objects_in_mode_unique_data:
...     for ebone in ob.data.edit_bones:
...         print(ebone)

what we see is the emergence of a strange cyclic pattern

The cyclic pattern is because we check for unique name twice: https://projects.blender.org/blender/blender/src/branch/main/source/blender/blenlib/intern/string_utils.c#L252
BLI_uniquename_cb call-back function is called from ED_armature_ebone_unique_name

Explaination for cyclic pattern:

consider you've batch renamed set of bones for first time.

On next attempt of batch rename, bone which has name test.001 will find duplicate bones (unique_check function in above link) because names till .005 are taken.
So test.001 bone will find unique name at .006 (new name will be test.006)

test.002 gets unique name with .001 suffix because we don't have any bone with same prefix (we had bone with same name earlier which is now renamed to .006 as said in above paragraph)

And this pattern continues for every next bone.

the "001" will NEVER swap place! differently from the other number names. So, to give the name "Bone.001" to, for exemple, the Bone on the opposite side

I did not understand this part. Do you mean name of a specific bone is not changing when new name entered during batch-rename and current name of particular bone is same?

Maybe this behavior of renaming can be improved. Forwardinng this to devs for further decision

This is indeed working as expected, codewise. > as it seems to be controlled only by (what I assume could be) the Bones' Indices ("IDs") Bones are itterated as the sequnence shown in outliner. In code, list of bones is accessed with this code block: https://projects.blender.org/blender/blender/src/branch/main/scripts/startup/bl_operators/wm.py#L2735 ``` >>> for ob in C.objects_in_mode_unique_data: ... for ebone in ob.data.edit_bones: ... print(ebone) ``` - - - > what we see is the emergence of a strange cyclic pattern The cyclic pattern is because we check for unique name twice: https://projects.blender.org/blender/blender/src/branch/main/source/blender/blenlib/intern/string_utils.c#L252 `BLI_uniquename_cb` call-back function is called from `ED_armature_ebone_unique_name` Explaination for cyclic pattern: consider you've batch renamed set of bones for first time. On next attempt of batch rename, bone which has name `test.001` will find duplicate bones (`unique_check` function in above link) because names till `.005` are taken. So `test.001` bone will find unique name at `.006` (new name will be test.006) test.002 gets unique name with .001 suffix because we don't have any bone with same prefix (we had bone with same name earlier which is now renamed to .006 as said in above paragraph) And this pattern continues for every next bone. - - - > the "001" will NEVER swap place! differently from the other number names. So, to give the name "Bone.001" to, for exemple, the Bone on the opposite side I did not understand this part. Do you mean name of a specific bone is not changing when new name entered during batch-rename and current name of particular bone is same? - - - Maybe this behavior of renaming can be improved. Forwardinng this to devs for further decision

Pratik Borhade added

Module

User Interface

Status

Needs Info from Developers

and removed

Status

Needs Triage

labels 2023-06-20 08:18:35 +02:00

Pratik Borhade added