Improvement to automatic numbering
A lot of software does this really well, so I'm kind of surprised Blender doesn't do this.
In short, if I duplicate or create a new object that has the same name, it will automatically add a ".XXX" number on the end IE: Cube, Cube.001, Cube.002, and so on.
Sometimes though an object might be named using a different convention such as "Obj_01," "Obj-01," "Obj1," etc. It would be nice if Blender could automatically detect the number at the end and increment it.
Actually, depending on if people want this or not, I might just go ahead and implement it myself
13 Comments
Ehh, I don't like this. If I have to write even more code for parsing strings in my addon I'm gonna cuss. It's good to have a single, standard convention.
* @Josephbburg * So conclusion is - you and other people come here and dislike suggestion because of " If I have to write even more code for parsing strings in my addon I'm gonna cuss . It's good to have a single, standard ". We all know that there is no " single standard " and " . " is 100% not even close to this " single " industry standard... Dot is something to separate file name and file extension. To export FBX and get some Object_V01.001.fbx file is nonsense, kind of joke. None of workflows work in this way.
Even if it have someway complicate some addon so what? This motivation sounds like users work in Blender for addons and addon creator... Not addon is created for users to help them do their work.
So if some freelancer get some outsource work and his client want to get object naming like Object_001 - no one care about this user, his work efficiency and his headache with workaround this dot...
Brilliant logic. If problem exist why we have to do something when we can do nothing and just say that there is no problem. With " If I have to write even more code... " logic there is no future for any software.
What a shame to watch on this...
* @IIIFGIII * That wasn't the point I was trying to make at all. I agree with you, the "." doesn't work and isn't common OUTSIDE of Blender -- that was never part of the discussion until now. I've had far too many objects come into Maya with ObjectFBXASC046001 as the name. But the solution is easy- if I can assume all of the objects I'm trying to export have ".###" in their names, then changing them for export is really easy- I can just use the ctrl-F2 batch rename without even opening the Python console.
The dot is used all throughout Blender and it's right to call it the "single standard" in reference to Blender.
What concerns me is this-- keeping Blender organized and predictable. ".000" ".001" ".002" is predictable. I'm thinking about the professionals that use Blender, change an otherwise innocuous looking setting ("Preferred Seperator Character"), and get upset that their addons keep throwing errors. You can't expect every addon developer to change their addons to support arbitrary naming conventions. There's just too many, and it's the kind of thing that's actually not that easy to write because everyone wants to use a different naming scheme. You have to make some assumptions. Maybe Blender's Python API could be extended to include standard functions for managing names- I'd love that. But just remember how long it took people to move over to Blender 2.80 after the API change. Heck, Retopoflow still isn't officially out for 2.8 yet! There was an addon drought for months, and I still have to open up 2.79 for some of my older addons to this day.
The irony is that I actually do support custom separator characters in my addon! It's stored as a JSON file in the addon's install directory, so the user can edit it however they want. (The addon is a rigging tool that has, among other things, a tool for renaming bones, selecting by name, etc.)It's very flexible, but ti does enforce some conventions, too, because I need to be able to predict names and find related bones easily. That's my solution- but someone else may come up with a totally different solution that behaves just differently enough to confuse and frustrate.
I propose this- rename stuff at the end, just before passing it off to the client. It's better than kicking against the goads the whole time you work.
Working in a team with 3dsmax user, .dot is a NO GO for me. We have strict namming convention and forcing user to use addon or script to rename all scene asset is realy annoying. In many usecase with different software interaction .dot create conflict. Renaming is done only at the end for exporting purpose. If some blender plugin only work with dot parsing it's not a problem : if renaming acept to convert underscore to dot and vice vesa, it will be fine. Batch rename find . replace _ is the way
I think the file -> save window's number incrementing buttons already behave this way. It just finds the last number in the string and increments it.
I asked for something like this long time ago - a. people here don't vote for this. b. after so long time I never heard any rumors about any works on this Also post on Devtalks . My last reply where I write that no default separator is sometimes kind of even better than this annoying dot default separator was without answer.
So you can understand it as official reply is something around " go f* your self - no one care, don't wait for any changes ".
* @IIIFGIII * my complaint is that there's no pragmatic reason for not having a separator. There is a very vocal minority that says they don't like it. Okay... I don't like the color green, but I'm not going to cut down all of my trees. It's not a valid reason.
Specifically- what OP is requesting (automatically incrementing ANY object that has a number at the end) is actually problematic for a number of reasons, but one in particular sticks out in my mind: In game development it is not uncommon to name objects based on their dimensions.. units/gridsize/whatever. So, if you have an object called building_a_512x512 and duplicate it, the next one will be called building_a_512x513. My studio uses UE4 and we run into this problem all of the time . It's maddening.. we had to write import scripts to counteract it, and incidentally they name the objects with .001, .002 etc.
Just another friendly reminder that Blender is a 'one size fits all' solution and we can't just go changing functionality like this without understanding the repercussions to all users. It's not "go F* yourself", it's "come up with a better reason because the one you've given is seems esoteric"
* @testure * Workflow wihout separator mean that user name parternt for example Streeplight_V01_ and then all instances becoeme Streeplight_V01_001, Streeplight_V01_002, etc.
With dot if user want to have " _ " as separator in scene and already have renamed structure without " . " but then it need to add new instances Blender don't reconize this Streetlight_V01_125 and add some Streetlight_V01_.126 one. Instead user get Streetlight_V01_.001
It make Blender disgusting soft for those who want or need to have something else than " . " as separator. In this case have no separator is better than " . " separator....
* @IIIFGIII * I disagree. You'd be asking every addon developer to write branches in their code to support this. And parsing strings sucks. It's tedious, boring, and slow, and in the end all it does is stitch letters together. No one wants to spend their time with that when they could be making code for things like meshes, rigs, and materials. It's really helpful to have a general assumption you can always safely rely on.
* @IIIFGIII * I don't care about the separator, make it a ^ for all I care. I'm talking about what the original proposal is about- automatic numbering for any object that ends with a number, which is a terrible idea. If you're hitching your proposal to this wagon, I have to disagree with it as well.. on its own, it's fine.
* @testure * As I understand suggestion - it about to allow Blender recognise different styles of separation and repeat same separation style while duplication.
It can be implemented as array of typical separation cases to recognise. By default this array is empty, but user can add -XX or _XX or any else to it. So now for this user Blender ( maybe even per scene option ) in case of duplicating SomeObject_01 recognise this _01 as numbering separation and create _02 object instead of .001
If it would be implemented in this way as optional clear by defauld, but if user want or need he may add it own rules, both sides would be ok.Blender become even much flexible and powerful software. Current way is too limited and wooden.
* @Josephbburg *
I disagree. You'd be asking every addon developer to write branches in their code to support this. And parsing strings sucks.I agree, but if it were done correctly I don't think it would be a problem. IE) you could have a global app preference for delimiter that is accessed in the same way UI scale is. Parsing '_' isn't inherently any more difficult than '.', it's still just string.split(delimiter)[-1]. Again, my problem with the proposal is incrementing arbitrary objects.
Seems situational.. If I'm working on a model for a 747 I don't want all of my objects ending in 747 being incremented to 748.