[Bf-committers] requesting reversion of 41550 despite downsides

[Bassam Kurdali]

Hmm, interesting, will offer some replies. below.
On Sun, 2011-11-27 at 06:49 -0800, Martin Poirier wrote:
> If it was partly working, I'd agree, but it isn't.
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 ;)
> 
> 
> 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.

> 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.
> 
> 
> If it was broken in a predictable fashion, I wouldn't have any issue
> with documenting it and leaving it there, but as it stands, even if
> you think you understand what the limitations are, you don't, I assure
> you.
Fine. I don't. Except: it works for me, and for many people who use it.
It's not that different from e.g. transform, snapping, rotations, which
all fail in weird, unpredictable ways (which is 'not a bug') 
> 
> 
> 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.
> 
> 
> Like I told Daniel last time, reenable this in local builds at your
> own risk, but I'm very much set against shipping unpredictably
> breaking feature. The fact that xmirror is disabled when pet is on
> could be better documented though. It could even be the reverse
> (disable pet when xmirror is on) if the consensus is that this would
> be better (break workflow less, be less surprising, ...).
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? (and before you start,
please *don't* disable edge slide with deform modifiers on)

At best, can it get hidden under a magic RT number ;) ?
> 
> 
> 
> Martin
> 
> 
> 
> 
> ______________________________________________________________________
> From: Bassam Kurdali <bassam at urchn.org>
> To: bf-blender developers <bf-committers at blender.org> 
> Sent: Saturday, November 26, 2011 7:02:25 PM
> Subject: [Bf-committers] requesting reversion of 41550 despite
> downsides
> 
> Hi all,
> 
> http://projects.blender.org/scm/viewvc.php?view=rev&root=bf-blender&revision=41550
> removes 'partially working' functionality from blender. And breaks
> stnndard workflow for facial rigging. In the past even though this
> feature had problems, It was still used by many to create symetrical
> shapes; some points about this:
> 
> -after mirror modifier has been applied
> -symmetric; vertex groups will be later used as masks for left and
> right
> side.
> -working on only one half of the shape is no good, you need to see the
> total symmetric one, and use the vertex groups to blend, otherwise,
> you
> get bad blends of left and right.
> -working point by point really, really kills when doing shapekeys.
> Rigging already takes too long.
> 
> this feature/workflow is present in almost any animation application.
> Simply removing it from blender is, well, a bit a extreme in my
> opinion.
> 
> usually if you avoided crossing the mirror line with the proportional
> circle you were pretty safe; weird things only happened close to the
> line, at which point we turned it off. This was better than what we
> have
> now: not having it all.
> 
> Can we have it back? pretty please? I know custom builds are possible,
> but... if we want remove partially buggy features from blender, we'd
> end
> up removing most of the program ;) - we have transform / offsets that
> break in many 'corner cases' , drivers that don't update (due to
> missing
> dependency graph fixes), python bugs, etc. The reaction isn't to
> remove
> transform/drivers/python from blender - oh, and please, don't take
> that
> as a suggestion ;)
> 
> cheers
> Bassam
> 
> 
> 
> _______________________________________________
> Bf-committers mailing list
> Bf-committers at blender.org
> http://lists.blender.org/mailman/listinfo/bf-committers
> 
> 
>