improvements to spline behavior with a SINGLE handle selected #36029

New Issue

David Jeske · 2013-07-06T07:41:07+02:00

David Jeske commented

2013-07-06 07:41:07 +02:00

%%%The initial motivation for this patch was resolving a discrepancy between the code-behavior of setting a spline handle to "Free", the Blender documentation, and the English definition of "free and independent".

This patch improves several elements of working with single spline handles...

resolves wording/behavior ambiguities in handle-type-set when a SINGLE handle is selected (see below)
makes it possible to "Scale" a single-selected spline handle, assuring it's rotation is not changed (previously you could only scale both handles together)
adds a visual indicator that a spline handle is rotation locked ("T" the end of the spline) - http://www.pasteall.org/pic/54987
makes the code safer/clearer by introducing the enum eHandleSetModes, instead of using integer conventions
fixes BUG: where two handles selected without the anchor had incorrect spline handle selection highlighting
fixes BUG: where a single selected handle would not toggle to "Automatic" correctly

NOTE: This patch does NOT change the meaning of the code flags HD_ALIGN / HD_FREE, it merely changes how BKE_nurbList_handles_set() maps change-actions to flag-states. There are no file-format compatibility issues, because it does not change the meaning or behavior of the handle-mode-types, it merely changes how the menu-actions map onto them when a SINGLE half of the spline handle is selected.

Notes about #1:

A precise description of the "current" 2.67b Handle-Type-Set-Menu action behavior, with a single handle selected, is...

"Free" - Allow this handle to be moved independently of the other handle if the other handle is not Align. If the other handle is align, then the handles will remain in alignment and the other handle will become rotation constrained. To unconstrain the other handle, set this handle to Align.
"Align" - Align this handle with the other handle. If the other handle is Align, this handle will be freely movable, otherwise, this handle will be rotation constrained. To free the rotation constraint, set the other handle to align or this handle to free.

A precise description of the Handle-Type-Set-Menu after this patch is:

"Free" - Allow this handle to be moved independently of the other handle. (regardless of the other handle's mode)
"Align + Constrain" - Align this handle with the other, and constrain it's rotation.
"Align" - Align the two handles and allow them to freely move. (If the other handle is vector, this implies Align + Constrain)

%%%

%%%The initial motivation for this patch was resolving a discrepancy between the code-behavior of setting a spline handle to "Free", the Blender documentation, and the English definition of "free and independent". This patch improves several elements of working with single spline handles... 1) resolves wording/behavior ambiguities in handle-type-set when a SINGLE handle is selected (see below) 2) makes it possible to "Scale" a single-selected spline handle, assuring it's rotation is not changed (previously you could only scale both handles together) 3) adds a visual indicator that a spline handle is rotation locked ("T" the end of the spline) - http://www.pasteall.org/pic/54987 4) makes the code safer/clearer by introducing the enum eHandleSetModes, instead of using integer conventions 5) fixes BUG: where two handles selected without the anchor had incorrect spline handle selection highlighting 6) fixes BUG: where a single selected handle would not toggle to "Automatic" correctly NOTE: This patch does NOT change the meaning of the code flags HD_ALIGN / HD_FREE, it merely changes how BKE_nurbList_handles_set() maps change-actions to flag-states. There are no file-format compatibility issues, because it does not change the meaning or behavior of the handle-mode-types, it merely changes how the menu-actions map onto them when a SINGLE half of the spline handle is selected. Notes about #1: A precise description of the "current" 2.67b Handle-Type-Set-Menu action behavior, with a single handle selected, is... "Free" - Allow this handle to be moved independently of the other handle if the other handle is *not* Align. If the other handle is align, then the handles will remain in alignment and the other handle will become rotation constrained. To unconstrain the other handle, set this handle to Align. "Align" - Align this handle with the other handle. If the other handle is Align, this handle will be freely movable, otherwise, this handle will be rotation constrained. To free the rotation constraint, set the other handle to align or this handle to free. A precise description of the Handle-Type-Set-Menu after this patch is: "Free" - Allow this handle to be moved independently of the other handle. (regardless of the other handle's mode) "Align + Constrain" - Align this handle with the other, and constrain it's rotation. "Align" - Align the two handles and allow them to freely move. (If the other handle is vector, this implies Align + Constrain) %%%

David Jeske commented

2013-07-06 07:41:07 +02:00

Changed status to: 'Open'

David Jeske commented

2013-07-06 07:59:39 +02:00

%%%A couple more notes about things that might be valuable after this patch is accepted:

make "ALIGN" always move the currently selected handle to the other. Currently it moves the first handle in spline direction order.
make a property panel to visualize / edit the active spline handle state
review the graph-editor spline behavior to see if something should be adjusted to match/clarify/fix bugs
maybe : add "mirror" functionality, to get typical "aligned + length mirrored" splines (new file/data extension)
maybe : add the ability to rotation lock both spline handles (aka, constrain both handles, allowing no rotation) (new file/data extension)

%%%

%%%A couple more notes about things that might be valuable after this patch is accepted: - make "ALIGN" always move the currently selected handle to the other. Currently it moves the first handle in spline direction order. - make a property panel to visualize / edit the active spline handle state - review the graph-editor spline behavior to see if something should be adjusted to match/clarify/fix bugs - maybe : add "mirror" functionality, to get typical "aligned + length mirrored" splines (new file/data extension) - maybe : add the ability to rotation lock both spline handles (aka, constrain both handles, allowing no rotation) (new file/data extension) %%%

David Jeske commented

2013-07-06 09:09:41 +02:00

%%%tiny patch update to add tooltips for the the handle-type-set-menu modes%%%

David Jeske commented

2013-07-07 20:01:56 +02:00

%%%FYI - After much deliberation about feedback on BA, I've decided to take a different route than I did with Patch [#36029]. I am going to create a NEW version of this spline-fix-patch which fixes the tooltips, bugs, and adds "rotation constraint" visuals -- while leaving the current behavior untouched -- where handle-set always affects only selected handles. I will also fix the wiki documentation to match the current behavior.

Why?

I created this patch because I want the documentation, tooltips, behavior, and visuals to all match -- it doesn't matter to me which way it works, so long as it's clear. When I started, the only thing that I understood was the documentation, partially because the current behavior is not documented and partially because bugs in the visuals make it confusing. Now that I fully understand the (intended) current behavior, I see a way to fix the tooltips, docs, and visuals which will be (mostly) consistent with the current behavior.

Some factors in my thinking:

While using patch [#36029], I have seen that 90% of the confusion with the current system can be eliminated simply by showing visuals for "rotation constrained" handles.
I can see the desire for handle-set behavior which only "touches" the state of the handle(s) which are actually selected.

But mostly:

I've realized that the "behavior inconsistency" is not possible to eliminate with either approach without breaking file-format compatibility -- something which I don't think is worth it at this point. That inconsistency is the overloading of "align" and "constraint" behavior, such that an align handle in align/free is rotation constrained, but in align/align is not rotation constrained. The overloading also has the side-effect that there is no way to rotation-constrain both handles. Other features which have been requested are also not possible without some amount of file-format conversion/confusion.. including rotation constraining both handles, and length-mirroring both handles.

... new patch coming soon.%%%

%%%FYI - After much deliberation about feedback on BA, I've decided to take a different route than I did with Patch [#36029]. I am going to create a NEW version of this spline-fix-patch which fixes the tooltips, bugs, and adds "rotation constraint" visuals -- while leaving the current behavior untouched -- where handle-set always affects only selected handles. I will also fix the wiki documentation to match the current behavior. Why? I created this patch because I want the documentation, tooltips, behavior, and visuals to all match -- it doesn't matter to me which way it works, so long as it's clear. When I started, the only thing that I understood was the documentation, partially because the current behavior is not documented and partially because bugs in the visuals make it confusing. Now that I fully understand the (intended) current behavior, I see a way to fix the tooltips, docs, and visuals which will be (mostly) consistent with the current behavior. Some factors in my thinking: - While using patch [#36029], I have seen that 90% of the confusion with the current system can be eliminated simply by showing visuals for "rotation constrained" handles. - I can see the desire for handle-set behavior which only "touches" the state of the handle(s) which are actually selected. But mostly: I've realized that the "behavior inconsistency" is not possible to eliminate with *either* approach without breaking file-format compatibility -- something which I don't think is worth it at this point. That inconsistency is the overloading of "align" and "constraint" behavior, such that an align handle in align/free is rotation constrained, but in align/align is not rotation constrained. The overloading also has the side-effect that there is no way to rotation-constrain both handles. Other features which have been requested are also not possible without some amount of file-format conversion/confusion.. including rotation constraining both handles, and length-mirroring both handles. ... new patch coming soon.%%%

David Jeske commented

2013-07-07 21:26:42 +02:00

%%%After creating the new patch, it seems VERY apparent to me how confusing and busted the old behavior of this menu is.. I STRONGLY recommend using this [#36029] patch over [#36048].

However, either is better than the current situation... [#36048] at least adds tooltips so it's possible to understand what is going on with spline handle type sets.

http://projects.blender.org/tracker/?func=detail&aid=36048&group_id=9&atid=127%%%

%%%After creating the new patch, it seems VERY apparent to me how confusing and busted the old behavior of this menu is.. I **STRONGLY** recommend using this [#36029] patch over [#36048]. However, either is better than the current situation... [#36048] at least adds tooltips so it's possible to understand what is going on with spline handle type sets. http://projects.blender.org/tracker/?func=detail&aid=36048&group_id=9&atid=127%%%

Christopher Barrett commented

2013-09-12 23:02:56 +02:00

%%%I'm working on implementing bezier curves in the movie clip editor.
We need 'Free' as a handle type, and need to add the code to select and move both handles around.
This will standardize Blender with other applications and allow the importation of rotoscoping masks and curves from other apps.
I met Sergey at Siggraph and he is going to help.
You could make my work a lot easier since you already have your head around how to make these changes.
Could you contact me at goodspiritgraphics.com?%%%

%%%I'm working on implementing bezier curves in the movie clip editor. We need 'Free' as a handle type, and need to add the code to select and move both handles around. This will standardize Blender with other applications and allow the importation of rotoscoping masks and curves from other apps. I met Sergey at Siggraph and he is going to help. You could make my work a lot easier since you already have your head around how to make these changes. Could you contact me at goodspiritgraphics.com?%%%

Campbell Barton commented

2013-09-30 09:21:40 +02:00

%%%Updated the patch for r60428.%%%

Campbell Barton commented

2013-09-30 18:48:06 +02:00

%%%closing requested by David Jeske%%%

Campbell Barton commented

2013-09-30 18:48:06 +02:00

Changed status from 'Open' to: 'Resolved'

Campbell Barton closed this issue

2013-09-30 18:48:06 +02:00

Sign in to join this conversation.

No Label

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

improvements to spline behavior with a SINGLE handle selected #36029