On Tue, Jul 2, 2013 at 3:41 PM, Bassam Kurdali <bas...@urchn.org> wrote:
> Personally I like this mode, but I could live without it I guess - for me > it isn't a bug, I often combine vector/aligned or free/aligned. the former > is more obviously useful, the second only marginally so ( you get one > handle that keeps the tangent, and only slides in line, and the other > handle is free to go (it's almost like one is parented to the other) > You're exactly the user I want to talk to then! Let's see if we can find a no-compromise solution. I apologize in advance for the long email... I do see the utility of the vector/aligned and free/aligned behavior. The part that seems like a "bug" to me isn't the existence of those combinations, but the reactions of the menu-options. If I want to grab a handle and move it without affecting the other one, my expectation, the docs, and the menu name "free" all suggest that I should click that handle, choose "free", and be able to drag it independently from the other. Today, this is not the case at all. In fact, I have to select the OTHER handle (or the center-point), and tell that one to be free, even though I don't want to move it at all. I found this rather non-intuitive.. in fact, I didn't really understand what was happening until I read the code. This is what my current patch changes. Also, when a handle is "rotation locked" (i.e. the aligned side of align/free), IMO getting it 'unlocked' is very non-intuitive. In fact you have to pick the OTHER handle and set it to "align", which is very confusing. Again, I didn't understand this behavior until I read the code. Now, let's see if we can keep all the possible spline behaviors while making the above a bit more intuitive! One change which is sort-of like the current align/free, align/vector behavior is adding the ability to scale just a single handle. Currently we can only scale both handles together by selecting the midpoint. I plan to add this regardless because I think it'll be useful. I understand this will not prevent accidentally moving the handle with grab. * Do you think just the ability to explicitly "scale only one handle" is enough to remove the need for these align/free and align/vector states? If we would like to preserve the "parent locking" like behavior of the current align/free and align/vector, the smallest change I can think of is to add an additional menu option called "constrain". This would be used to create the align/free or align/vector state. With one handle selected, "constrain" would rotation-lock that handle by creating the align/free or align/vector states -- while the "free" and "align" menu items would create free/free and align/align respectively. I don't like adding the complexity of an additional menu item, but I think this would be a *much* simpler user model. * Do you agree this will keep today's align/vector and align/free behavior? Do you see how it's more direct and intuitive, because you choose a handle and an "verb action" to take on that handle -- rather than having to select the OTHER handle? One wrinkle of causing "constrain" to work within the current handle-states is that constraining both handles will not act as expected. In this case I would expect both handles to be frozen (something you can't achieve today), but in fact they will both be draggable as in align/align today. This can be fixed by also introducing an additional "constrained" state for each handle.. this state is like align, except that align/align is movable, while constrain/constrain is completely locked. * Do you think it's worth-while to add the ability to lock both handles with constrain/constrain? Would you use this? If it is valuable to keep the constrain/free, constrain/vector, and possibly constrain/constrain states.. I think it would be worth making this a little clearer with some super-minimal visuals. My thought is to make the constrained handle look like a small "T" instead of a dot. This would help visually indicate that you can linearly drag but not rotate it. * Do you think this visual would be helpful? Too busy? _______________________________________________ Bf-committers mailing list Bf-committers@blender.org http://lists.blender.org/mailman/listinfo/bf-committers