Remove indices from objects, groups, materials on export #85056

New Issue

Dodger Cannon · 2021-01-25T21:40:13+01:00

Dodger Cannon commented

2021-01-25 21:40:13 +01:00

System Information
Operating system: Any
Graphics card: Any

Blender Version
Broken: 2.83.5
(example: 2.79b release)
(example: 2.80, edbf15d3c044, blender2.8, 2018-11-28, as found on the splash screen)
Worked: never

Short description of error
Internal numerical indices for objects and materials should NOT be included by default in OBJ export.

Anyone affected by this problem will find their blood pressure spiking if they google how to try and alleviate the issue, because it inevitably leads to people posting the problem and then someone in what can only be imagined as a whiny, nasal voice talking down to the questioner, explaining how object and materials require indices to maintain their individuality (a problem which is not unique to Blender, but is mysteriously unique in its not being hidden behind transparency to the user). Such explanations are of no use to the person who suddenly finds themselves with 25 OBJ exports that can only be "easily" fixed to how they obviously should have been written in the first place by opening them all in vim and running regexes -- and that only to users at my level who would not be daunted by the task, merely annoyed.

Such "answers" as are given usually tell the user they need to rename it internally (manually, apparently, even if there are hundreds of materials in use, which is possible when indices are being added to each import as well).

The fact is simply that someone condescendingly explaining the internals of how Blender tracks objects and materials is in no way a solution to the problem of it literally altering the materials of an object that is imported and re-exported without even any changes, something that should be obvious in its wrongness. So please do not respond to this bug report in that way. We KNOW it needs indices internally to separate materials and objects. It doesn't need to show them, but even if it does it should NOT export them unless someone weirdly and inexplicably wants them and sets an option to do so. As it is, there's not even an option NOT to include them.

Exact steps for others to reproduce the error
(Back up any object you do this with unless you don't care about it)

1: Import an OBJ file, preserve vertex order.
2: Export that object to the same OBJ file (overwrite) with no changes having been made, preserve vertex order so it's not splitting anything even.
3: Delete the object
4: Import the same OBJ file you just exported, same settings
5: Export that object to the same OBJ file (overwrite) with no more changes having been made, as above.
6: Import to any other OBJ-using software that cares about groups and materials (so, like, not ZBrush basically). Maya, Max, Poser, Substance Painter, even Photoshop. Examine the materials' and groups' names. Note that they all have .001 appended to the end (or higher if you didn't start with a clean project).

This is an occurrence that, quite frankly, pisses everyone who uses it off except the few people who make excuses for the behaviour, when it is clearly wrong and please don't go trying to explain it isn't wrong, because it absofragginglutely is wrong.

**System Information** Operating system: Any Graphics card: Any **Blender Version** Broken: 2.83.5 (example: 2.79b release) (example: 2.80, edbf15d3c044, blender2.8, 2018-11-28, as found on the splash screen) Worked: never **Short description of error** Internal numerical indices for objects and materials should NOT be included by default in OBJ export. Anyone affected by this problem will find their blood pressure spiking if they google how to try and alleviate the issue, because it inevitably leads to people posting the problem and then someone in what can only be imagined as a whiny, nasal voice talking down to the questioner, explaining how object and materials require indices to maintain their individuality (a problem which is not unique to Blender, but is mysteriously unique in its not being hidden behind transparency to the user). Such explanations are of no use to the person who suddenly finds themselves with 25 OBJ exports that can only be "easily" fixed to how they *obviously* should have been written in the first place by opening them all in vim and running regexes -- and that only to users at my level who would not be daunted by the task, merely annoyed. Such "answers" as are given usually tell the user they need to rename it internally (manually, apparently, even if there are hundreds of materials in use, which is possible when indices are being added to each import as well). The fact is simply that someone condescendingly explaining the internals of how Blender tracks objects and materials is in no way a solution to the problem of it literally *altering the materials of an object that is imported and re-exported without even any changes, something that should be obvious in its wrongness*. So please do not respond to this bug report in that way. We KNOW it needs indices internally to separate materials and objects. It doesn't need to show them, but even if it does it should NOT export them unless someone weirdly and inexplicably wants them and sets an option to do so. As it is, there's not even an option NOT to include them. **Exact steps for others to reproduce the error** (Back up any object you do this with unless you don't care about it) 1: Import an OBJ file, preserve vertex order. 2: Export that object to the same OBJ file (overwrite) with no changes having been made, preserve vertex order so it's not splitting anything even. 3: Delete the object 4: Import the same OBJ file you just exported, same settings 5: Export that object to the same OBJ file (overwrite) with no more changes having been made, as above. 6: Import to any other OBJ-using software that cares about groups and materials (so, like, not ZBrush basically). Maya, Max, Poser, Substance Painter, even Photoshop. Examine the materials' and groups' names. Note that they all have .001 appended to the end (or higher if you didn't start with a clean project). This is an occurrence that, quite frankly, pisses everyone who uses it off except the few people who make excuses for the behaviour, when it is clearly wrong and please don't go trying to explain it isn't wrong, because it absofragginglutely is wrong.

Dodger Cannon commented

2021-01-25 21:40:13 +01:00

Added subscriber: @Dodger-1

Ryan Inch commented

2021-01-27 02:54:40 +01:00

Added subscriber: @Imaginer

Omar Emara commented

2022-03-08 08:58:02 +01:00

Added subscriber: @OmarEmaraDev

Omar Emara commented

2022-03-08 08:58:02 +01:00

Changed status from 'Needs Triage' to: 'Archived'

Omar Emara closed this issue

2022-03-08 08:58:02 +01:00

Omar Emara commented

2022-03-08 08:58:02 +01:00

Those indices are not solely used internally by Blender, in fact, they are just normal object names, not indices. The exporter merely exports the objects with the name assigned to them in Blender.
It is the importer that identifies the existence of a mesh with the same name as the object getting imported, so .[0-9]+ is appended at the end to make a unique name. This not just internal to Blender and is integral to everything that Blender does.
The importer also decides to share the same name between the mesh and the object by design. This could be changed, but we don't consider it a bug. Closing as this bug tracker is only for bugs and errors.

For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests

For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Those indices are not solely used internally by Blender, in fact, they are just normal object names, not indices. The exporter merely exports the objects with the name assigned to them in Blender. It is the importer that identifies the existence of a mesh with the same name as the object getting imported, so .[0-9]+ is appended at the end to make a unique name. This not just internal to Blender and is integral to everything that Blender does. The importer also decides to share the same name between the mesh and the object by design. This could be changed, but we don't consider it a bug. Closing as this bug tracker is only for bugs and errors. For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

Dodger Cannon commented

2022-03-08 09:06:48 +01:00

No, it really, as I said, absofragginlutely is wrong.

This is the sort of attitude that guarantees open source stuff not be taken as seriously as commercial software. It IS A PROBLEM and CAUSES PEOPLE PROBLEMS, therefore it IS A BUG. Just because you have an explanation/apologetics for why it does something, does not mean it HAS TO DO that thing that way.

It would not be particularly hard to add some metadata to the mesh that says "these groups have been renamed, and these are their original names" and then for the exporter to read this same data and fix the problem on the way out.

So open the frakking task back up because it frakking needs done, OMAR.

No, it really, as I said, absofragginlutely is wrong. This is the sort of attitude that guarantees open source stuff not be taken as seriously as commercial software. It IS A PROBLEM and CAUSES PEOPLE PROBLEMS, therefore it IS A BUG. Just because you have an explanation/apologetics for why it does something, does not mean it HAS TO DO that thing that way. It would not be particularly hard to add some metadata to the mesh that says "these groups have been renamed, and these are their original names" and then for the exporter to read this same data and *fix the problem on the way out*. So open the frakking task back up because it frakking needs done, OMAR.

Omar Emara was assigned by Dodger Cannon

2022-03-08 09:07:44 +01:00

Dodger Cannon commented

2022-03-08 09:10:29 +01:00

I mean, even just a "rename groups on save" that remains sticky, with some pattern options including ",\d\d\d+$" => "" would solve the main problem.

I mean, even just a "rename groups on save" that remains sticky, with some pattern options including "\,\d\d\d+$" => "" would solve the main problem.

Omar Emara removed their assignment 2022-03-08 09:15:12 +01:00

Omar Emara commented

2022-03-08 09:15:12 +01:00

Changing a behavior to potentially improve the workflow is something that we could do. The fact that we don't consider this a bug doesn't mean that we we will not consider your suggestion. However, there are different channels for feedback like this. This tracker is only for bugs and errors. See the links in my previous message for the different channels you can use instead.

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Remove indices from objects, groups, materials on export #85056