- use python malloc's in bpy_array.c
- automatically blending bone locations is disabled if the target bone has locked location
- neck had incorrect roll
Now, temp screens are hidden from being accessed directly, with a new 'Back to Previous' button appearing in place of the screen menu when (for example) fullscreen render image areas are present. Window type menus also get disabled here too, to prevent things from getting too mixed up.
1. MSVC 9 projectfiles update (graph_header.c, action_header.c and nla_header.c removed)
2. Fix for opening the filebrowser when saving file for the first time (untitled.blend) from file menu
3. Add CROSS effect sequence type back to menu. (Durian fix)
Note: Removed SEQ_EFFECT from rna, since this no actual sequence type, but rather used to check for the effect bit.
also avoids hitting the 255 string limit if you want to add 100's of values. eg.
>>> b05/max(0.001, [globals().update({"LOCALS":locals(), "ADD":float.__add__, "reduce":__import__("functools").reduce}), 0.0][1], max((, [LOCALS["b%.2d" % (i+1)] for i in range(5)])))
Since this more simple expression reaches the limit fairly quick...
>>> b05/max(0.001,b01+b02+b03+b04+b05)
* Make partial update work again for faster editing.
* Draw parents over children again, nicer for editing.
* Fix crash with remove tools & showing child particles.
* Fix children not disappearing always when setting to None.
* Fix wrong normal for last point in child path.
* Fix a python error in the hair dynamics panel.
- updated delta not to remove a bone
- spine and neck rigs interpolation bones are now axis aligned to the control bone
- palm tag is expected on the pointer finger rather then the wrist
- operate on bone children first working up the chain (not essential but more pradictable)
Brecht, I added a Layout template function, template_dopesheet_filter -> uiTemplateDopeSheetFilter, this creates the group of buttons for filtering ID type (and some other options) for animation editors (Graph, NLA and Dopesheet). I hope this is all right, if not, we can move this maybe to a .py file as a function for reuse.
Basic definition works like a python operator but you derive from "bpy.types.Macro" instead.
Operators are added to the macro after it has been added with "bpy.ops.add_macro" through the class method "define" which takes an operator id and returns an OperatorMacroType (new RNA type) for which properties can then be defined to be passed to the operator when run.
Example: http://blenderartists.org/~theeth/bf/macro.py
Using this system, it should be easy to add an operator to the console that converts selected lines into a macro or even a more generic record macro system.
original bone names cant be changed anymore but this means the bones can be re-parented without confusing scripts that run after the rig is modified.
support for defining a bone to have multiple types and automatically blending between 2 generated rigs
Don't use passes anymore for indirect lighting, people were using this
probably thinking it would do bounces, but that's not the intention of
this feature, it is to reduce problems with light bleeding. I want to
remove this option for AO as well, but will leave it in for now until
there is a better alternative.
Added bounces option for indirect, could be implemented much better,
but perhaps useful for testing now. Existing files need to set this to
1 to get the same results again.
After testing and feedback, I've decided to slightly modify the way color
management works internally. While the previous method worked well for
rendering, was a smaller transition and had some advantages over this
new method, it was a bit more ambiguous, and was making things difficult
for other areas such as compositing.
This implementation now considers all color data (with only a couple of
exceptions such as brush colors) to be stored in linear RGB color space,
rather than sRGB as previously. This brings it in line with Nuke, which also
operates this way, quite successfully. Color swatches, pickers, color ramp
display are now gamma corrected to display gamma so you can see what
you're doing, but the numbers themselves are considered linear. This
makes understanding blending modes more clear (a 0.5 value on overlay
will not change the result now) as well as making color swatches act more
predictably in the compositor, however bringing over color values from
applications like photoshop or gimp, that operate in a gamma space,
will give identical results.
This commit will convert over existing files saved by earlier 2.5 versions to
work generally the same, though there may be some slight differences with
things like textures. Now that we're set on changing other areas of shading,
this won't be too disruptive overall.
I've made a diagram explaining the pipeline here:
http://mke3.net/blender/devel/2.5/25_linear_workflow_pipeline.png
and some docs here:
http://www.blender.org/development/release-logs/blender-250/color-management/
