Supports selecting using object data, material and library.
Would be nice to hide this menu item from menus appearing for
datablocks which does not support such a selection, but that
could be done separately.
Fixed by clamping current index value to 0..list_size-1 range in list event
handling function. This shouldn't give any regressions since this clamping\
happens only after template was already displayed so items counter should be
correct here.
It is still possible to set index to meaningless value by directly changing
the index value via python, but that's not in the scope of interface engine
and not currently considered a bug.
Would rather have mathematical functions consistent from using
the same vector for input and output values point of view then
introducing questionable optimizations.
draw_rigid_body_pivot() didn't check it could actualy use the given ob_wire_col...
Also silenced a compiler warning, and removed (replaced) a potential dengerous pointer cast (char *[4] -> int* is not safe on 64bit machines!).
Boid operators now retrieve the particle settings from the context directly, instead of always using the particle system (which is only needed to get to the settings anyway). When particle settings are pinned there is no particle system in the context, causing the operators to fail.
The particle system modifier has to ensure tesselation before testing for topology changes. It compares the number of vertices, edges and tesselation faces to the previously stored values.
Note that this test only detects a subset of actual topology changes (where the number of elements differs), but this is a known limitation we have to live with for now.
The image format for the node and sockets were not properly initialized. The file output node only supports image types (not movies), so it needs to check for proper format type after copying from the render settings.
This fixes memory overflow caused by creating render result every time
RenderResult is creating when updating sample and not being freed until
tile is fully rendered.
Solved in probably not best way -- RenderResult is being stored in
RenderBuffers, so it's creating only once.
This solves memory issues, but while was looking into this issue
discovered dramatic slowdown caused by samples update in some files
from mango svn.
Solving this slowdown is becoming first priority from now on.
Does not have any effect for current registerable types (Operator, Menu, Panel, etc.), since none of those actually have a base struct, but will be required for future types with an actual hierarchy (custom nodes).
Seems to be simple non-initialized buffer used in math, but additional
check would be welcome here.
At least now result doesn't seems to be corrupted and seems to behaving
the same way as non-tile compositor.
