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