- mathutils.Color.hsv attribute. eg. material.diffuse_color.hsv = 0.2, 0.8, 0.4
- Vector/Euler/Quaternion/Color now only take a single seq arg.
- internal function for parsing arrays. (cleanup messy internal list/vector/tuple/seq parsing)
- didnt update rigify yet.
This adds a new presets menu in the splash screen and the Input section of
User Preferences to choose a preset interaction style, consisting of key configurations
and also other user preferences such as select mouse button, view rotation style, etc.
Currently, just 'Blender' and 'Maya' presets are included, hopefully we can have more
presets contributed (and maintained!) by the community.
It's best to keep these presets minimal to avoid too many key conflicts. In the Maya one
I changed the view manipulation key/mouse combos and also the transform
manipulator keys, not much more than that.
To save an interaction preset, open the user preferences Input section, and press the
[ + ] button next to the presets menu. It will save out a .py file containing any edited key
maps and navigation preferences to the presets/interaction folder in your scripts folder.
---
Part of this commit changes the way that key maps are exported/displayed in
preferences - now partial key configs are allowed. Previously it would export/import the
entire key configuration, regardless of whether individual key maps were edited or not
(which would make them more susceptible to conflicts in unexpected areas).
(note, in blender terminology, a key map is a category of key items, such as
'Object Mode' or 'View 2d'.)
Now, the export and the UI display work in a similar way to how key maps are
processed internally - Locally edited key maps (after pressing the 'Edit' button) are
processed first, falling back to other key maps in the current key config, and then falling
back to the default key config. So it's possible for a key config to only include a few
key maps, and the rest just gets pulled from the default key config. The preferences
UI display works like this too behind the scenes in deciding what to show users,
however using it is just like it was before, the complexity is hidden.
- added new mathutils.Color() type, use with rna so we can do for eg:
material.diffuse_color.r = 1.0
# also has hsv access
material.diffuse_color.s = 0.6
- made Mathutils and Geometry module names lowercase.
- vectors now respect min/max settings.
- keyframing and adding drivers raises an error in an index is set on a non array, keyframing raises an error if it fails.
reference docs...
- added docstrings for remaining python bpy_struct functions
- added fake class for docs, bpy_struct, which is the base class of everything in bpy.types
- improved inherictance references for struct classes, include bpy_struct members.
* Some cases of struct name being set where it shouldnt have been.
* Spelling: wich --> which
* Copy and initialize uv modifier scale, remove unneeded enum.
* Ability to pin any object into the context.
* Update uv window while transforming (useful when used with UVProject modifier)
* Patch by Wahooney, so new template's are internal text and dont get saved over
by mistake.
* Fix for https://bugzilla.redhat.com/show_bug.cgi?id=572186
Bug 572186 - [abrt] crash in blender-2.49b-5.fc12: Process
/usr/bin/blender.bin was killed by signal 6 (SIGABRT). Original fix submitted
by Jochen Schmitt.
* [#21816] bpy.data.add_image has stopped working on Windows. moved to
bpy.data.images.load(), missed this call.
(commits 27726,27825,27828,27831,27832,27833,27834,27836,27837,27838,27839,27858 by Campbell from render25 branch)
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.
setting sys.stdin to None is done so python wont lock blender when it tries to read from the input. - help() from the console does this.
Running blender with -d keeps the stdin so python debugging can work. add info in the help message about this.
eventually it might be best to replace sys.stdin with our own object which interacts with the console but this is not trivial.
Added a tail control rig.
For now, you have to manually hook the resulting controls up to a separate spline IK rig that you make by hand. Perhaps this can be automated in the future.
For anyone using this: keep in mind that you need separate armatures for the tail deformation bones and tail control bones. Otherwise you create a cyclic dependency like so:
tail deform bones <- spline object <- tail control bones
reloading bpy_types was causing reload to fail. also unregister all modules in the reverse order that they were loaded, so when reloading removed files done hang around.
Required options:
mesh: name of mesh object(s) to add/get shapekeys to/from
(if multiple objects, make a comma-separated list)
Optional options:
loc_<x/y/z>: name of the shape key to tie to translation of the bone
loc_<x/y/z>_fac: default multiplier of the bone influence on the shape key
rot_<x/y/z>: name of the shape key to tie to rotation of the bone
rot_<x/y/z>_fac: default multiplier of the bone influence on the shape key
scale_<x/y/z>: name of the shape key to tie to scale of the bone
scale_<x/y/z>_fac: default multiplier of the bone influence on the shape key
