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().
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)
Crash was caused by using NULL pointer as a wire color for drawing
object selection when drawing flag is set to DRAW_CONSTCOLOR.
Solved by not calling drawObjectSelect when DRAW_CONSTCOLOR flag
is set, which seems reasonable -- rather than adding checks deeper
in all possible functions which are being called there easier to
just not call that functions using a single check.
by default, since people usually want the layout to be updated).
Motivation has been confused user that tried to use live unwrap
afterwards and found that it would not work as it should.
Previous attempt was not taking into account parent nodes of the group nodes (i.e. frames). The nodeFromView function should be used to convert between relative node location to absolute view space. Also added this in the node_add_node helper function, which is used in a number of operators for adding nodes in a specific location.
There used to be an issue in colormanage_cache_get which lead to
wrong reference number counter in cases when exposure / gamma
does not match values stored in cache. In this case cache handle
should be set to NULL, no callee function could always call
buffer release function (as it was intended to).
Made display buffer acquire / release functions thread safe.
This applies to "external" API only, internal helpers are
non-thread safe for performance issues, so if one uses them
he need to be careful.
Converted partial display buffer update into a single function
which still updates all display buffer ever created for given
image buffer. This means that it's not needed to create any
kind of context first and if there're display buffers created
in-between of partial updates they would also be updated with
next calls of partial updates.
This allowed to make render result nicely color managed during
rendering, meaning that render progress is visualisable with
color management for image editor set up.
