Age | Commit message (Collapse) | Author |
|
BKE_report()<->BKE_reportf() fixes.
|
|
Also forgot to translate reports' titles, and change some usages of BKE_reportf to simple BKE_report, when the former is not needed!
|
|
or good to keep for completeness. quieted some warnings and add flags -Wmissing-include-dirs and -Wno-div-by-zero to cmake/gcc
|
|
|
|
Note about long lines: I did not touch to two pieces of code (because I don’t see any way to keep a nicely formated, compact code, with shorter lines):
* The node types definitions into rna_nodetree_types.h
* The vgroup name functions into rna_particle.c
|
|
Addresses:
* C++ comments.
* Spaces after if/for/while/switch statements.
* Spaces around assignment operators.
|
|
* Split off code to refresh relative/builtin KeyingSets for the
current context before they get used to a separate function.
* Hooked this up to a new PyAPI/RNA function: KeyingSet.refresh().
Call this before checking the paths that a Keying Set has, especially
if it is not "absolute"
* Added option for "Select Grouped" operator (for Objects), which will
select all objects affected by the active Keying Set. This is probably
more useful for absolute KeyingSets, where changing the selection is
less likely to affect the result.
- The equivalent for bones is currently still in development, but is
likely to be more useful for animators, where rigs are the primary
animation entities they deal with
|
|
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$
|
|
|
|
|
|
those groups can't be deleted
- Disallow this and report a warning in the console when it happens.
- File selector operators now report in the global report console.
- Cleared some warnings.
|
|
|
|
* Added operator (Ctrl Shift Alt I) to show menu for changing the active Keying Set in the 3D view (todo item from last commit)
* KeyingSetInfo (i.e. the Builtin Keying Set classes) can now be accessed from Keying Set instances with ks.type_info
* Added ks.remove_all_paths() function to remove all the paths for a Keying Set.
---
These two changes mean that builtin Keying Sets could be refreshed in response to context changes by doing:
<code>
ks = bpy.context.scene.active_keying_set
if ks.absolute==False and ks.type_info:
ksi = ks.type_info
# remove existing paths to fill with new
ks.remove_all_paths()
# check if Keying Set can be used in current context
if ksi.poll(bpy.context):
# call iterator() which calls generate() and re-populates paths list
ksi.iterator(bpy.context, ks)
</code>
And then, once this has been done, the paths that the Keying Set will operate on can be accessed as
<code>
paths = bpy.context.scene.active_keying_set.paths
</code>
|
|
* Added 'id_name' property, which is used as the "typeinfo_name" by Keying Set instances. This is simply the name of the relevant KeyingSetInfo classes.
* Renamed the 'array_index' arg for ks.add_path() to 'index'. Also removed the 'entire array' toggle arg in favour of just passing -1 to index. However, Keying Sets in general still maintain their 'entire array' toggle flags for now, it's just that the API function does conversion between the two.
|
|
|
|
|
|
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.
|
|
Also some indention/whitespace tweaks
|
|
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.
|
|
|
|
are not descriptive.
* armature.pose_position: POSE_POSITION, REST_POSITION --> POSE, REST
* rigify now forces rest pose mode
* updated neck_flex to keep original bones unchanged
|
|
* Loading old files didn't initialise the new rotation variables properly
* Fixed some errors with the newly added operator for copying RNA-paths for properties
* Auto-keyframing now correctly refreshes animation editors after adding keyframes. Made the keyingsets code send notifiers again, but now using the newly added WM_main_event_add() (thanks Brecht)
* A few UI tweaks again for animation stuff (timeline, keyingsets UI)
|
|
Wrapped the Keying Sets API with RNA Functions so that they can now be called from Py-Scripts. This will ultimately be useful for riggers to create Keying Sets which can get loaded up/created for animators to use after importing their rig.
I've created a demo for this, which can be found at:
http://www.pasteall.org/blend/552
Notes:
- Kazanbas, I've had to create a rna_scene_api.c here to hold some of the relevant functions. Hopefully this won't cause you too much pain when you do your next merge from 2.5 to your branch ;)
- I've noticed that there seem to be a few cases mentioned in the demo which don't totally work yet. I'll commit some fixes for those later.
|