>________________________________ > From: Bassam Kurdali <[email protected]> >To: Martin Poirier <[email protected]> >Cc: bf-blender developers <[email protected]> >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 _______________________________________________ Bf-committers mailing list [email protected] http://lists.blender.org/mailman/listinfo/bf-committers
