+1 on finding this behaviour annoying. Since this behaviour was implemented with an N-gon use-case in mind, would it be possible/ make sense to have the behaviour vary depending on whether or not the selected edge belongs to an N-gon or not?
Right now though, even for the N-gon purpose though it seems slightly unintuitive to me. Maybe I'm just over-thinking it now, but here's screenshot to help me explain: http://www.pasteall.org/pic/show.php?id=51228 I marked click positions that cause the selection shown orange. The red marks in the third picture show what I would expect to contribute to this selection, but don't currently. I would love to see the "old behaviour" back for quads and the new one used for Ngons only to allow easy selection. Again, I may just be over-thinking it (heck, and I hardly use N-gons, so power users in that regard may have a different idea on this) and it's potentially a very subjective preference, but just thought I'd chime in. Cheers, Patrick > From: [email protected] > To: [email protected] > Date: Mon, 13 May 2013 14:31:02 +0000 > Subject: Re: [Bf-committers] select loop behavior > > although it's not a killer but annoyingly enough change, i could model > without it, or select in edge mode, > but surely it slows down the workflow, thanks anyway :) > > Regards > Yousef Harfoush > [email protected] > > > > > Date: Mon, 13 May 2013 13:15:17 +0100 > > From: [email protected] > > To: [email protected] > > Subject: Re: [Bf-committers] select loop behavior > > > > It's problematic because of the examples in the first post. If I am > > trying to select a loop similar to the picture in the first post then it > > selects the whole face, which means I have to either change to edge mode > > and deselect the offending edge or reselect the other verts. manually. > > As fredrik said, this causes workflow problems when working with single > > strip quads when doing things like retopo or in my case blocking out a > > high/lowpoly surface. > > > > Without trying to sound like a dick, I cannot imagine a real world > > example where any modeller who is at least relatively experienced would > > want to select the boundary of an ngon in the manner that you presented > > in your example...people just shouldn't model that way. Ngons should > > never be used as a boundary... only ever on flat, non deforming surfaces > > and only then if they are surrounded by a loop of quads. They can always > > inset the ngon and the problem is fixed for them. > > > > Cheers, > > > > -Andy > > > > On 13/05/2013 12:51, Campbell Barton wrote: > > > On Mon, May 13, 2013 at 9:31 PM, metalliandy > > > <[email protected]> wrote: > > >> Hmm, It really depends on what the target audience is for this I > > >> suppose. It plays havoc when doing subd work, for which ngons should > > >> only be used on flat areas that are surrounded by quad loops. > > >> How much do people select ngons in this way vs quads? > > > Are you talking about the original post from Yousef? > > > How to deal with mixes of NGons+Quads+WireEdges+BoundryEdges... is > > > disputable and could be changed/improved. > > > But I fail to see how a detail about the behavior of selecting the > > > endpoint of dangling quad would cause havoc to your workflow. > > > > > > Can you give details as to why current behavior is so problematic? > > > _______________________________________________ > > > 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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
