| Age | Commit message (Collapse) | Author |
|---|
|
* Renamed the 'blend' blending mode to 'replace', since that's what it usually does
* Drawing a darkened rect behind the keyframes shown in the action line
--
* Fixed typo made last night which broke compiling
* Consolidated all the keyframe-shape drawing code to use a single codebase. Even if we don't ultimately go with OpenGL keyframes, there's always a tidy option for that now.
|
|
* Some cleanups aimed at giving some (neglible) speedups
* Preparation for NLA-Strip keyframes to be editable
|
|
F-Modifiers now work on 'all' types of NLA Strip. To get them working on Meta-strips, F-Modifiers on the Meta strip must be applied on top of those for child strips. For now, this is done by joining the lists of modifiers, and evaluating the joined list.
Currently, Transitions don't work that great with F-Modifiers yet (only the endpoints get evaluated with the F-Modifiers). Solving this is for another time...
|
|
Previously, the quick-hack I coded for Meta-strips evaluation didn't really take into account the possibilities to use Meta-Strips as strips in their own right - i.e. reversed, muted, time-mapping-curves, influence-blending - were all unavailable.
This commit makes the aforementioned capabilities of other strips available for Meta-Strips too. The evaluation is now kind-of recursive (as with most of the other methods which take them into account) so that each 'level' of strips get evaluated correctly within their frame-of-reference.
TODO:
* F-Modifier support for Metas...
|
|
Refactored the backend code/API's to support 'meta' strips (i.e. strips containing other strips). These have been implemented to be nested to 'unlimited' depths (in terms of common usages that is, though there is a very remote chance of stack-overflow in theoretrical evil cases only that shouldn't ever be encountered in production).
This paves the way for implementing the necessary tweaks needed for the transform code (in addition to some cool user-level tricks)
|
|
Groups (the Action variety) can now be muted, and also be set to not be drawn in the Graph Editor. These settings get applied to all the F-Curves within the group, overriding any settings individual F-Curves might have, allowing users to quickly mute or hide groups of curves without having to go through clicking on all of them.
Also, added a flag that can be used to set the curve visiblity on AnimData level too. This will be enabled in a future commit.
|
|
While trying to fix the mapping conversions for repeat, I came across some limitations with the current (soon to be previous) mapping methods.
Now the mapping conversions should work nicely for all places that use them.
|
|
21073 to 21145
|
|
Added AnimData to ParticleSettings so that this will work. This seems to be ok in the brief tests I did, but be warned that this may not be optimal for the Particles System...
|
|
In TweakMode, the keyframes of the Active Action are now shown (and can be edited) in NLA-mapped time, with appropriate corrections applied when editing. This works in the DopeSheet and Graph Editors :)
To do this, got rid of the old wrappers/API-methods, replacing them with new-style ones. A few methods previously (in this branch) used only for evaluation are now used for this purpose too. As the same code is used for editing + evaluation, this should now be much better to work with.
I've only done a few brief tests now, but I think I might've muddled the invert-flags on one or two cases which I'll need to check out tomorrow. So, beware that there may be some weird and critical bugs for the next few days here...
Also, added proper license headers to new NLA files.
TODO:
- testing + bugfixing due to this commit
- show range of keyframes in NLA Editor active-action line
|
|
These fixes get the 'pathJumper.blend' file from our testing suite workable in 2.5 (with a few minor tweaks still needed *)
Changes required:
- Added a 'ctime' var to curve structs for storing the value that used to be obtained by specially evaluating the 'speed' curve when evaluating objects parented to the curve. This can now be animated as a 'proper' var as per normal.
- Added a special hack for detecting constraint blocks, as the old method resulted in paths for Objects instead...
(*) Issues:
- Unfortunately, the paths still don't work out of the box. For some reason, the constraint names in the paths are spelt incorrectly - "Ar" and "Br" instead of "Ap" and "Bp". I'm not sure where this problem is coming from, but changing the paths manually in the Datablocks viewer fixes this error...
- I noticed that in the buttons view, only 1st of the constraints gets shown. This seems a bit like some of the intermittent problems I've had with some arrays/lists not expanding properly in Datablocks view.
|
|
== Transitions ==
Transition strips are now able to be created + evaluated. Transitions allow for interpolation between the endpoints of two adjacent strips in the same track (i.e. two strips which occur in the same track one after the other, but with a gap between them).
- The current behaviour when only one endpoint affects some setting is non-optimal, since it appears somewhat inconsistently extend/replace values...
- Transform code needs a few fixes still to deal with these
== Strip Adding Operators ==
* New strips referencing Actions can be added using the Shift-A hotkey while in the strips-area. You must have a track selected first though.
The new strip will get added, starting from the current frame, in the selected track(s) only if there is enough space to do so. Otherwise, the new strip gets added at the top of the stack in a new track.
* New transition strips can be added with the Shift-T hotkey while in the strips area. You must have two adjacent strips selected for this to work.
== New Backend Methods ==
* Recoded the strip/track adding API to be more flexible
* Added a new method for testing whether F-Curve has any modifiers of with certain attributes. Will be used in a later bugfix...
== Bugfixes ==
- Fixed bug with strip-blending which caused the blending modes to be useless.
- NLA buttons now use proper poll callbacks instead of defining checks
- Commented out missing operator in menus, silencing warnings in console
- Removed obsolete/incorrect comments
|
|
* Strip scaling was being evaluated in the wrong way, resulting in scaled strips not being played too fast (for lengthened strips) or too slow (shortened strips)
* Also, verified that the 'reversed' option works correctly (no changes needed to be made here)
|
|
- Evaluation times for strips are now strictly clamped to the endpoints of the strips - i.e. if a strip has 'extend' on, the strip's evaluation time won't continue to change as time changes
- New NLA Editor instances now have auto-snapping turned on by default (as they should)
|
|
Most of the relevant properties have been wrapped.
- There are still some properties I'm not sure about whether they should be exposed at all (which have been left out for now). Most of these are really internal flags which are used in a few select places.
- To maintain the integrity of the settings, I've included some custom code for a few of the setters (i.e. scale/end-frame) where changing one should result in a change in the other and vica-versa.
Also, tweaked the wrapping for a few other types.
Another side effect of this commit is that I can now uncommented some code for using F-Curves to control the influence and time of the strips. These F-Curves would need to be specifically attached to the NLA-Strip they affect for now (TODO: I need to review this again...), and as such, cannot be used yet since there's no (end-user-accessible) way to do this :)
|
|
|
|
* Fixed an evil bug where the last frame of a strip was always incorrectly evaluated.
This was because these frames were not being included in the strip's 'range' as defined by the IN_RANGE() testing macro, which only considers the given range as an open interval (i.e. non-inclusive of boundary points). I've added a new macro, IN_RANGE_INCL(), which is inclusive of boundary points, since this is a common test in many other parts of the code.
* When an AnimData block is in 'tweaking' mode, the tracks following (and including the active track) are now correctly skipped during evaluation.
* Finished coding the option of setting a single NLA-track per NLA-block to play 'solo' (i.e. only that track is enabled for evaluation).
To enable this, simply click on one of the grey 'dots' beside the NLA-track names, turning this dot yellow. The 'yellow' dot means that the track will play by itself (even the 'active action' gets silenced). Only one track per AnimData block can play solo at a time. To disable, simply click on the 'yellow' dot again.
NOTE: this currently uses the View3D layer-status icons. We probably need some special ones for these later (coloured vs grey star?)
* Also (not related to evaluation) made the selection operators for the NLA Editor only work when not in tweaking mode, since in tweaking mode they can potentially result in data being resolved inappropriately when leaving tweaking mode.
|
|
In this commit, I've introduced the mechanism by which actions already referenced by strips used in the NLA can be edited (or 'tweaked'). To use, simply select a strip you wish to edit, and hit that TAB key to start tweaking that strip's action, and hit TAB again once you're done.
What happens when you enter 'tweak mode':
1) The action of the active strip temporarily becomes the 'active action' of the AnimData block. You are now able to edit this in one of the Animation Editors (DopeSheet/Action, Graph Editors) as per normal (i.e. sliding keyframes around, inserting keyframes, etc.). The 'action-line' will therefore get drawn immediately above the active track containing the active strip, so that it's clear that that's what we're editing.
2) All the NLA-tracks (and all the strips within them) that occur after the track that the active strip lived in get disabled while you're in tweakmode. This is equivalent to travelling back to an earlier state in a construction history stack.
3) The active NLA track also gets disabled while in tweakmode, since it would otherwise interfere with the correct functioning of the tweaking for the action of interest.
4) The 'real' active action (i.e. the one displaced by the active strip's action) gets put into temp storage, and will be restored after you exit tweakmode.
5) Any strips which also reference the action being tweaked will get highlighted in red shading to indicate that you may be making some changes to the action which you don't really want to make for the other users too.
Please note though, that this is only a rough prototype of this functionality, with some niceties still to come. i.e.:
* NLA-tracks after the active track should still get drawn above the 'tweaking action line', but perhaps with different appearance?
* Various tools will still need awareness of this to prevent corrupting operations from taking place. How to proceed is still undecided...
* When exiting tweak-mode, the strip the action came from still needs some form of syncing with the modified action... there are a few tricky issues here that will need to be solved
* Evaluation code doesn't totally take this into account yet...
---
Also, fixed a number of bugs with various code (notably selection, and also a few drawing bugs)
|
|
* Fixed some bugs which meant that NLA-strips weren't getting drawn
* Removed some debugging code
* Fixed bug with Action-line disappearing after 'pushing down' actions
* Fixed bug where Objects with no animation data showed up in NLA
* Tried fixing a bug where NLA-strips were evaluated erratically. I have a feeling that there are some rounding errors I'll need to pay more attention to somewhere :/
|
|
* Data copying
* Strip sorting
|
|
In this commit:
* Added code for freeing NLA data now stored in AnimData
* Started writing some utilities for adding NLA data, especially the 'push-down' concept for Actions
* Cleanups of existing code - removal of obsolete NLA code from various places
Next commits/parts:
* File IO code for new-style NLA data
* Version patching for old data to new data
|
|
In theory, actions can now be evaluated in NLA, though in practice, we don't have an NLA Editor to create data to use this yet! Next up, transitions...
Some notes:
* Recoded the way the 'accumulation' methods work (i.e. blend, add, etc.), adding a few new ones. It should now be more obvious how these work.
* Some assorted code cleanups done too (removing unneeded vars/args)
|
|
* Refactored F-Curve Modifier stack evaluation into functions which can be reused for F-Curve Modifiers on NLA-Strips
* Started setting up temporary accumulation buffer system for use when evaluating strips
|
|
* Recoded the flags for NLA-Strips to take into account the new design directions
* Modified parts of the evaluation pipeline to reflect this
|
|
Now it is possible to write a Python Expression using the variable names for driver targets (see mockup from initial commit) to substitute the appropriate values into the expression.
In the __global__ namespace for PyDriver evaluation, the following modules are available:
* __builtins__ - i.e. the builtin Python functions
* bpy - new Python API
* math or m - math module
For example:
Consider a driver with three targets, named: A, B, C
Now, you could write an expression like:
C if A < 5 else B
or even:
2*C if A < 5 or A > 20 else m.PI*B
Of course, you don't have to have three targets, the above was just an example.
TODO:
* Bring back way to load pydrivers.py
* Blender.Noise equivalent would be nice to have
P.S. I hope I haven't made any terrible Python API coding errors here (i.e. mem leaks, etc.)
|
|
The Python API to define Panels and Operators is based on subclassing,
this makes that system more generic, and based on RNA. Hopefully that
will make it easy to make various parts of Blender more extensible.
* The system simply uses RNA properties and functions and marks them
with REGISTER to make them part of the type registration process.
Additionally, the struct must provide a register/unregister callback
to create/free the PanelType or similar.
* From the python side there were some small changes, mainly that
registration now goes trough bpy.types.register instead of
bpy.ui.addPanel.
* Only Panels have been wrapped this way now. Check rna_ui.c to see
how this code works. There's still some rough edges and possibilities
to make it cleaner, though it works without any manual python code.
* Started some docs here:
http://wiki.blender.org/index.php/BlenderDev/Blender2.5/RNATypeRegistration
* Also changed some RNA_property and RNA_struct functions to not
require a PointerRNA anymore, where they were not required (which
is actually the cause of most changed files).
|
|
* Added extra parameter to generic unique name finding function BLI_uniquename() for specifying the delimeter between non-unique parts of the name and digits.
* Driver target variables now get unique names by default.
|
|
* Cleaned up Keyframing API to get eliminate some of the problems faced during the original implementation of PoseLib, thus reducing code redundancy.
* Added new Animato evaluation functions specifically for use by PoseLib.
* Replaced parts of PoseLib code which relied on old animation system to the equivalent code for Animato. Notice the much cleaner + saner + compact code!
Next step is to operatorfy the PoseLib tools (while maintaining possibility for an API to some things) :)
|
|
* Copying objects with animation data now works correctly. Previously, actions were not getting copied correctly, leading to loss of data in some cases.
* Action and Graph editors now display the name of the Action concerned (for 'Action' folder channels), making it easier to tell which AnimData blocks are sharing the same actions
* Added some code to make relative KeyingSets (converted from absolute ones) work better.
|
|
* Invalid drivers are now tagged accordingly and are not evaluated until they are manually refreshed using the 'Update Dependencies' button
* Drivers with errors have a error warning shown in their UI
* Rearranged the UI buttons a bit for drivers, adding support for a 'remove' driver button.
|
|
When inserting keyframes in the 3D-View (support will be extended to other editors in due course) using the IKEY hotkey, the menu which appears will now consist of 3 parts:
* 'Active Keying Set' - this option allows you to use the user-defined KeyingSet which is active for the current scene (i.e. the one seen in the TimeLine/Outliner headers)
* User defined Keying Sets - a list of all such available KeyingSets is included, and entries can be chosen from there
* Built-In Keying Sets - see later...
To achieve this, several changes needed to be made first:
* Added support for 'relative' in addition to 'absolute' Keying Sets. Relative Keying Sets are Keying Sets which operate on data from the current context (i.e. a 'location' KeyingSet will add location keyframes for selected objects/bones/nodes as opposed to location keyframes for some particular object). The is a tentative 'templates' requirement system here, which still needs to be fully fleshed out.
* Added support for builtin Keying Sets (i.e. 'Location', 'Rotation', 'Scaling', and 'LocRot' as a few initial demonstrations), which replaces the temporary Insert Keyframe operator for the 3D-View (IKEY). These are effectively relative Keying Set definitions which are included in Blender by default and stored in a list separate from user-defined ones. Volunteer help in defining a few more of these for other editors will be welcome soon.
* Removed/replaced much of the crappy temporary Keyframing operator code, though a few tweaks could still be done.
|
|
Outliner
* Cleaned up the helper functions for the Outliner operators which deal with Keying Sets
* Fixed a few minor bugs in the Keying Sets API that won't show up with the current tools, but may crop up later
* Added a new method to find a 'matching' path in a Keying Set. Now adding a new path to a Keying Set will firstly check if there is any similar path already, and skip adding another path.
|
|
* 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.
|
|
|
|
To use KeyingSets, simply Outliner-select items in the Datablocks view and press K to add to the active KeyingSet. Then keyframes can be inserted by choosing the 'Active Keying Set' option when inserting keyframes.
Important notes on the current implementation:
* Only properties directly inside some ID-block that is close to the root (i.e. main -> objects -> "someobj" -> location, or main -> materials -> "somemat" -> colour) can be accessed for now, as I haven't got the code for building the inner-parts of the paths working yet. Help on getting this working is welcome (hint to Brecht).
* Properties that can be safely included include simple properties "object -> Dupli Verts", entire arrays "object -> Location" or individual array elements "object -> Location -> y"
---
Also added typo fix for KeyingSet freeing. It was freeing the KeyingSet instead of it's paths.
|
|
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.
|
|
- Added depsgraph tag for object-change in AnimData, so the
new animsys doesn't have to all objects anymore.
(Still WIP, depsgraph has to do this much better)
- Bugfix in notifiers; only 1 notifier was handled for
frame updates
Result: 2 windows, displaying 2 scenes, now can be edited
independently, and play independent. Not when they share
data, of course. :)
|
|
* RNA_blender.h is now generated along with the other files. It is not
used anywhere yet, and still located quite hidden next to the other
rna_*_gen.c files. Read only access for now.
* Inherited properties are not copied from the base anymore but
iterated over. Patch by Vekoon, thanks!
* Array get/set callbacks now do the whole array instead of getting an
index. This is needed for some layers for example so python can set
the array as a whole, otherwise the check that one layer has to be
enabled at all times gets in the way. Also nicer for the C API.
* Also some changes to returning pointers to make the API cleaner, got
rid of the type() callback and instead let get() return PointerRNA
with the type included.
The C API looks like this currently:
http://users.pandora.be/blendix/RNA_blender.h
|
|
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.
|
|
many slowdowns on complex rigs with Action Constraints. Many of these prints should eventually be removed, though some of them will still be useful.
|
|
Currently this still works really badly, but I'm not sure of the exact cause yet.
|
|
* ShapeKey conversions should now go to the correct places
* Added fix for drivers to prevent crashes when no driver object is provided (Franky from BBB seems to have one such driver for some reason).
* Temporarily disabled a check when evaluating drivers for whether the driver is tagged for evaluation. Drivers still need to be correctly tagged AND ordered by the Depsgraph to work correctly.
|
|
* Mouse-Select and DeSelect All work again
* Added access to constraint 'influence' value
|
|
This is work-in-progress patching support for converting animation saved in old system to work in the new one.
* Only IPOs/Actions directly attached to Objects + Shapekeys are converted for now. More types will follow...
* This is currently done as a step outside of do_versions() due to problems with various pointers not having been resolved yet, but which are necessary for correct resolution of issues such as drivers... However, the current code does illustrate how the data should be converted to give best results/compat between the two systems.
* Still need to get the converted data working with depsgraph correctly. Currently, some of my testfiles work, but the BBB files still don't.
|
|
* 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!).
|
