[Bf-committers] select loop behavior

[patrick boelens]

+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: bat3a at msn.com
> To: bf-committers at blender.org
> 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
> bat3a at msn.com
> 
> 
> 
> > Date: Mon, 13 May 2013 13:15:17 +0100
> > From: metalliandy666 at googlemail.com
> > To: bf-committers at blender.org
> > 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
> > > <metalliandy666 at googlemail.com> 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
> > > 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
>  		 	   		  
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers