spline users, help me fix the spline handle behavior!

General Forums Blender and CG Discussions
1

i’m working a patch to improve some oddness in spline-handle type-toggling… You can read the bug here…

http://projects.blender.org/tracker/?func=detail&aid=35952&group_id=9&atid=498

I’m looking for some experts in splines, IPO curves, and animation splines to weigh in on some questions…

  1. Do you agree the current spline handle type-toggle behavior is odd and unintuitive, especially when toggling to “FREE” while only one spline handle is selected?

  2. What should toggle free/aligned do to vector handles? Currently it just toggles them as if they were aligned. I’m considering making it either leave them alone entirely… or only toggle them if only vector handles are selected (aka leave them alone in mixed selections). Any opinions?

  3. Currently it’s possible to create “aligned / vector” handle combos, where the aligned side is not rotatable because it’s pinned to the vector side. To me this just seems “broken” as you can’t move the handle. However, is this good behavior, or should I remove this and cause “aligning” a handle to remove the vector side?

  4. The IPO editor splines have the same bug(s). Should I fix it there too?

2

some thoughts:

  1. I do find it odd that it wont let me toggle the one handle to free without first altering the other handle

  2. It should have no effect. vector is locked to the next point like auto, so its relationship to the other handle is irrelevant (correct me if I’m wrong)

  3. leave it as is, it’s nice to be able to have a smooth curve transition into a straight line without needing to manually smooth out the transition

  4. sure

I’m not a huge user of splines, and these were thoughts that I had after playing with them a few minutes. Hope this feedback is helpful

3

Thanks for the feedback! Your sensibilities agree with mine, though I’m hoping to also hear from some heavy users of splines.

I found at least one user who makes use of the current align/free and align/vector behavior on bf-committers. I have two proposals to retain that functionality while making the toggle menu choices behave more intuitively.

(1) I can add the ability to “scale” a single handle. This would work on any combination of handle states (except vector handles which can not be scaled).

(2) I can add a new menu option “constrain”, which will allow the spline to be put into the align/free or align/vector state… and possibly a new constrain/constrain state where both handles are fully locked.

Any feedback on these is welcome… You can read all the gory details here…

http://lists.blender.org/pipermail/bf-committers/2013-July/041122.html

4

…another quick question… Do folks miss the ability to force “mirrored” spline handle, like in drawing programs like Illustrator, where the length of both sides of the spline is linked together?

5

I am not sure to understand your option “constrain”.
For me align or vector does not mean free; so I think it is logical to have current behavior without adding another type.
In my opinion, the expectation that you described in mailing list is equal to toggle both handles to free.

I don’t see the benefit to create a “constrain” handle equal to a free unused handle.
It just adds complexity to blender by adding an non-useful type with the idea that “constrained” world is more meaningful than “aligned”. But again, “aligned” does not mean “free” and it contains “constrained” meaning.
And your option “constrain” does not look like a constrained handle but rather to a frozen one.

In this case, if you feel that the documentation does not correspond to current behaviour. I think it is more pertinent to change the documentation than blender.

+1
It is a good idea.

6

I’m not married to the current behavior, but I think zeauro’s response is the most suitable.

7

I’m not talking about adding another handle-type. I’m talking about changing the way the handle-type-set menu works.

I think it is more pertinent to change the documentation than blender.

Have you tried this? Try to write a precise documentation of what the “free” and “align” menu choices currently do. I didn’t even understand how they worked until I read the code. Here is my attempt to describe the current behavior. I probably still missed something…

select-handle -> Set Handle Type -> Free -> Allows the handle to be moved independently of the other handle if the other handle is also set to free or vector. If the other handle is Align, then Free merely means you can move this handle, but the other handle will move with it. If you wish this handle to move independently of the other, you need to change the other handle to free as well.

select-handle -> Set handle type -> align -> sets the spline to align in a straight line. This handle will be movable if the other handle is also align. If the other handle is free or vector then this handle will be constrained and not able to move the aligned spline. In order to be able to move this side of the aligned spline, set the other side of the spline to align as well.

This is the description of my version:

select-handle -> set handle type -> free -> Allows the handle to be moved freely from the other handle.
select-handle -> set handle type -> align -> Aligns the spline into a straight line which can be moved from either handle.
select-handle -> set handle type -> constrain -> constrain rotation of this handle to match the other handle.

If you know something about the nitty-gritty-details of blender… I achieve this by changing the mapping from the menu options to spline-handle-type-configuration.

my free -> free / free
my align -> align / align
my constrain -> align / free

Essentially, I bury all that complex logic about how to get the results you want into my set-handle-type code, so the user can just think about the simple thing he wants to do with the single handle he has selected.

Make sense? Do you see how my model allows a simpler usage-model? Where you can change the behavior of the handle you have selected, without mucking with the other handle?

8

I understand I think, but my workflow is different in that a select the point and not just the handle, and change the handle type to affect both handles at the same time. Odd maybe, but that is how I use them.

9

@davesf the more I think about it, the more I think you’re overthinking/overcomplicating things. Semantically, the behavior is exactly like I’d expect it. That is, if I want both handles to move independently of one another, then the most logical thing to do would be as Craig Jones does: select the control point itself. However, if I choose just one handle and decide to set it as free, then by definition I’m only changing the property of that one handle. The other handle is not affected at all, so it makes sense that it would continue to align itself. It might be slightly less convenient if you’re not in the habit of selecting the actual control point, but it certainly makes sense.

Bottom line: if you want both handles to move independently of one another, select the control point and make the change there. It’s fewer clicks anyway. :slight_smile:

10

I agree with Fweeb. Current behavior is visually the most simple and logical.
Select one handle -> set handle type just for this handle.
Select control point (= 2 handles) -> set handle type for both handles.

Your proposal is :
For free/align/constrain type , select one handle -> set handle type for two handles.
For vector type, select one handle - > set handle type for one handle.

11

If you only handle set by selecting the anchor and setting the same handle-type on both handles, then this conversation is irrelevant to you, because my code works exactly the same as the old code in this case. THis discussion is about people who use the mixed states, like align/vector, align/free, and align/vector.

For a moment, let’s pretend the current behavior is “okay” and the documentation should be fixed. Do you know what it should say? I doubt most people even know how it works. Currently the docs say “Free - The handles are independent of eachother”…

http://wiki.blender.org/index.php/Doc:2.6/Manual/Modeling/Curves

I’ve spent the last couple days rewriting this code, and today, this is a proper documentation of the current handle set behavior:

Set Handle Free = “The handle will rotate and scale independently of the other handle, as long as the other handle is set to free, vector, or automatic (which will be converted to free). If the other handle is set to align, then it will be rotation constrained and aligned to this handle even when this handle is set to free. In order to get them to move independently, set the other handle to free or vector.”

Set Handle Align = “The handle will be aligned with the other spline. This handle will be free to be rotated and scaled only if the other handle type is Align, or Automatic (which will be converted to Align). If the other handle type is Free or Vector, then this handle will be unable to control rotation, grabbing it will only allow the handle to scale along the aligned axis. To allow this handle to also rotate the aligned spline, set the other handle to align.”

IMO, this is crazy complicated. People are not computers running Blender’s wacky handle code. We need simple models.

After my patch, this is the documentation:

Handle Set Free - The handle will move independently of the other handle.
Handle Set Align - The handle will align to the other handle. (both sides are draggable)
Handle Set Constrain - The handle’s rotation will be locked, constrained to the other handle.

…and if I find a clean solution…

Handle Set Align Mirror - The handles will stay aligned and mirror each other’s length.

Do you still assert the current toggle behavior is easier to understand? The handle-functionality is exactly the same, so there is no debate there. This is merely about the cognitive model of the handle-set-menu.

12

…ohh, and BTW… if anyone has ideas/mockups/opinions about how to visualize when a handle which is “rotation constrained” (aka, can’t be rotated), I’d like to add that.

13

Yes… zeauro and I both explained it pretty succinctly (though I’ll admit to being a bit surly).

Given the choice, I’d keep the current behavior (I do find it easier to understand) and opt for investigating equal-length handles (though I’ve very rarely ever needed that feature). Even more interesting would be an implementation of vertex slide for curve control points.

14

I don’t understand why it is a problem that would require a patch to add another type.
I don’t see the problem with the doc, except the fact that words of the sentences are in the plural.
All is fine if sentences are set in the singular form.
Free : the handle is independant of the other one.
When there is one handle Free and the other Align, it is not the “Free” handle that is constrained to “Align” handle. Free Handle is still free to be displaced.
It is “Align” handle that can not move. And it is logical because it is aligned to the Free Handle.

There is no big problem with the explanation of Free type.
You just have to specify for Align handle that it is always aligned to other handle of control point. Accordingly it can only be rotated if both handles of the control point share this same type.

I think it clarifies to set documentation to singular form to describe a conversion behavior that works independently per each handle.
I don’t see a need to add a conversion behavior that will change both handles of a control point after selection of only one handle to set finally document in the singular form.
Because the way you describe it, your new types are not handle types but control point types.

I agree with Fweeb. I would prefer an equal-length option that could work with all types rather than an align-mirror type limited to aligned handles.

15

After some digging, I think this is at least partly a discrepancy because of British vs US English differences in meaning for the words “free” and “independent”.

In US English, something is “free” only if it is “not united with, attached to, combined with or mixed with something else”. The words for something “not affected by another” in US English are “unconstrained”, “unaffected”, or “unbiased”.


http://www.macmillandictionary.com/us/dictionary/british/free

I don’t think language differences explains the “align” confusion though. Both US and British English say align is “to organize things so they form a straight line or are in the correct position in relation to other things”… which says nothing about the causality or precedence of that alignment.

What happens during blender’s align/free state is not “alignment” but “alignment and constraint”.

The full-set of valid operations possible on handles are (in US English):

“Free” is an action on two handles, to make them rotate independently from each other
“Align” is an action on two handles, to make them align to each other
“Unconstrain” is an action on a single handle, to unconstrain it’s motion to the other. (formerly free, sort-of)
“Constrain” is an action on a single handle, to constrain it’s motion to the other. (formerly align, sort-of)

My current proposal/patch is: (informed by this thread and others!!)

“Free” is an action on two handles, to make them rotate independently from each other
“Align” is an action on two handles, to make them align to each other
“Align (constrained)” is an action on a single handle, to constrain it’s motion to the other. (formerly align, sort-of)

Do you have an alternate set of actions and descriptions which you think are valid in both US and British English?

16

I am French.
So, I am not particularly perturbed by that.

“Free” is an action …
“Align” is an action …
“Unconstrain” is an action…
“Constrain” is an action…

Your way of thinking appears to me more clearly here.
The user does not really think of these buttons as actions. What is important is the state of the handle represented by its color.
And each button is just a way to convert an handle state to another.
“Vector” is not a verb. If “Align” is probably used instead of “Set to Aligned” because it is a shorter word that takes less space in the UI.

Actually, conversion works according to selection (single handle or control point).

I understand the need to convert only one handle. It is a need actually satisfied.
I understand that the meaning of 4 types (free, align, vector, automatic) is not automatically obvious for people who don’t know the software.
But I think that if you take some minutes to think about it; you can rapidly adopt it.

What I don’t understand and find overcomplicated is your need to keep buttons to convert two handles and create a button to convert a single handle.

I have no problem with an additionnal operator to align two Free handles and keep them Free.
But it should not be confused with existing “Set Type of Handles” opearators as it is said in the tooltip.

I think the problem is that UI was too much simplified.
In Curve Tools Panel, “Handles” title for these buttons should be replaced by “Set Handles Type”.
If you look at the UI of mask, it uses the words “Handle Type” and “Aligned”.

17

@davesf: I don’t want to get into the semantics of language too much here, but you’re using verbs when you ought to be using adjectives (note that it’s “Aligned”, not “Align” in the interface).

I much prefer that an operation only apply to the actual active selection. If I’m selecting one handle and changing the behavior (it’s adjective) of that handle, then I don’t want it to change the behavior of any other handle that I don’t have selected.

If you’re hung up on the word “Free”, then perhaps think of it like this: A boy and a stray dog are walking down the street together; they are aligned. The boy decides he wants to walk a different direction; he is free. However, the stray dog is still aligned, so he follows the boy. This is proper mixed use for free and aligned. If we want the boy and dog to both walk different directions, then they would both need to be free (i.e. selecting the control point). It doesn’t make sense to have handles set with one free and the other aligned, but they both move independently (that would be free/free).

18

The adjective “Aligned” does not imply constraint.

The dog-analogy does not say the same thing to me. If a dog decides to turn and the leash causes his (aligned) master to follow, he is not “free”. He is only “free” when the connection between the two has been severed. Likewise, if the (aligned) master pulls, the dog will follow, he’s not constrained.

I have made an ALTERNATE version of this patch which merely “fixes the documentation (and bugs)”… I don’t prefer this patch, because I think it’s confusing, but it is still better than the current situation.

The tooltips / docs for the two versions are:

  • #1 KEEP-DOCS / FIX-BEHAVIOR
    [LIST]

  • Free - allows the handle to rotate independently from the other handle.

  • Align - aligns the handle with the other handle

  • Align + Constrain - aligns the handle with the other hand and constrains it’s rotation

  • #2 KEEP-BEHAVIOR / FIX-DOCS

  • Free - Align the handle(s) to the other. If the other handle is Free, Vector, or Auto, this will cause the handle to be rotation constrained.

  • Align - Allow the handle(s) to freely rotate. To allow the handle to rotate independently, set the other handle to Free, Vector, or Auto.

[/LIST]

Pesonally, I think if you TRY the two versions, instead of talking about them, it’s pretty darn obvious that patch #1 works better. However, now we have both options. I’ll see which one I can get pushed through.

http://lists.blender.org/pipermail/bf-committers/2013-July/041180.html

19

Alright… now it just feels like you’re trying to argue for the sake of it. There is no leash.

20

If there is no leash, then why does the other side of the spline follow?

When I make a handle “Free”, I want it to be unconnected from the other handle, just like your dog is unconnected from his master. That is not the case today. You set the handle free, and it’s still stuck to the other one if that other one is of a certain type (align).