Since autosnap was being applied during the flushing step for various practical reasons,
it wasn't possible to restore keyframes and handles to their original values, as these
would always get overwritten before getting a chance to be written back to the keyframes.
Since the NLA was also using the standard transform mode by default, this meant that
no frame/second step-snapping was happening here (i.e. like for the Graph Editor).
The actual differences between doing true stepping vs nearest here are quite small
(and don't really make much sense with NLA Strips), so for now, it should be fine that
these are the same.
The previous behaviour for nearest second meant that transforming the strips often
caused their lengths to change (sometimes drastically), since strip lengths aren't
always uniformly x-seconds long. Now, it only snaps the start frame value, and adjusts
the end of the strip to follow.
This works well for most cases, apart from negatively scaling the strip, where it will
get "stuck" as a 0.001 frame long strip (and the viewport drawing will be a bit weird
during this time). Nevertheless, negative scaling of strips isn't something that's exactly
recommended.
This commit cleans up and fixes some problems related to how the auto-snapping
behaviour in the animation editors works, resolving the issues mentioned in T39819.
1) "Nearest Frame" no longer snaps to the nearest second when time is displayed in seconds.
Instead, there is now also a "Nearest Second" option, so that either can be used
as needed instead of only when a certain time display is used.
2) A similar change has been made for "Time Step" - This is now "Frame Step" and "Second Step"
respectively.
Notes:
* Removed the unneeded getAnimEdit_DrawTime()
* Time Step/Frame Step don't work for Graph Editor yet (and seem to not have worked at all)
* NLA Editor also seems to be showing some weirdness now. Will be checked on.
* Cancelling nearest-second snapping doesn't work nicely, due to another bug with GraphEdit transforms.
View2D had some inconsistencies making it error prone in some cases.
- Inconstant checking for NULL x/y args.
Disallow NULL args for x/y destination pointers, instead add:
- UI_view2d_region_to_view_x/y
- UI_view2d_view_to_region_x/y
- '_no_clip' suffix wasn't always used for non-clipping conversion,
switch it around and use a '_clip' suffix for all funcs that clip.
- UI_view2d_text_cache_add now clips before adding cache.
- '_clip' funcs return a bool to quickly check if its in the view.
- add conversion for rectangles, since this is a common task:
- UI_view2d_view_to_region_rcti
- UI_view2d_region_to_view_rctf
This reverts commit 6cc5bdc99e.
Revent this for 2.70a, it changes behavior too much without allowing
keyframe handles to be scaled some alternative way.
Summary:
The title actually says it all, it's just possible to
have independent free handles for mask splines. Also
it's now possible to have aligned handles displayed
as independent handles.
Required changes in quite a few places, but they're
rather straightforward.
From user perspective there's one really visible change
which is removed Handle Type menu from the panel. With
asymmetric handles it's not clear which handle type to
display there. So now the only way to change handle type
is via V-key menu.
Rewrote normal evaluation function to make it deal
with new type of handles we support. Now it works in
the following way:
- Offset the original spline by maximal weight
- Calculate vector between corresponding U positions
on offset and original spline
- Normalize this vector.
Seems to be giving more adequate results and doesn't
tend to self-intersect as much as old behavior used to,
There're still some changes which needed to be done, but
which are planned for further patch:
- Support colors and handle size via themes.
- Make handles color-coded, just the same as done for
regular bezier splines in 3D viewport.
Additional changes to make roto workflow even better:
- Use circles to draw handles
- Support AA for handles
- Change click-create-drag to change curvature of the
spline instead of adjusting point position.
Reviewers: campbellbarton
CC: sebastian_k, hype, cronk
Differential Revision: http://developer.blender.org/D121
Transform operators for nodes were not taking parent nodes (frames) into
account. Now use the nodeToView/nodeFromView functions to apply
transforms in local node space.
Ways how it was resetting its values (backspace) was far from satisfaying. Now, e.g. when scaling, it will reset at 1 (or whatever mouse-value it was before entering numinput), instead of some ugly 0.0 value.
Implementation details:
* Values passed to applyNumInput() are stored as default ones (val_org), if it is not EDITED.
* applyNumInput() returns a boolean saying whether it actually set values or not.
* When backspace hits its ultimate step (where it clears all EDITED flags and reset all default values),
it sets a temp FAKE_EDITED flag that will be used to apply one last time values of numinput
(so that default values actually get applied!).
There are important things to note here for code using numinput:
* Values passed to applyNumInput() should be valid and are stored as default ones (val_org), if it is not EDITED.
* bool returned by applyNumInput should be used to decide whether to apply numinput-specific post-process to data.
* *Once applyNumInput has been called*, hasNumInput returns a valid value to decide whether to use numinput as drawstr source or not.
Those two steps have to be separated (so do not use a common call to hasNumInput() to do both in the same time!).
Was using wire or black in many places, this color is used for cursor,
camera guides, transform helper lines. So its possible to have a dark
background with light overlay color.
Patch D331 by Brita, with some edits.
There were 3 bugs with both data types
- using freed memory while sorting.
- sorting failed in some situations.
- scaling allowed multiple items to be on the same frame.
Replace this with a simple sort + de-duplicate, taking selection into account.
