* Shapekey editor now shows ID-box for showing and editing the action assigned here. This should help alleviate the misconceptions arising to #23823, where user tries to load shapekey action into Action Editor (context there is ob-action only).
There are still a few minor update bugs that I still need to fix here (i.e. post keyframing) though. Those shouldn't take too long I think.
* Changing the action used in the Action Editor properly decrements the user counts now. This solves the bug where you could get actions with a high usercount, but not that many actual users.
Submitted by: Shane Ambler (sambler)
<quote>
From blenderstorm idea# 169 this patch changes the swatch button to display a border showing the keyed status colour
of the colour.
I chose to go with showing the keyed colour in a border around the swatch, insetting the size of the swatch colour to
prevent altering the sizing of the swatch. An un-keyed swatch is not altered visually, only a keyed colour swatch is
changed to have the keyed colour around the outside of the swatch button.
I think a border of 3 pixels is sufficient to make the keyed colour visible without taking too much of the colour area
away.
</quote>
Second attempt at fixing. Last time, I missed the case where the "Only Insert Available" userpref was enabled, which was why the bugreport was reopened. Hopefully I haven't missed anything else...
When there are 2+ consecutive deform modifiers, the second modifier was getting incorrect normals, this only showed up for the displace modifier since its the only deform modifier that uses vertex normals.
It would have been easy to fix this by always calculating normals on deform modifiers, but slow.
To fix this I added a function to check if a deform modifier needs normals, so the normal calculation function only runs if there are 2 modifiers in a row and the second uses normals.
Now drivers cannot be added to properties that have been animated (and visa versa). Previously, the check was only checking if there was a keyframe, not whether the property was animated.
safety fixes, was one case where it was still using get_ibuf instead of
acquire/release_ibuf, this is required for render and compositing results
which are modified by other threads.
* Sequence speed effect was functional in theory, but very difficult to actually use.
* Now the effect works as follows:
- "Speed Factor" (formerly "speed fade") controls the current speed of the sequence (can be animated).
- "Use as speed" (formerly "f-curve velocity") is now the default behavior so that the "speed effect" by default changes the "speed" of the sequence.
- "Multiply Speed" (formerly "global speed") is a scale factor that's applied to the calculated frame (can't be animated).
- Without animation "Speed Factor" and "Multiply Speed" work exactly the same (in this case "multiply speed" could perhaps be disabled in ui, but currently there's no easy way to check this).
- If "Use as speed" is not checked the effect simply remaps the current frame to the given "Frame Number" (can be animated).
- "Scale to length" (formerly "f-curve compress y")scales "Frame numbers" from 0.0-1.0 to the length of the target strip to allow easy animation.
* Tooltips added for all values and options.
* Code for frame blending was nowhere to be seen, so I commented the option out from ui.
* This should fix at least bugs #20979 and #21309.
