Age | Commit message (Collapse) | Author |
|
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
|
|
|
|
to original state
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.
|
|
* Frame Step now works correctly and as expected
* Second Step kindof works, but the handles are not well behaved.
|
|
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.
|
|
|
|
|
|
|
|
This reverts commit 6cc5bdc99e63b05248f132833bfe0259c2a27923.
Revent this for 2.70a, it changes behavior too much without allowing
keyframe handles to be scaled some alternative way.
|
|
|
|
was a (minor) bug).
|
|
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.
|
|
|
|
A regressions since 2.69, eeeh.
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
|
|
This matches 3d view and means you can change the amplitude of a curve
while keeping auto-clamped handles.
|
|
This was only set when the camera was active, however non active cameras
can be transformed too.
|
|
|
|
This reverts commit f72acc38d 65c5be967 eff6b385e 3fe487217
|
|
|
|
This commit hopefully fixes all glitches we had when bone was Z-aligned. Note that when you init a transform
with a Z-aligned bone and change it to be non-Z-aligned, you will still get some brutal roll change,
there is not much things we can do here afaik...
|
|
|
|
Basic idea is now to have the transformes bones keep "facing" the armature's Z axis, see comments in code for details.
That might not be ideal, but at least we now have humanly predictable and consistent results.
|
|
Disable transform and mask display when there's no active clip.
It's not a matter of returning fallback dimensions if there's no
slip, it's also matter of making it so stabilization and distortion
routines are aware of clip == NULL which is really crappy.
Also almost all the operators are disabled in clip editor without
active clip already anyway.
Also tweaked header UI a bit to not display mask stuff when there's
no active clip,
|
|
D187 was committed without review and later rejected by Brecht and myself.
|
|
|
|
|
|
|
|
keyboard input
Issue was in fact in strip update code when transforming, in case we move both left and right
handles the strip is handled twice in the loop, but it was always updated at the end of the
first loop only...
|
|
|
|
|
|
|
|
|
|
|
|
This was caused by recent change to transform locations being changed
to the upper-left corner of nodes (rBa857a6f).
|
|
|
|
During drag the H key can be used to toggle the hide flag of the selected nodes.
This makes it easier to 'attach' nodes to available links in narrow places.
|
|
Because of the issue of how simplification works, there could
be more flags in on->recalc bitfield which are ignored by object
anyway.
Would save some update calls after simplificating the scene.
|
|
It was actually rather simple to make sure depsgraph is up to date
before calling BKE_object_handle_update() in the transform code by
just moving DAG_scene_relations_update() to the beginning of the
function.
Wouldn't expect any side effects for other cases since DAG is not
used bu the code between new location of the call and old one.
|
|
also increase precision of rctf print functions
|
|
|