[Bf-committers] New "merge cdlayers by name" feature can generate more than 8 allowed uvmaps or vcol layers

[Harrisyu]

Hi！
I notice that when you use more than 14 uv layers in cycle node，material will not display texture in viewport，render is ok.why I use many uv layer is because I did a complex cartoon texture face setup.can we increase this limit to 24 or 32？

发自我的 iPhone

在 2013-11-12，16:51，Brecht Van Lommel <brechtvanlommel at pandora.be> 写道：

> The only reason there is a limit is indeed for blender internal, where
> it's just these two lines in struct ShadeInput:
> 
>    ShadeInputUV uv[8];   /* 8 = MAX_MTFACE */
>    ShadeInputCol col[8]; /* 8 = MAX_MCOL */
> 
> I see two good solutions:
> * Support dynamic allocation of these things. It needs to be done
> carefully with per-thread memory pools in the Render struct for
> performance, and would need a shadeinput_free function because all of
> ShadeInput is just static now.
> * Document this as a limitation of Blender Internal and allow
> unlimited layers elsewhere. Even if the mesh has that many UV layers,
> it's unlikely that one material would use that many?
> 
> Brecht.
> 
> 
> On Mon, Nov 11, 2013 at 9:55 PM, Bastien Montagne <montagne29 at wanadoo.fr> wrote:
>> When you merge two meshes with each 8 UVMaps which names are not
>> matching, you get a mesh with 16 UVMaps (same goes for vcol layers).
>> 
>> This is not completely bad per se, as the 8 limitation is only at the
>> shading (render) level. However, we should try to fix it - here are some
>> solutions I can see:
>> 
>> 1) Let code as it is currently, warning the user when too much layers
>> get generated, and add tools to merge layers (in a same object).
>> 2) Just drop the layers above limit number (easy to implement, but not
>> user-friendly at all!).
>> 3) Fallback to "non-matching-name" merging when we do not have enough
>> room to create all needed layers (not really good solution either, imho,
>> as it would give some rather unpredictable results on user POV).
>> 
>> So I would rather go for 1)… We would probably also need some API from
>> customdata.c to easily check the max number of layer is respected, and
>> optionally merge or drop the supernumerary ones.
>> 
>> Any feedback is welcomed here, as usual, especially if you have better
>> ideas on how to handle this issue!
>> 
>> Best regards,
>> Bastien
>> _______________________________________________
>> Bf-committers mailing list
>> Bf-committers at blender.org
>> http://lists.blender.org/mailman/listinfo/bf-committers
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers