Welcome to mirror list, hosted at ThFree Co, Russian Federation.

git.blender.org/blender.git - Unnamed repository; edit this file 'description' to name the repository.
summaryrefslogtreecommitdiff
AgeCommit message (Collapse)Author
2010-02-27* Renaming some Keying Sets API functions to make the terminology more ↵Joshua Leung
consistent in the UI * Fixed bug with hotkeys for adding properties to Keying Sets using the KKEY over the relevant buttons. Was calling the remove callback instead.
2010-02-12correct fsf addressCampbell Barton
2010-01-30A few minor code cleanup tweaks for recent commits in animation code, to ↵Joshua Leung
better follow conventions elsewhere here :)
2010-01-30deleting objects which were driver targets would crash blender.Campbell Barton
added a utility function BKE_animdata_main_cb which loops over all AnimData's of all ID's
2010-01-27Bugfix #20752: Background Image Panel Properties Keyframing?Joshua Leung
Added a check in RNA_property_animateable() which checks if the base ID-block can have animation data or not. Screen data currently cannot have animation data, so this solves that problem (where there were non-functional entries there in the menu).
2010-01-10Make linked animdata working again, copies NLA too, as well as ObData ↵Campbell Barton
animdata where types match
2009-10-20Bugfix #19663: Renaming named data doesn't fix F-CurvesJoshua Leung
RNA Paths used in F-Curve, Drivers, etc. now get renamed when some data that they use gets renamed. This only works when things like Bones, Constraints, Shape Keys, and Modifiers get renamed, but other cases can get added easily. The code here only performs simple string replacements, so there is the potential for problems when several sets of data with the same names are present. For example, if there are multiple armatures with bones that have the same names, renaming a bone on one armature (with a bone on another armature having the same name) will break all the drivers on the other one, even though they aren't really connected. However, I don't expect the aforementioned scenario to really be a problem in most production scenarios.
2009-09-092.5: Object moduleBrecht Van Lommel
* Split object_edit.c into multiple files: object_add.c, object_edit.c, object_hook.c, object_relations.c, object_select.c, object_transform.c. * Rename files to have consistent object_ and mball_ prefix: object_shapekey.c, object_lattice.c, object_vgroup.c, mball_edit.c. * Added operators: * vertex group menu and set active * apply location, rotation, scale, visual transform (location is new) * make local * make vertex parent * move to layer * convert to curve/mesh (not finished yet) * Many small fixes for marked issues, but still much code to be cleaned up here...
2009-08-152.5: Screen/Scene New/Delete operators.Brecht Van Lommel
Implementation Note: * Moved the scene copy/unlink code back into blenkernel, with the exception of the copy single user stuff which is still in object_edit.c. * Uses SCREENDELETE notifier like SCREENBROWSE, seems only clean way to do this now.
2009-07-182.5 - Optimisations for Keyframe Drawing in DopeSheetJoshua Leung
Keyframes are now prepared for drawing by being added to a binary-tree structure instead of using insertion-sort on a Double-Linked List. This gives rather significant improvements on a few bad cases (*). I've implemented a basic Red-Black Tree whose nodes/data-structures can also be used as a simple Double-Linked List (ListBase) for this purpose. The implementation of this tree currently does not have support for removing individual nodes, since such capabilities aren't needed yet. Stats (using keyframes from an imported .bvh animation file): * When only the keyframes are drawn (i.e. long keyframes are not identified), the time needed to draw the DopeSheet region 10 times went down from 4000ms to about 300ms. * When long keyframes are considered as well, the same test has gone from 6000ms to 3000ms. There is still a bottleneck there that I haven't been able to remove yet (an attempt at this made the runtimes go through the roof - 32000 ms for the test done here). Assorted Notes: * Added missing headers for some files * Fixed profiling flags for mingw. There was an extra space which prevented the sound-code from compiling.
2009-04-15Fixing linux compiling Joilnen Leite
2009-04-152.5 PoseLib - First steps to get PoseLib to work in 2.5Joshua Leung
* 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) :)
2009-02-15Keying Sets: Added 'remove selected from active set' (Alt-K) operator in ↵Joshua Leung
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.
2009-02-13Keying Sets: Wrapped KeyingSets in RNA Joshua Leung
* 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.
2009-02-11Keying Sets: Initial commit of skeleton codeJoshua Leung
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.
2009-01-182.5 - AnimSys Data management stuff...Joshua Leung
* 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
2009-01-172.5 - AnimData fixesJoshua Leung
* 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)...
2009-01-172.5: Blender "Animato" - New Animation System Joshua Leung
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!).