| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This reverts commit 6cc5bdc99e63b05248f132833bfe0259c2a27923.
Revent this for 2.70a, it changes behavior too much without allowing
keyframe handles to be scaled some alternative way.
|
|
|
|
Some more float precision issue...
|
|
|
|
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.
|
|
|
|
results in 0.5828 increments
Interesting one, took me hours to understand the issue - a stupid typo checking the wrong value against the wrong flag (present since 2008!).
|
|
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.
|
|
|
|
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.
|
|
|
|
also comment debug prints for raytracing
|
|
|
|
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.
|
|
|
|
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 reverts commit f72acc38d 65c5be967 eff6b385e 3fe487217
|
|
Using length units outside of 3dview does not make sense...
|
|
|
|
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.
|
|
|
|
|
|
Use Z axis for the edge direction for edges and vertex pairs.
Issue raised in T38592, now edge select and vert-pairs share logic
for calculating orientation and the active vertex determines direction.
|
|
|
|
|
|
|
|
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...
|
|
|
|
Snap code may be called with a NULL region, add check about this and assume ray_start is OK in this case!
|
