Anyone know why we have this silly limitation in Blender?

The interface, modeling, 3d editing tools, import/export, feature requests, etc

Moderators: jesterKing, stiv

Fire Angel
Posts: 0
Joined: Wed Aug 03, 2005 6:24 pm
Location: London, England.

Anyone know why we have this silly limitation in Blender?

Post by Fire Angel »

On many 3d packages you can allocate many materials to a single mesh, in some cases as many as you have memory for. In Blender, however, we're limited to a mere 16 per mesh, and this makes it really awkward sometimes when creating models that are going to be used in other applications or when importing models made in other applications. Sometimes the best way to solve material problems is to add another material to some parts of a mesh or model, and 16 is an absurdly low limit. Before anyone suggests it, yes I know we can break a model up into a number of meshes and parent them to keep them together, but that's a messy solution that really shouldn't be needed.

Do we have a 4-bit pointer or material number stored somewhere? If so, can someone please do the obvious and let us use a 32-bit number instead? or at least a 16-bit value, that would give us 65,536 materials instead of 16, seems like enough even to keep me happy...

:D

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

let us use a 32-bit number instead
Are 4 billion materials really going to be enough?

Fire Angel
Posts: 0
Joined: Wed Aug 03, 2005 6:24 pm
Location: London, England.

Post by Fire Angel »

stiv wrote:
let us use a 32-bit number instead
Are 4 billion materials really going to be enough?
Possibly not for some people, but 16 definitely isn't enough. I'm not the only person who has been puzzled by the 16 material limit and not the only one who finds it annoying.

zingbat
Posts: 0
Joined: Thu Apr 29, 2004 12:36 am

Post by zingbat »

There are many small limitations in Blender that don't make sense any more. Besides the number of materials, there's also a limitation on the default camera view range and the number of grid lines we can have at a time. We can't modify the way the snapping grid is oriented or what is considered the up axis in Blender. Filenames and ids are still limited to 20 chars.

It would be cool if all those small limitations were collected and removed once and for all.

Fire Angel
Posts: 0
Joined: Wed Aug 03, 2005 6:24 pm
Location: London, England.

Post by Fire Angel »

zingbat wrote:There are many small limitations in Blender that don't make sense any more. Besides the number of materials, there's also a limitation on the default camera view range and the number of grid lines we can have at a time. We can't modify the way the snapping grid is oriented or what is considered the up axis in Blender. Filenames and ids are still limited to 20 chars.

It would be cool if all those small limitations were collected and removed once and for all.
Excellent idea, and I'm sure everyone who uses Blender a lot has their own list. Most of them would probably be pretty trivial efforts to remove, so I hope for some work on it in 2.5.

My own bugbear is that material limit, as I am often called upon to modify models built in other programs, and some of them have forty materials or more.

jesterKing
Site Admin
Posts: 207
Joined: Fri Oct 18, 2002 12:48 pm
Location: Finland

Post by jesterKing »

zingbat wrote:Filenames and ids are still limited to 20 chars.

It would be cool if all those small limitations were collected and removed once and for all.
Filename limitations are AFAICR dictated by filesystem limitations (but I can be mistaken).

Anyway, to circumvent the problem with datablock IDs being limited, I think you / we could use IDProps for that instead. In that way the current ID could be used as a UUID, which is a 128-bit identifier. The current ID name limit would be more than sufficient to give a large enough range (4 bytes more than needed!). Of course, it is then a matter of making sure to make distinction between low-level data ID and user-defined ID/name.

At least you could already use IDProps for your own naming purposes.

/Nathan

Fire Angel
Posts: 0
Joined: Wed Aug 03, 2005 6:24 pm
Location: London, England.

Post by Fire Angel »

jesterKing wrote:
zingbat wrote:Filenames and ids are still limited to 20 chars.

It would be cool if all those small limitations were collected and removed once and for all.
Filename limitations are AFAICR dictated by filesystem limitations (but I can be mistaken).

Anyway, to circumvent the problem with datablock IDs being limited, I think you / we could use IDProps for that instead. In that way the current ID could be used as a UUID, which is a 128-bit identifier. The current ID name limit would be more than sufficient to give a large enough range (4 bytes more than needed!). Of course, it is then a matter of making sure to make distinction between low-level data ID and user-defined ID/name.

At least you could already use IDProps for your own naming purposes.

/Nathan
I think in most cases that UUID device would be so overcomplicated it isn't a good idea. If the mesh materials are being indexed by a 4-bit number raising the number of bits to somewhere between 10 (giving 1024 possibilities) and 16 (giving the aforementioned 65,536) would be simple to implement and easy to test and debug. It would also provide all the materials on one mesh that any reasonable modelling project is likely to need. I have found many uses for more than 16 materials, I haven't found a sensible use for more than 1000 or so (Oh no! I just thought of one :shock:).

16 bits would be enough for any sensible use I can think of, even the one I just alluded to in the last paragraph. :D

jesterKing
Site Admin
Posts: 207
Joined: Fri Oct 18, 2002 12:48 pm
Location: Finland

Post by jesterKing »

Fire Angel wrote:
jesterKing wrote:
zingbat wrote:Filenames and ids are still limited to 20 chars.

It would be cool if all those small limitations were collected and removed once and for all.
Filename limitations are AFAICR dictated by filesystem limitations (but I can be mistaken).

Anyway, to circumvent the problem with datablock IDs being limited, I think you / we could use IDProps for that instead. In that way the current ID could be used as a UUID, which is a 128-bit identifier. The current ID name limit would be more than sufficient to give a large enough range (4 bytes more than needed!). Of course, it is then a matter of making sure to make distinction between low-level data ID and user-defined ID/name.

At least you could already use IDProps for your own naming purposes.

/Nathan
I think in most cases that UUID device would be so overcomplicated it isn't a good idea. If the mesh materials are being indexed by a 4-bit number raising the number of bits to somewhere between 10 (giving 1024 possibilities) and 16 (giving the aforementioned 65,536) would be simple to implement and easy to test and debug.
I was not talking about mesh materials only, but about *all* ID datablocks we have. Essentially an UUID is just a 128-bit number, this giving room for a heckload of data with ID (objects, materials, textures, armatures, you name it).

The idea I suggested was to keep the current ID as it is visualised in the GUI under the hood, and expose a human readable name in its stead.

/Nathan

jayr
Posts: 0
Joined: Fri Oct 28, 2005 6:23 am

Post by jayr »

sorry wrong place "Accident" :oops:
Last edited by jayr on Tue Oct 28, 2008 6:58 pm, edited 1 time in total.

stiv
Posts: 0
Joined: Tue Aug 05, 2003 7:58 am
Location: 45N 86W

Post by stiv »

Did you post in the wrong thread? No Joeris in this one. If you are going to be a troll, try to display at least a modicum of competence. Attempts to hijack a thread are frowned upon.

-- moderator

joeri
Posts: 96
Joined: Fri Jan 10, 2003 6:41 pm
Contact:

Post by joeri »

stiv wrote:...No Joeris in this one. If you are going to be a troll...
What is this all about?


16 materials is enough for a single object.
If you need more separations for game use or so use the vertex groups.

UUID for datablock sounds like a good idea. But as nathan suggests I have no trouble naming my object AT123T-V instead of "The Head Of This Character I'm Now Working On Part iV [ Client wanted change did that on 21-06-08 ] ~Joeri "

damir
Posts: 0
Joined: Tue Feb 21, 2006 7:50 pm

Post by damir »

joeri wrote: 16 materials is enough for a single object.
Sorry but I've had to comment this statement because it sounds to me like the famous: 640K is enough for anyone...

Based on my needs, 16 materials/object isn't enough. But also I don't think that anyone needs 4 billion of materials. I vote for 16 bit.

kursadk

Post by kursadk »

Is this limiation available even if I use material nodes?

Master Letch
Posts: 0
Joined: Sun May 25, 2008 8:15 am
Location: Keswick Ontario, Canada

Post by Master Letch »

joeri wrote:
stiv wrote:...No Joeris in this one. If you are going to be a troll...
What is this all about?


16 materials is enough for a single object.
If you need more separations for game use or so use the vertex groups.

UUID for datablock sounds like a good idea. But as nathan suggests I have no trouble naming my object AT123T-V instead of "The Head Of This Character I'm Now Working On Part iV [ Client wanted change did that on 21-06-08 ] ~Joeri "
hey, just found this thread to be a heated debate (somewhat)
so don't burn me at the stake for this. I've never used more then 8 materials for an object, until I read about this limitation, I didn't even know there was one. with all the reasons for keeping objects in compound states (such as radio, animation and quirks with external renderers), the 16 material limitation, as annoying as it seems to be, makes sure things don't get disorderly...
M. Letch

bloodangel
Posts: 0
Joined: Tue Dec 30, 2008 1:00 am

Post by bloodangel »

zingbat wrote:There are many small limitations in Blender that don't make sense any more. Besides the number of materials, there's also a limitation on the default camera view range and the number of grid lines we can have at a time. We can't modify the way the snapping grid is oriented or what is considered the up axis in Blender. Filenames and ids are still limited to 20 chars.

It would be cool if all those small limitations were collected and removed once and for all.
I really like Blender but to me it seems pretty bass ackwards sometimes. Z is the up axis *shudders* and when I edit texture UVs the vertices on the image screen don't match up right. ex. I edit a face. I am looking into the face, opposite the direction of the face normals. None of it lines up. I have to look at the face for a reference. OpenGL is right-handed. Why the developers went out of their way to reverse the axes is beyond my comprehension.

Post Reply