[Bf-committers] Joining objects and merging UV Layouts has Changed in Behaviour (2.69)

[Dalai Felinto]

The report doesn't make much sense. I replied it there.

Not that we shouldn't have per-id merging (that be still be discussed) ,
but his example doesn't makes a valid point for that in my opinion

2013/10/22 Bastien Montagne <montagne29 at wanadoo.fr>

> Another complain about new behavior (this time, he’d like to *not* merge
> his UVMaps…):
>
> https://projects.blender.org/tracker/?func=detail&atid=498&aid=37182&group_id=9
>
> I really think we should allow that as well (so merge by name, merge by
> index, no merge), does not really complicate that much the code, and
> allows much more flexibility in workflows…
>
> On 15/10/2013 17:54, Dalai Felinto wrote:
> > Hi Gaia,
> >
> > What would the "Combine UV Layers" operator do exactly?
> > How to solve conflicts in a predictable way when the same face has UV
> > information in multiple layers.
> >
> >> this would allow old behavior which works very well in most cases (since
> > i guess most objects only have one layer)
> >
> > For most of the objects that have one layer the layer is also most likely
> > called UVMap, so in that case the old behaviour is already accomplished.
> >
> > Note that in case the user joined the objects and regretted later (way
> past
> > the Ctr+Z point) she can still separate the objects, delete the empty
> > UVMaps, rename them, and re-join it.
> >
> > Finally it doesn't make sense to have join by id if we can't even order
> the
> > UV maps up and down in the list. (thus joining by name gives the user way
> > more control and is a lossless solution).
> >
> > Cheers,
> > Dalai
> > _______________________________________________
> > 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
>