Issue here is that we force mirroring even if original armature is not
mirrored.
We could be smart and store only unselected mirrored bones here (since
those will get restored from transdata), however not all properties were
getting stored and restored; rolling bones still suffered from the bug
for instance.
To fix this we need to restore all properties that armature mirroring
overrides. Transdata obviously does not offer a lot of space here, so I
used TransInfo->customdata to store an array of initial parameters of
the mirrored bones.
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.
Just remove that rotation special case for now, at least fixes the glitch along Z axis when rotating around Y axis in report.
Anyway, there is no reason for such special handling, we do not have real rotation in editbone...
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.
Changed curve active point from pointer to index. Allows curve active point to be saved to file and retained between modes for free. Also some small optimisations by removing pointer look up code.
- Made active point access functions into BKE API calls.
- Fixes operators where curve de-selection resulted in unsel-active point.
- Split curve delete into 2 functions
Remove usages of ANIM_unit_mapping_apply_fcurve in favor of
runtime scale factor apply.
There're still calls to ANIM_nla_mapping_apply_fcurve are
hanging around, they're the next t be cleaned up!
wrong button.
Works by adding a flag to transform operators "remove_on_cancel". This is currently only used for node transforms, the idea is that if set, the operator will remove the transformed elements when it is
cancelled. It's not possible to do that in the original NODE_OT_add_node operator, because transform is modal and there is no way of reacting to a cancel outside of the transform itself (previous attempt
used a macro operator, but that also doesn't work because subsequent operators don't get executed if the previous transform cancels).
- Do plane re-evaluation only when transform is actually done.
Before this re-evaluation happened on every mouse move.
- Added a flag "Auto Keyframe" for the plane track, which does:
* If Auto Keyframe is enabled, then every manual edit of the
plane will create a new keyframe at current frame and update
plane motion between current frame and previous/next keyframe.
This now also implies blending detected motion with neighbor
keyframes, so there's no jump happening.
No automatic update on manual point tracks edit will happen.
* If auto Keyframe is disabled, then no keyframes are adding
to the plane and every plane tweak will re-evaluate in on
the whole frame range.
In this case manual tweaks to point tracks and re-tracking
them implies plane re-evaluation.
This commit includes all the changes made for plane tracker
in tomato branch.
Movie clip editor changes:
- Artist might create a plane track out of multiple point
tracks which belongs to the same track (minimum amount of
point tracks is 4, maximum is not actually limited).
When new plane track is added, it's getting "tracked"
across all point tracks, which makes it stick to the same
plane point tracks belong to.
- After plane track was added, it need to be manually adjusted
in a way it covers feature one might to mask/replace.
General transform tools (G, R, S) or sliding corners with
a mouse could be sued for this. Plane corner which
corresponds to left bottom image corner has got X/Y axis
on it (red is for X axis, green for Y).
- Re-adjusting plane corners makes plane to be "re-tracked"
for the frames sequence between current frame and next
and previous keyframes.
- Kayframes might be removed from the plane, using Shit-X
(Marker Delete) operator. However, currently manual
re-adjustment or "re-track" trigger is needed.
Compositor changes:
- Added new node called Plane Track Deform.
- User selects which plane track to use (for this he need
to select movie clip datablock, object and track names).
- Node gets an image input, which need to be warped into
the plane.
- Node outputs:
* Input image warped into the plane.
* Plane, rasterized to a mask.
Masking changes:
- Mask points might be parented to a plane track, which
makes this point deforming in a way as if it belongs
to the tracked plane.
Some video tutorials are available:
- Coder video: http://www.youtube.com/watch?v=vISEwqNHqe4
- Artist video: https://vimeo.com/71727578
This is mine and Keir's holiday code project :)
of the active object in the 3D view. This was due to sharing a global G.moving
flag to indicate that transform is active, now it's only set per transform data
type so different editors don't influence each other.
Crash happened in ED_view3d_calc_zfac and happend in cases operator was invoked
from a region different from RGN_TYPE_WINDOW.
For a transformation zfac is only used in convertViewVec in cases region is
RGN_TYPE_WINDOW, so solved by just adding extra check in calculateCenter
for this particular case.
