- curve map insert point had a nested loop which used the same value to index different arrays.
- dynamic paint used ternary operator where both outcomes were the same.
Currently this stuff is used for 2d tracking job only, but the same
thing would necessary for camera solver job, so moved it into more
general utility stuff.
The problem was in fact in the changes made to blend_ramp() func at rev42164. The checks on green pointer (if(g) {...) were checking the existance of a valid value (i.e. if input color was rgb or only shades of grey in r pointer), but as we get now a full float[3] pointer, this test is no more possible. And doing if(r_col[1]) {... was wrong, as it only broke things in case green was 0.0 (which was the case with the generated glare color of bug report).
So, just removed all those tests!
This change adds RNA access to tesselated face UVs and colors (MTFACE and MCOL), primarily for use by plugin renderers (e.g. cycles). The RNA mesh properties to get to these are prefixed with "tessface_" and additionally the help text states that these are for renderers, to try not to confuse existing mesh editing tool scripts into thinking they could just start using these values.
Transparent rendering can't be implemented in way it gives accurate shading in
3d viewport. It's acceptable for object mode, but when you're in edit mode
it gives more problems than benefits of seeing transparent faces.
This is possible fix for for weird polygons in [#29255] Object invisible and weird polygons appearance
Now the '+' button to the right of a line style name (in the template_ID
GUI widget) creates a copy of the active line style instead of a new
line style with default settings.
Also added a proper tool tip for the use of template_ID for line styles.
"Just a simple check for non power of two support (GLEW_ARB_texture_non_power_of_two), to avoid what seems to be a very slow, and very unnecessary gluScaleImage call."
This is the only part of the VideoTexture that does the POT calculation, so the check seems good.
It would be interesting if some opengl guru would like to benchmark the use of this in other areas of Blender (e.g. 2D Filters, and all GLSL materials).
Note that mipmap should also be supported automatically by this extension, so it's not something to worry about.
I've written a convenient function that returns the sibling of a node in the
red-black tree implementation originally implemented by Joshua Leung.
I want to use this get_sibling() function in the future to implement the missing
removal function of the red-black tree implementation.
For now the get_sibling() function just simplifies the get_uncle() function.
Just like the rest of the red-black tree implementation this diff is based on
Wikipedia: http://en.wikipedia.org/wiki/Red%E2%80%93black_tree#Removal
