[Bf-committers] requesting reversion of 41550 despite downsides

[Martin Poirier]

>________________________________
> From: Bassam Kurdali <bassam at urchn.org>
>To: Martin Poirier <theeth at yahoo.com> 
>Cc: bf-blender developers <bf-committers at blender.org> 
>Sent: Sunday, November 27, 2011 8:08:38 PM
>Subject: Re: [Bf-committers] requesting reversion of 41550 despite downsides
> 
>Hmm, interesting, will offer some replies. below.


>coder working != user working. I always assumed coders would think
>something works when users say it doesn't, but it appears it can happen
>the other way around ;)

There were a couple of bug reports directly related to this bug in the last year.

That's what prompted the disable in the first place, after investigation.


>> The behaviour depends on the order of the vertices in the mesh and
>> their distances to the selection.
>Great. However, in 6 or so years of using this feature, I've never to my
>knowlege seen that happen, and been satisfied with results. (user works!
>= coder works). It's possible because, in most of our workflows, mesh
>results from a mirror modifier that has been applied, with resultant
>order of vertices? or that the problem you see is not as bad as you
>think it is in practice.

Or maybe you were using it with a single vertex selected, with area of influence not crossing the mirror boundaries.
Which sometimes work.


>> It's even more unpredictable when area of influences crosses the
>> symmetry plane.
>True, which is why I just turn off proportional when working on the tiny
>fraction of verts that are too close (or lower the proportional value).
>Still beats not having it at all.

For people who are somewhat used to the behaviour maybe. It's a two line change, easy to edit locally.


>> The way x-mirror is implemented needs to be overhauled for this to be
>> fixed in any shape or form. There's is no quick and dirty fix that
>> won't make it broken in another unpredictable fashion.
>I'd never argue against a proper fix. I just think removing it until
>that happens is a pretty brute force solution, and lowers the usability
>of blender in the mean-time.

It's certainly not the first time we've disabled broken features.


>neither option is good. Both are surprising, both feel really bad. could
>we just get a warning, similar to edge slide with deform modifiers on,
>indicating the user that something can go wrong?

I tried edge slide on an armature deformed mesh and didn't get any visual warning (and slightly wrong sliding behaviour when pushing toward extremities).

A strong visual warning would be ok, probably.


>At best, can it get hidden under a magic RT number ;) ?

I'd rather put a compile option than a RT value.


Martin