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.
shape instead of just the difference/deltas applied by the source shape
Apparently this was a regression from that crept in during the BMesh merge. I've
just restored the pre-BMesh method, adapted for the BMesh style.
Also, removed a somewhat superfluous (?) copy at the end of each step (from co
back to sco). It didn't seem to be serving any purpose (i.e. we're not trying to
modify the source shape at all).
Error flags set on Drivers and F-Curves when they can't be evaluated or flushed
properly are now cleared when loading files, allowing drivers to be re-evaluated
when a file is reloaded. This means that if a driver couldn't be used in the
previous session due to the set of extension modules active at the time (and was
thus disabled), reloading the file with the necessary extensions loaded means
that the driver can work out of the box without manually re-enabling.
Convert color into ACES color space from rec709 (which is quite the same
as blender internal) before running tonecurve and convert color space back
after tonecurve.
This makes tonecurve be applying in actual space it was intended to and it
makes color range smoother a bit.
Would be nice to convert this into OCIO view tho.
The problem is motion blur was being treated as a per scene operation, but all scenes were trying to use the same accumulation buffer. Now motion blur is done in EndFrame() instead of PostRenderScene().
