It looks like there’s a limit to the number of UV maps one object can have, something like 8 in my tests. I’m curious about the origin of this and whether it might be trivially changed without breaking other systems (so it’s kind of a development question to ask what the ramifications might be).
It’s not trivial, but probably not that hard either. It requires going through the code and replacing arrays with fixed size MAX_MTFACE with something dynamic, in a way that doesn’t impact performance much by doing many memory allocations in performance sensitive functions.
If this change is made it would be good to understand first why you need more than 8 UV maps though, since that will take up a lot of memory. When this was asked for in the past, I remember it being for some uses cases that had better solutions.
The original reason was that it matched OpenGL limitations on number of texture coordinates. There’s still limitations as far as I know, but they might not matter depending on how you’d use this.
Some background, then. I was looking to use the particle system to place building lots on polygons, using one particle per polygon. These placement polygons are from an upstream tool that is also responsible for the street layout and similar (it’s a legacy tool).
The building lots are coming from linked scenes, each with a group. The group is made up of a pavement object and then the various buildings that have been manually placed on the pavement, each as a child object. Each building has its own UV map to place its textures. There, in total, are 40 base building variations, with each lot having a number of these variations and each lot having a different number of buildings in total (and a different number of unique buildings) - that is lot001 could have 20 buildings, but 10 variations; lot002 could have 10 buildings with 3 variations. Each building lot is its own blend file and has its own group in that blend file.
To make the building lots usable via the single group slot in the particle system, I’ve tried (and failed) with:
- Linking each group into the master, adding each of these groups to a master group and using that master group as the source of the duplication.
- Creating a dupligroup instance in the building scene and importing just that in the main scene, adding this to a group and then using that as the source of the duplication.
- The ‘whole group’ does work, but I can only have a single building lot in this situation, which makes things rather boring.
Based on my initial experiments with this, using single object place-holders, it seems like the only way to make this work is to have each building lot be a single object that exists within the group. To that end, I went through the process of explicitly linking the UV maps in the surface nodegraph and then joining all the meshes. This silently drops the 9th and later UV maps (or at least the warning is not obvious enough) and I only noticed the issue when the viewport render preview started turning buildings black.
So, that’s where the request comes from - I haven’t found another way to do this and was rather taken by surprise by the limitation 
It’s not clear to me why joining meshes requires more UV maps. If you ensure all meshes have a UV map with the same name, they should all join into a single UV map. The joined buildings may need multiple image textures or materials, but not multiple UV maps?
2 Likes
Ah, that will work. I didn’t think of that as an option. Still, the limit seems kind of arbitrary and the tool doesn’t really make the limitation obvious. Would it be possible to have a user preference and/or a much more obvious warning/error when more than the max number of UV maps is somehow involved?