Hi. A while ago, using 2.79, I noticed material names had a maximum length of 63 chars. That limit is still in place in 2.80. It’s mostly fine, but there’s one program I sometimes export to whose material names are in a ‘path’ format, e.g. textures\stone\wall etc, and models made in 3d programs have to use this.
In some cases the material names are longer than 63 chars. It would be impractical to change them in the destination program because many of them will be in use by existing projects. When I’ve encountered this problem I’ve made a duplicate of the material with a shorter name and used it for my project. It works but shouldn’t be necessary.
Would it be possible to increase the character limit?
I work on the same project as R_Soul and having this 63 material name limit is severaly slowing down my workflow. I have to covert the .LWO to .ASE so that I can then manualy edit the material names. Then convert back to .LWO.
Modifying the source code is exactly what I was getting at. I wasn’t suggesting anything else. Bringing it to the attention of the Blender devs is the challenge, because I’m sure it would be a simple task for people who are already familiar with large c/c++ projects.
I’ve already made a post in the horribly named right click select forum:
Python script? I have in fact written an addon to handle IDTech materials. E.g. one part of it looks at the diffuse texture in Blender and scans the materials files to find matching names. I had to adjust the code so that if a material name is more than 63 chars it puts a warning in the Blender material name and stores the real one in a custom property. That doesn’t help when exporting because the wrong material name is written to the file.
I don’t think Blender would have any performance problems with longer material names.
for small files no problems of performance
but bl internal works with List and when you get a few 1000’s
it begins to be sluggish
mind you some of these list have been optimise in 2.8 so I hope it will be faster
but I know in 2.79 it gets very sluggish
if you do a lot of work then might be worth to build yourself some
python script to deal with these names!
you could use like a dictionnary for names
so easier to find the equivalnet name for material
i’m certan there is a way to do it
good luck
I didn’t know there were a limit, but if it’s actually for RAM saving, it seems totally crazy for me
Even having 100 materials of 100 chars would cost no more than 10 kB, I feel like setting a limit is no use for RAM saving compared to the involved limitation ^^
One reason for any limit is that all programs need to know how much memory to set aside for things. When the code was being done for material name lengths, someone therefore had to choose a limit, and decided 63 would be fine.
Generally it seems fair enough, because most materials can be called things like WoodRotten or MetalPolished, so it’s easy to imagine that 63 is a reasonable limit, but that person clearly didn’t take ‘path based material names’ into account.
RickyBlender, please stop suggesting I write a python script. First of all I’ve already said that I’ve done something to help with the problem, but it shouldn’t be necessary. Nor should it be necessary to modify the .lwo and .ase exporter/importer scripts to be modified to replace the limited material names with something read from a custom property. It would create a dependency between two/three addons, whereas someone who has access to and knowledge of the source code could probably just change a 63 to 128 and be done with it.
Im using 3.2 and the limitation is still there.
Totally agree with @R_Soul im also using path based material names.
No easy way to fix this still right?
It’s probably easy to change in the source code and compile blender yourself.
If you don’t want to do that, then you have to cheat with python, that won’t allow you to extend names, but workaround using custom properties.
As said in the previous answer it create a lot of mess for a small thing but if you really need it then it can help.
ok so the variable is MAX_ID_NAME and is in DNA_ID.h ive changed to 130 so 2 for id and 128 chars for naming just build blender 3.2 and seems to work fine
Just an FYI, changing the DNA structure without proper versioning code will change the structure of your blend file and you’ll no longer have compatibility with the official Blender releases.
Usually in C programming you would create a string value as static array of characters: char material_name[64];
Since Blender 10+ years ago would have to fit nicely in RAM of the time, surely made that restriction. Perhaps the name now can be safely expanded to 256 which is exacly one byte of size (nobody will feel the burden in terms of capacity)…
If it goes like this we should create a petition to push the change.
The challenge seems to be getting the attention of just the right person at just the right time. The devs can’t read every comment, so I’ve been trying in a variety of places:
I started a thread on the right-click select forum:
(as mentioned above)
Also, when they post an update on LinkedIn I tend to mention this limit in a comment.
And here’s a thread on the DevTalk forum:
(Nerophesis is there too)
We must keep up the campaign.
From this day to the ending of the world,
But we in it shall be remember’d;
We few, we happy few, we band of brothers;
I do wonder though, is there any utility for path-based texture names since just about every program has a search function now? What happens when you re-organize your texture folder and every single file name becomes inaccurate?
Perhaps the character limit could be increased so the overtly meticulous can have names like SlightlyWornAndSomewhatGlossyHighResolutionRedBricksForTheBigBuildingAtTheEdgeOfTheScene, but I do not think we should make Blender heavier on hardware just because hardware itself allows us to do it.
This would be a call for another one fancy Addon that handles the problem and prevents links from breaking.
But what if would be better, that Blender eventually has to introduce the concept of virtual file system as well, these ‘virtual file systems’ as used in game engines can offer a better level of abstraction that is crucial for maintaining file structures.
