[Bf-committers] select loop behavior

[Campbell Barton]

While checking on these issues I found some other odd behavior with
ngons (simple case fixed r56773).
Id like to try address the issues posted, but more in the context of
getting predictable results rather then just adding quick hack for
this one case work as it did in 2.4x.

On Tue, May 14, 2013 at 2:41 AM, patrick boelens <p_boelens at msn.com> wrote:
> +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
>
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers



-- 
- Campbell