| Age | Commit message (Collapse) | Author |
|---|
|
Interpolation between keyframes for enum values (and booleans) can only be constant now.
TODO:
A way to do this for modifiers is still needed.
|
|
Using this cycling mode option, the keyframe range will be repeated in reverse order every second repeat. Thanks for the idea mfoxdogg :)
|
|
Time-Modifying F-Curve Modifiers now get special callbacks to allow them to specify what frame they need to be evaluated on, instead of forcing a re-evaluation of the preceeding curve + modifier-stack. This should be more robust than the old way in general.
It still remains to be seen if some tweaks to this are still needed, as the full consequences of the propogation of modified time-spaces have yet to be fully explored.
For now though, evaluation works by finding the last modifier on the stack which modifies time, and asks it what time it modifies the given time to. This modified time is used to evaluate the F-Curve data only. The modifier stack gets evaluated using the original time instead.
|
|
It is now possible to mute individual modifiers so that they will not contribute to the final result.
|
|
Thanks Aligorith for making such an easy to use system!
http://mke3.net/blender/devel/2.5/fcurve_noise_modifier.mov
|
|
* Also look in ./release for scripts instead of next to executable.
* Some warning fixes.
|
|
Drivers now support multiple targets which act as 'variables'. The targets have a short 'name' (see later), and reference some property (in much the same way as F-Curves do, using RNA-Paths) which acts as the 'value'.
These named variables can then be used in a Python Expression which relates them to each other for more fine-grained control over the result of the driver. By using only the names of these variables in the expressions, we are able to define expressions/relationships in a much more readable way, as data access is separated from data use. This makes the underlying relationships easier to understand.
By default, if no Python Expression is given, the variables are simply averaged together, so old files won't break. :)
For example, check the following diagram (thanks Cessen/Nathan V from Peach team):
http://download.blender.org/ftp/incoming/250_drivers_mockup_cessen.png
TODO List:
* Depsgraph building for new driver relationships doesn't work yet. This needs to be recoded again, but this new system makes this much easier, since the targets are clearly defined (i.e. no need to parse py expressions to get list of objects)
* Graph Editor interface for editing these needs to be rewritten
* Python function for evaluating these expressions is needed (Campbell?)
|
|
* Replaced a quicky hack needed to get PoseLib working with a proper new group-naming option for KeyingSets. Now, all builtin KeyingSets will use the name of the data (i.e. Object or PoseChannel) as the name of the group new channels are added to
* Fixed a bug with LocRotScale builtin KeyingSet, which meant that scale keyframes were not getting added.
* TAB key (toggle original pose) now works again. Previously, events were flying past too quickly.
|
|
This (most important part) of PoseLib now mostly works again. It even works for PoseLibs saved with the old animation system.
However, there are a few annoying bugs that need to be addressed still:
* When 'confirming' poses, the pose changes to the next one before PoseLib exits. I'm not quite sure where this is coming from yet...
* There are still a few minor bugs in the search-string code that will get ironed out
* AutoKeyframing doesn't work yet for this
|
|
This new modifier clamps the values of the F-Curve to lie within specified bounds, much like Limit Location/Rotation/Scale constraints do. You can limit by time range(s) and/or value range(s).
|
|
This setting means that instead of blindly replacing the existing values, the generator modifier will instead apply its effects on top of any existing modifiers (and/or curve data).
Thus, it is now possible to apply effects such sin/cos-based oscillations on top of keyframed motion.
|
|
* Rewrote the Generator modifier to be more efficient and support more options
* A few UI tweaks for this, but the UI for this is still not yet functional though.
|
|
Now F-Curve channels in channels region are drawn with the same colour as their respective curve is drawn in the curves area. I've had to make a compromise to store such colour info in F-Curves themselves, which is not terribly ideal if the F-Curve gets reused in some way. However, for now, this will do (special tweaks can be made to make this work better though).
I've also added a colour-determination mode per curve which should in future allow more control over this. By default, all curves still use the old 'rainbow' style. The available types area:
* Old Rainbow - Colour is determined 'automatically' using a magic method which uses curve position + total curves to generate a colour.
* Auto RGB - Color is determined using the 'array index' stored in F-Curve for data-access. An unresolved issue with this is that all the curves with this will end up with exactly the same colour, leading to confusion (i.e. all location.x and scale.x properties could potentially all be the same red colour).
* Custom colour - self explanatory
Currently, there's a minor bug when loading old files where the colours don't get initialised yet. For now, just clicking in the Graph Editor after file-load will solve any of these problems.
Ton: it looks like area->refresh() isn't getting called after file read.
|
|
* The settings of KeyingSets can now be viewed/modified through RNA.
* Shuffled RNA wrapping for AnimData over to its own file
* Moved insert-key flags to DNA_anim_types.h, as they're now used for KeyingSets.
|
|
When fully implemented, these will be the clearest demonstration of 'Everything is Animateable', as they will allow users to define an arbitary group of settings through selecting items in the Datablocks (RNA-Viewer) View of the Outliner to define custom 'sets'. Such Keying Sets are known as the 'absolute' ones, which are created for a custom purpose.
Of course, 'builtin' Keying Sets will still be provided. Such built-in ones will not work on any particular paths, but will use context info to maintain the legacy method of inserting keyframes (via IKEY menu).
Currently, KeyingSets cannot be created/edited through the UI, though the backend code is in place to do this.
|
|
It's about time that the RNA wrapping for various parts of the animation system were cleaned up for my recent changes. I've moved some code around (and/or deleted a file or two) in the process.
|
|
* Drivers view in Graph Editor now displays drivers only, instead of displaying normal Animation data.
* 'Materials' channel is now only shown under an Object when there are Materials with animation data...
* Hid more debug prints behind debug flag. These should be removed...
|
|
* Streamlined the filtering code to remove a few redundant options, which required tweaking the code for most tools
* F-Curves are simply displayed using their full paths right now. This should eventually be the UI-string stored in RNA, but right now there are still a few missing things.
* There are a few tools which are not available yet which were available in 2.5 before Animato was added:
- Copy/Paste
- Rearrange channels
Also, the DopeSheet is not totally functional (in terms of displaying animation data for sub-object data yet). That will be added tomorrow.
* Added 'Action Group' pointer to F-Curves, as it will be handy for allowing Bone channels to still remain grouped as they were before with the Action Channels. However, reintroducing such a structure to the data-storage is not anticipated...
|
|
* Removed nAction struct. We'll be using good ol' bAction structs again, but putting new data in a different list. Apart from that, the data is similar enough to do so.
* Rearranged code in DNA_action_types.h while renaming the structs to avoid confusion over what is currently in use...
* Added freeing and AnimData execution loops for many other ID-types too. (NOTE: I've added AnimData in NodeTree struct too, but it's not clear to me where the relevant data-management calls should go in Nodes code).
* File writing code should now only write the new data to files
|
|
* Made AnimData blocks be stored as pointer instead of directly in the ID-datablock, so that fewer files will need to be recompiled everytime some animation settings change.
* Tried to fix some of the compiler errors that pop up in Yafray code. If this commit doesn't fix it, just disable Yafray code for now (WITH_BF_YAFRAY=0 for scons)...
|
|
Finally, here is the basic (functional) prototype of the new animation system which will allow for the infamous "everything is animatable", and which also addresses several of the more serious shortcomings of the old system. Unfortunately, this will break old animation files (especially right now, as I haven't written the version patching code yet), however, this is for the future.
Highlights of the new system:
* Scrapped IPO-Curves/IPO/(Action+Constraint-Channels)/Action system, and replaced it with F-Curve/Action.
- F-Curves (animators from other packages will feel at home with this name) replace IPO-Curves.
- The 'new' Actions, act as the containers for F-Curves, so that they can be reused. They are therefore more akin to the old 'IPO' blocks, except they do not have the blocktype restriction, so you can store materials/texture/geometry F-Curves in the same Action as Object transforms, etc.
* F-Curves use RNA-paths for Data Access, hence allowing "every" (where sensible/editable that is) user-accessible setting from RNA to be animated.
* Drivers are no longer mixed with Animation Data, so rigs will not be that easily broken and several dependency problems can be eliminated. (NOTE: drivers haven't been hooked up yet, but the code is in place)
* F-Curve modifier system allows useful 'large-scale' manipulation of F-Curve values, including (I've only included implemented ones here): envelope deform (similar to lattices to allow broad-scale reshaping of curves), curve generator (polynomial or py-expression), cycles (replacing the old cyclic extrapolation modes, giving more control over this). (NOTE: currently this cannot be tested, as there's not access to them, but the code is all in place)
* NLA system with 'tracks' (i.e. layers), and multiple strips per track. (NOTE: NLA system is not yet functional, as it's only partially coded still)
There are more nice things that I will be preparing some nice docs for soon, but for now, check for more details:
http://lists.blender.org/pipermail/bf-taskforce25/2009-January/000260.html
So, what currently works:
* I've implemented two basic operators for the 3D-view only to Insert and Delete Keyframes. These are tempolary ones only that will be replaced in due course with 'proper' code.
* Object Loc/Rot/Scale can be keyframed. Also, the colour of the 'active' material (Note: this should really be for nth material instead, but that doesn't work yet in RNA) can also be keyframed into the same datablock.
* Standard animation refresh (i.e. animation resulting from NLA and Action evaluation) is now done completely separate from drivers before anything else is done after a frame change. Drivers are handled after this in a separate pass, as dictated by depsgraph flags, etc.
Notes:
* Drivers haven't been hooked up yet
* Only objects and data directly linked to objects can be animated.
* Depsgraph will need further tweaks. Currently, I've only made sure that it will update some things in the most basic cases (i.e. frame change).
* Animation Editors are currently broken (in terms of editing stuff). This will be my next target (priority to get Dopesheet working first, then F-Curve editor - i.e. old IPO Editor)
* I've had to put in large chunks of XXX sandboxing for old animation system code all around the place. This will be cleaned up in due course, as some places need special review.
In particular, the particles and sequencer code have far too many manual calls to calculate + flush animation info, which is really bad (this is a 'please explain yourselves' call to Physics coders!).
|
