Age | Commit message (Collapse) | Author |
|
Currently "long keyframes" are only useful for indicating where stationary
holds occur. If however you try to create a "moving hold" (where the values
are slightly different, but in terms of overall effect, it's still a hold)
then it could get tricky to keep track of where these occur.
Now it's possible to tag such keyframes (using the keyframe types - RKEY)
as being part of a moving hold. These will not only be drawn differently
from normal keyframes, but they will also result in a "long keyframe"
being drawn between each pair of them, just like if they had been completely
stationary instead.
Currently the theming/styling of these is a bit rough. They reuse the existing
theme colours for long keyframes.
|
|
To get this working the least effort, I've had to expose the helper functions
used by the lasso and circle select keyframe-test callbacks (which are generic)
and expose them for use by the GP keyframe editing code too. Hopefully in time
we clean this all up and just write the code once to operate on "keyframes"
|
|
This only works in the Action and Dopesheet modes (which operate on FCurve keyframes).
Support for Grease Pencil and Mask Keyframes though is still pending.
|
|
|
|
crashes Blender
Simple NULL-check seems fine here, working as it should now. Most likely caused by rBc4dc14b079d81.
|
|
|
|
TweakMode
When in TweakMode on NLA strips that had an offset, it was not possible to select
those keyframes in the Summary Channel in the Dope Sheet.
The main gist of it is that the current code is from before the summary track was
introduced, and so could assume that ANIM_nla_mapping_get() would work for all channels
present. Thus, simply converting the clicked frame to nla-mapped time once would be
enough. However, for summary channels, nla-mapping_get() doesn't do anything, since
we can potentially include keyframes from several different objects!
|
|
When using the "Current Frame" options for these operators, the Cursor X value
will now be used instead of the current frame. Perhaps the labels could be changed
too, but for now, I guess this will be good enough.
|
|
|
|
axis.
Names are rather confusing here... :/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
ANIM_editkeyframes_refresh was testing handle selection as if those handles were transformed.
This is already handled by areas which need it,
so simply replace testhandles_fcurve -> calchandles_fcurve.
This was causing other bugs such as inserting a keyframe changing handles of unrelated fcurves.
|
|
Opted to keep includes if they are used indirectly (even if removing is possible).
|
|
This option (alongside the Ease In/Out/InOut options already available) aims to make it
easier to get an initial curve that looks closer to the one you were expecting, by
automatically picking whether Ease In or Ease Out should be used based on the type of
interpolation being used for the curve segment in question.
Notes:
* The types chosen may need some adjustments (e.g. using ease in-out instead of just ease in)
* This does break compatability with files saved in previous dev builds, but only
if you were using Bounce/Elastic/Back with "Ease In"
|
|
|
|
|
|
|
|
This commit introduces support for a number of new interpolation types
which are useful for motion-graphics work. These define a number of
"easing equations" (basically, equations which define some preset
ways that one keyframe transitions to another) which reduce the amount
of manual work (inserting and tweaking keyframes) to achieve certain
common effects. For example, snappy movements, and fake-physics such
as bouncing/springing effects.
The additional interpolation types introduced in this commit can be found
in many packages and toolkits (notably Qt and all modern web browsers).
For more info and a few live demos, see [1] and [2].
Credits:
* Dan Eicher (dna) - Original patch
* Thomas Beck (plasmasolutions) - Porting/updating patch to 2.70 codebase
* Joshua Leung (aligorith) - Code review and a few polishing tweaks
Additional Resources:
[1] http://easings.net
[2] http://www.robertpenner.com/easing/
|
|
|
|
|
|
|
|
selected but not the mid-point.
only one of the handles would be changed to the HD_FREE.
effected curves and fcurves.
|
|
* Reverted the changes to code comments, as suggested by Campbell. It makes it more hard to follow.
* Only keep changes to actual UI messages.
|
|
* DopeSheet -> Dope Sheet. No need to glue the words together.
Only changed comments and UI strings, no functional changes. Request by Dalai Felinto.
|
|
|
|
|
|
our naming convention.
|
|
use where possible.
|
|
|
|
|
|
parsers that done expand macros.
|
|
|
|
|
|
already used a lot and part of proposed style guide).
|
|
hidden, resulting in bad curves.
hide handles wasn't properly respected by transform function testhandles_fcurve().
|
|
also fixed own errors in recent static check commit.
|
|
So apparently this was a regression from 2.4x, since vector handles
were one of the handle types which could be set independently for each
handle (vs both needing to be the same, for example, Auto Handles)
|
|
Causing a flurry of refresh file prompts post-commit,
Confusing local diffs and causing merge conflicts,
Stating the obvious; redundant and useless...
We shall not miss thou, blasted expand $keywords$
|
|
* Tweaked order of handle types to make it easier to find Auto/Auto-
clamped in the list
* Fixed a number of places which were still just checking for auto-
handles when they should have included auto-clamped too, including
handle rotation
|
|
handle/key
This used to be a weird per-curve setting which would happen to get
applied/work correctly if handles were set to "auto", and was a source
of constant confusion for both old and new animators. The main effect
of this handle-type/option was really to just ensure that auto-handles
stayed horizontal, instead of tilting as the keys were moved.
This commit simply changes this from a per-curve to per
keyframe/handle setting.
|
|
* Removed frame-number display from NLA strips. Indeed doing so makes
things look cleaner/easier to identify.
* When transforming NLA strips, the "temp-metas" (purple strips) get
their frame extents drawn on either end, like in the sequencer, which
seems to be easier to read than the ones inside the strips.
---
The downside of this tweak is that there is no longer any visual
feedback for which strips run reversed instead of forwards, as that
used to be shown using the frame extents stuff.
|
|
Channels can now be used as "animation containers" to be filtered
further to obtain a set of subsidiary channels (i.e. F-Curves
associated with some summary channel).
The main use of this is that object and scene summary channels can now
be defined without defining the filtering logic in three different
places - once for channel filtering, once for drawing keyframes in
action editor, and once for editing these keyframes.
An indirect consequence of this, is that the "Only selected channels"
option in Timeline will now result in only the keyframes for a
selected bones getting shown (when enabled), instead of all keyframes
for the active object. This was requested by Lee during Durian, and is
something which has only become possible as a result of this commit.
|
|
* This (big) commit is aimed at cleaning up the filtering flags used
by the animation channel filtering code. The list of filtering flags
has been growing a bit "organically" since it's humble origins for use
in the Action Editor some 3 years (IIRC) ago now during a weekend
hackathon. Obviously, some things have ended up tacked on, while
others have been the product of other flag options. Nevertheless, it
was time for a bit of a spring clean!
* Most notably, one area where the system outgrown its original design
for the Action Editor was in terms of the "visibility" filtering flag
it was using. While in the Action Editor the concept of what channels
to include was strictly dictated by whether the channel hierarchy
showed it, in the Graph Editor this is not always the case. In other
words, there was a difference between the data the channels
represented being visible and the channels for that data being visible
in the hierarchy.
Long story short: this lead to bug report [#27076] (and many like it),
where if you selected an F-Curve, then collapsed the Group it was in,
then even after selecting another F-Curve in another Group, the
original F-Curve's properties would still be shown in the Properties
Region. The good news is that this commit fixes this issue right away!
* More good news will follow, as I start checking on the flag usage of
other tools, but I'm committing this first so that we have a stable
reference (of code similar to the old buggy stuff) on which we can
fall back to later to find bugs (should they pop up).
Anyways, back to the trenches!
|
|
- remove some warnings
- fix typos
- cmake allow in-source build (when WITH_IN_SOURCE_BUILD is defined)
- cmake, use an explicit list of rna files (don't glob)
|