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 <[email protected]> 写道： > 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 <[email protected]> > 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 >> [email protected] >> http://lists.blender.org/mailman/listinfo/bf-committers > _______________________________________________ > Bf-committers mailing list > [email protected] > http://lists.blender.org/mailman/listinfo/bf-committers _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
