| Age | Commit message (Collapse) | Author |
|---|
|
The idea is to allow certain animation channels to be always visible in
animation editors. So, for example, one can pin Camera animation to the
editor so it is always possible to refine/tweak camera animation when
animating something else in the scene.
There is probably some more polishing required, and some current
limitations could be solved in the future but should be a good starting
point already.
Currently only works for object without recursing into deeper datablock
(so for example, it's not possible to pin object material animation).
Studio request by Colin Levy.
|
|
Drivers can use this to refer to the data which the driver is applied to,
useful for objects, bones, to avoid having to create a variable pointing to its self.
|
|
The "W" channel will get a yellowish colour (i.e. a blend between the X/R and
Y/G axis colours), while the XYZ will behave as they do for other transforms.
|
|
FCurve evaluation depended on FCurve.curval, which isn't threadsafe.
Now only use this value for debug display,
and pass the value instead of storing in the FCurve for all but debug-display.
|
|
some autogenerated expressions"
This reverts commit 322f86d6b330ebeb1da5c1f527714745dc901460.
|
|
"blank") names
|
|
F-Curves easier
Now, when trying to insert a keyframe on a driven property (using IKEY, or with
autokeying enabled), the keyframes will get created on the Driver's F-Curve
(instead of creating a new FCurve that goes into the active action, but will never
do anything). Furthermore, the x-value of the new keyframe will be the current
result of the driver expression.
Why/Motivations:
This way, it becomes easier to create corrective drivers, as you can position all
the targets the driver depends on, then adjust the driver value until it does what
you need, and then you keyframe that value to bake it into the Driver F-Curve
(in effect, "training" the computer how to behave in that case).
Usage Notes:
* In practice, that particular workflow is still quite clunky to achieve, due to some
quirks of how the driver system and the UI widgets interact. Specifically, you'll
need to disable/mute the driver before trying to edit the setting (to prevent the
driver from immediately resetting the value - before even autokey fires!). However,
if you're using the Graph Editor to preview/monitor/manage the keying process, you'll
then want to re-enable the driver before changing the targets, so that you can see
how much of a change you'll want to be applying!
* The warning about editing driver values may need to be disabled or selectively
knocked out. I had it disabled while testing this functionality, but it's actually
harmless in its current state (if just a bit annoying).
|
|
When attempting to change a driver variable name to an "invalid" name,
an indicator will now be shown beside the offending variable name.
Clicking on this icon will show a popup which provides more information
about why the variable name cannot be used.
Reasons that it knows about are:
1) Starts with number
2) Has a dot
3) Has a space
4) Starts with or contains a special character
5) Starts with an underscore (Python does allow this, but it's bad practice,
and makes checking security of drivers harder)
6) Is a reserved Python keyword
|
|
autogenerated expressions
While most scripted expressions are quite short (e.g. "var" or "frame + 1"),
those that are autogenerated by scripts (to take into account a wide range of factors)
may require a bit more headroom to operate in.
By doubling the maximum length here, we now make it possible to combine up to 38
3-letter variables in some linear combination (with all factors expressed to 4 dp).
That should be more than enough for anyone or anything for quite a while!
Unfortunately, this does increase memory consumption for drivers across the board.
|
|
too short
When all the names in Blender were updated to go from having 32 characters to 64,
the "pchan_name" field in the DriverTarget struct was missed. This meant that if you
had a bone with a suitably long name, it would have been impossible to use values from this
bone in a driver.
The only reason this probably hasn't been discovered yet is because the standard/old depsgraph
doesn't work that well for bones in the same armatures, so setups where this may have
occurred are not that common.
To prevent this problem from happening in future, I've added the standard "MAX_ID_NAME-2"
comment to the comments on each line likely to be impacted by such changes, making it
easier for whoever does a search and replace in future :)
|
|
Feature is found as per channel option in graph editor.
|
|
There should be no functional changes visible from this change, but this commit
should make it easier to code tools which need to check on tweeakmode status,
by making it easier to figure out which NLA Track contains the strip which
owned the action being edited. (The strip is already saved, so this commit just
adds the track alongside it).
For now there is no version patch for this. The worst that happens is that an
extra refresh is needed in the NLA editor to get these to show up.
|
|
Normalization feature now uses the full range of the data instead of
just one semiaxis for the maximum size.
|
|
The logic used for determining whether certain keyframing settings (i.e. visual,
only needed, xyz -> rgb) got applied was wonky. The original intention here was
that the Keying Set settings would override the global settings, and the path
settings would override what was used for the Keying Set. However, that was not
happening in all cases previously, as it was only possible to add flags and not
to turn them off.
This commit fixes that by introducing separate toggles to control whether the
Keying Set/Path's settings override the settings inherited from its parent
(i.e. the Keying Set for the Path, and the User Prefs for the Keying Set).
The icons used for these toggles could get revised a bit (we need something
which communicates "override this"; the current one is the closest I could find)
WARNING: If you have old keying sets, this may cause some breakage!
|
|
tangent handles...
Added an extra option to `insert_bezt_fcurve()`, to allow full override of existing
keyframes when pasting (in this case, we do not want to inherit handles from existing
curve!).
|
|
|
|
FCurve Noise Modifer now has an extra float property which offsets the noise in time.
This is useful for creating follow through in procedurally animated noise.
For example, if you've used a noise modifier on a parent bone to add additional movement,
a quick and easy way to add overlapping motion is to create copies of that modifier on
its children, and then offset the time those curves play at. See this in action at:
http://youtu.be/Ph6fk_z_k3k
Reviewed By: Joshua Leung
|
|
Summary:
Crash was happening because of fcurve modifier stack
used modifier's DNA to store temporary data.
Now made it so storage for such a thing is being
allocated locally per object update so multiple objects
which shares the same animation wouldn't run into
threading conflict anymore.
This storage might be a part of EvaluationContext,
but that'd mean passing this context all over in
object_where_is which will clutter API for now without
actual benefit for this.
Optimization notes: storage is only being allocated
if there're Cycles modifier in the stack, so there're
no extra allocations happening in all other cases.
To make code a bit less cluttered with this storage
passing all over the place added extra callbacks to
the FModifier storage which runs evaluation with the
given storage.
Reviewers: brecht, campbellbarton, aligorith
CC: plasmasolutions
Differential Revision: https://developer.blender.org/D147
|
|
Added two options to a header of FCurve editor:
- Normalize which makes it so every individual
curve is fit into -1..1 space.
- Auto-normalize, which probably is to be called
"Lock" which "locks" curve normalization scale.
This is useful to prevent curves from jumping
around when tweaking it.
It's debatable whether it need to be a button to
normalize curves n purpose only, and it's fully
depends on animator's workflow.
Here during Project Pampa we've got Francesco
who get used to auto-renormalization and Hjalti
who prefers locked behavior.
Docs are to be ready soon by Francesco.
Thanks Brecht for the review!
|
|
|
|
in the UI
This is the second part of the fixes for [#32492], making it easier to identify
which part of a driver (i.e. which of its targets) is causing problems
A number of additional/related changes needed to be made:
* Red-alert status for layouts is now propagated down to child layouts when they
are created. This is needed as otherwise some of the templates used in the Graph
Editor driver settings won't actually get the red-alert status flushed down to
them. Also, note that this status needs to be set before any widgets are added
to the layout, or else the settings aren't applied when the relevant widgets get
created.
* "Single Property" RNA-Paths resulting in out of bounds array access will now
trigger an error status and appropriate warnings
TODO:
* The error tagging doesn't get applied immediately after variables are created,
or their types changed
* There was also some other weirdness involved when a higher-value flag (1<<10)
was used for this setting, which needs further attention
|
|
|
|
|
|
|
|
See http://wiki.blender.org/index.php/Dev:Doc/CodeStyle#Macros.2C_Enums.2C_Inline_functions
|
|
|
|
*Add a new idname to keyingsets, keeping name as label-only (using same string for both made lookup fail when using i18n other than english, as it tried to compare an untranslated static string id against a translated RNA name). Also adding a description string (can be helpful with custom keyingsets, imho).
*Fixed a few other bugs related to that area (namely, you can’t deselect current keyingset from the shift-ctrl-alt-I popup menu, and insert/delete key ops were using a rather strange way to get chosen custom keyingset…).
*Fixed UI code so that it always uses (RNA) enum, and simplified menu-creation code.
|
|
|
|
|
|
without the underscores these clogged up the namespace for autocompleation which was annoying.
|
|
|
|
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$
|
|
Speaker objects fully functional!
Minor changes:
* Fixed three memory bugs found via valgrind.
* Fixed bug with jack transport crashing after file loading.
* Sound NLA Strips now start at CFRA instead of 0.
|
|
These are basically just for specifying when a speaker should fire off
it's soundclip, and as such, many NLA operations are irrelevant for
it. They can only be specified on object-level for speaker objects.
I've still got some UI tweaks I'll need to work on in order for these
to be able to be added even when the speaker doesn't have any NLA
tracks yet. (EDIT: while typing this, I had an idea for how to do
this, but that'll be for next commit). In the mean time, you'll need
to add a single keyframe for the object, snowflake that action and
delete the NLA strip before you can start editing.
|
|
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.
|
|
By popular demand, the "Transformation Channel" driver variable type
now has a "local space" transform space option which uses the same
magic that constraints use for defining local-space. This is what many
bug reporters and feature requesters have moaned about for a while
now, so after reviewing several of the bug reports which lead to the
current situation, here is what has been much-wanted for so long!
In order to implement this, I've:
- renamed the old "Local Space" option here to "Transformation Space",
in order to prevent old rigs breaking. This has also been kept, as it
is useful for #21384 (though perhaps with this new option it isn't
needed anymore)
- reviewed my fix for #20870 (IIRC, a Durian-era bug), which related
to the non-uniqueness of matrix->euler decomposition
|
|
Following on from my commit to introduce frame ranges for FModifiers,
those frame ranges can now have blend in/out values. By setting a
blendin or blendout value, you're specifying the number of frames for
the modifier's "full influence" to take effect or fade out relative to
the start/end frames.
The "full influence" above needs a little clarification.
When the "use influence" setting is enabled, "full influence" is taken
from the "influence" slider (a new setting). Otherwise, it uses 1.0
(i.e. unmodified influence, same as old behaviour before the
introduction of influence controls). The influence slider basically
says how much the modifier's effects are allowed to contribute to the
final result.
---
Notes:
- This opt-in "Use Influence" approach is really forced upon us
because there are heaps of old files for which we cannot easily
version patch without spending some effort going through all the data
in the file, hunting out the F-Modifiers.
- interpf() seems to use a backwards order compared to everything else
|
|
Using this feature, it is now possible to for example have different
noise-profiles for different parts of a curve, which makes it possible
to do animate camera shake for example.
Or perhaps, for having greater control of mixing and matching
different parts of F-Modifier effects, such as combining several
generator modifiers to get multi-case functions for instance.
See http://aligorith.blogspot.com/2011/06/gsoc11-fmodifier-range-
masks.html for details.
|
|
|
|
documentation done.
|
|
- Adding drivers from the UI (not from py-scripts though) will now
automatically add a "Transform Channel" driver variable to the newly
created drivers. This makes setting up drivers a bit more convenient
for the most commonly used case.
- Drivers now report their errors using the Reports system instead of
writing these directly to the console.
- Clarified some comments to be more insightful about the "why's" of
some design decisions, and related formatting/cleanup tweaks
- Reduced scope of "path" vars to just the scope they're required in
- Removed some unused defines from a failed experiment in the original
Keying Sets code ("templates" and "template flags") which was
superseeded by the more flexible + nicer "Builtin KeyingSets"
|
|
|
|
This commit restores the ability to reorder channels in the animation editors (DopeSheet/Action/etc., Graph/Drivers, NLA). The hotkeys for this are:
- Shift-PageUp = Move Up
- Shift-PageDown = Move Down
- Ctrl-Shift-PageUp = Move to Top of List
- Ctrl-Shift-PageDown = Move to Bottom of List
Do note that only animation data can get reordered using this.
So, do not expect to be able to change the object order (that is actually taken from the order that Blender actually evaluates them per update/frame).
---
In the process, I've fixed a couple of other bugs:
* Removed 'optimisation step' check in anim_filter.c for dopesheet with no filtering options modified, since this meant that the ANIMFILTER_ANIMDATA data filter was not getting processed (and potentially there were other maintenance problems with that).
* Made NLA Editor's channel list not totally duplicate the basic Animation Channels keymap. Instead, the "NLA Channels" keymap now only defines the parts that are different, and this then gets specified before the standard one so that these different parts will override the standard ones.
* Attempted to fix BorderSelect on NLA Channels list. Still not totally working correctly yet though.
* Moved "Euler Discontinuity" menu entry from "Channels" to "Keys". It really belongs in the latter, since it affects the keyframe values, rather than some aspect of the channel (i.e. ordering of channels or how they're displayed)
|
|
27562, 27570, 27571, 27574, 27576, 27577, 27579, 27590, 27591, 27594, 27595, 27596, 27599, 27605, 27611, 27612, 27613, 27614, 27623
|
|
This commit started out aiming to make the "Stepped" F-Modifier (committed last night) even more useful, but ended up fixing a few other finer-points of how F-Modifiers work.
Firstly, the new stuff:
I've addded options to the Stepped F-Modifier to not affect frames before and/or after specified values, and renamed the 'start offset' to 'offset' for clarity.
The main objective of this is to allow Stepped F-Modifiers to only affect certain time ranges, so that by layering/using multiple instances of the F-Modifier, it can be possible to have multiple stepping-sizes.
This allows for effects like:
http://www.pasteall.org/blend/2230
or in words, it provides a convenient mechanism for animators to specify whether sections of the animation is shown "on twos", "fours", or even "forty-second-ths plus a smidgen", as can be easily done with 2D.
Assorted changes to support this:
* Properly fixed up how F-Modifiers that work with time, evaluate the time to evaluate the curve at. Now layered time effects like this should be possible in a much nicer way.
* Added proper value range validation/clamping to many properties. There are still a lot more that need checking, but at least more properties now do "the right thing".
|
|
* Copy/Paste operators for F-Modifiers
Available in Graph and NLA Editors. Use the Copy/Paste buttons beside the 'Add Modifier' buttons.
Copy copies all the modifiers of the ACTIVE F-Curve or Strip depending on the editor.
Paste pastes modifiers from the buffer to all the selected F-Curves or Strips, adding the new modifiers to the ends of each list.
* 'Stepped Interpolation' F-Modifier
This modifier holds each interpolated value from the F-Curve for several frames without changing the timing.
This allows to preview motions 'on-twos' for example without altering the timing, or having to go through setting heaps of keyframes. In this case, Andy wanted to use this for CG <-> StopMo.
|
|
After a few days of wrong turns and learning the finer points of RNA-type-subclassing the hard way, this commit finally presents a refactored version of the Keying Sets system (now version 2) based on some requirements from Cessen.
For a more thorough discussion of this commit, see
http://sites.google.com/site/aligorith/keyingsets_2.pdf?attredirects=0&d=1
------
The main highlight of this refactor is that relative Keying Sets have now been recoded so that Python callbacks are run to generate the Keying Set's list of paths everytime the Keying Set is used (to insert or delete keyframes), allowing complex heuristics to be used to determine whether a property gets keyframed based on the current context. These checks may include checking on selection status of related entities, or transform locks.
Built-In KeyingSets have also been recoded, and moved from C and out into Python. These are now coded as Relative Keying Sets, and can to some extent serve as basis for adding new relative Keying Sets. However, these have mostly been coded in a slightly 'modular' way which may be confusing for those not so familiar with Python in general. A usable template will be added soon for more general usage.
Keyframing settings (i.e. 'visual', 'needed') can now be specified on a per-path basis now, which is especially useful for Absolute Keying Sets, where control over this is often beneficial.
Most of the places where Auto-Keyframing is performed have been tidied up for consistency. I'm sure quite a few issues still exist there, but these I'll clean up over the next few days.
|
|
Added a new option to filter the out Object-level (i.e. transforms, object visibility/settings, and also bone animation) animation data from the channels list. As most of these settings are transforms, I've used the transform manipulator icon and named the RNA setting display_transforms.
This is useful when trying to filter out only material animation data for example, as requested by Colin.
|
|
|
|
F-Curves now internally store radians again instead of degrees.
- This solves problems with inconsistencies when working with drivers.
- No need to version patch old files, potentially screwing them up. As such, removed the version patching for F-Curves.
- Is better suited to optionally showing radians throughout the UI instead or degrees.
As a result, values are now converted on the fly in the Graph Editor for display and operators that operate on values. I've made the conversion system for this rather general, so that other unit type conversions can also be hooked up with the type conversion backend.
Also, made some tweaks to F-Curve RNA wrapping to make it represent the data better.
TODO:
- Transform code currently still needs to be corrected to work with these changes. Currently moving keyframes for rotation curves will make them change too rapidly vertically when using degrees.
|
