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.
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.
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().
When initially coding this functionality, I was aware of the potential for
infinite recursion here, just not how frequently such setups are actually
used/created out in the wild (nodetree.ma_node -> ma -> ma.nodetree is all too
common, and often even with several levels of indirection!).
However, the best fix for these problems was not immediately clear. Alternatives
considered included...
1) checking for common recursive cases. This was the solution employed for one
of the early patches committed to try and get around this. However, it's all too
easy to defeat these measures (with all the possible combinations of indirection
node groups bring).
2) arbitrarily restricting recursion to only go down 2/3 levels? Has the risk
of missing some deeply chained/nested drivers, but at least we're guaranteed to
not get too bad. (Plus, who creates such setups anyway ;)
*3) using the generic LIB_DOIT flag (check for tagged items and not recurse down
there). Not as future-proof if some new code suddenly decides to start adding
these tags to materials along the way, but is easiest to add, and should be
flexible enough to catch most cases, since we only care that at some point those
drivers will be evaluated if they're attached to stuff we're interested in.
4) introducing a separate flag for Materials indicating they've been checked
already. Similar to 3) and solves the future-proofing, but this leads to...
5) why bother with remembering to clear flags before traversing for drivers to
evaluate, when they should be tagged for evaluation like everything else?
Downside - requires depsgraph refactor so that we can actually track the fact
that there are dependencies to/from the material datablock, and not just to the
object using said material. (i.e. Currently infeasible)
