There were actually two bugs, the one reported and that the Sync Callback never has been called after someone had to add #ifdefs around the call without checking that the build systems are even configured to add the needed definition, am I right Cam? :P
Related to another bug fixed recently, both viewer + split viewer
could be set to output to the same image. That also could make node
tree localization/sync go wrong.
was drawn. Problem was that these were not set to be in gamma space. Also
needed to fix automatic 0..255 to 0..1 range conversion for PROP_COLOR_GAMMA,
was only working for PROP_COLOR.
Reported by Michael Williamson
Add support to write the uvlayer name as found in <bind_vertex_input> semantic attribute (Blender
exports in this one too, so reimport goes ok now).
I have created a patch for OpenCOLLADA to be applied against r769, which is needed
for this fix to work: http://code.google.com/p/opencollada/issues/detail?id=117
The Windows OpenCOLLADA updated builds (r769+patches) will be committed after this.
Note: This means that linux and osx users will have to patch OpenCOLLADA themselves, until
it's committed (or in case of OSX the libs updated in lib/darwinXXX).
* 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.
