This commit changes a lot of how IDs are handled internally, especially the unlinking/freeing
processes. So far, this was very fuzy, to summarize cleanly deleting or replacing a datablock
was pretty much impossible, except for a few special cases.
Also, unlinking was handled by each datatype, in a rather messy and prone-to-errors way (quite
a few ID usages were missed or wrongly handled that way).
One of the main goal of id-remap branch was to cleanup this, and fatorize ID links handling
by using library_query utils to allow generic handling of those, which is now the case
(now, generic ID links handling is only "knwon" from readfile.c and library_query.c).
This commit also adds backends to allow live replacement and deletion of datablocks in Blender
(so-called 'remapping' process, where we replace all usages of a given ID pointer by a new one,
or NULL one in case of unlinking).
This will allow nice new features, like ability to easily reload or relocate libraries, real immediate
deletion of datablocks in blender, replacement of one datablock by another, etc.
Some of those are for next commits.
A word of warning: this commit is highly risky, because it affects potentially a lot in Blender core.
Though it was tested rather deeply, being totally impossible to check all possible ID usage cases,
it's likely there are some remaining issues and bugs in new code... Please report them! ;)
Review task: D2027 (https://developer.blender.org/D2027).
Reviewed by campbellbarton, thanks a bunch.
Distinguish the 3 different methods for acquiring pixel color values (executePixel, executePixelSampled, executePixelFiltered).
This makes it easier to keep track of the different sampling methods (and works nicer with IDEs that do code parsing).
Differential Revision: http://developer.blender.org/D7
- freeing a mask from RNA BKE_libblock_free() twice on the mask.
- loading a new blend file would only free the mask and not unlink it from nodes - it would access freed memory.
for a color combine (mix) node with render resolution at 100%
Seems to be that the MaskNode has been created as a complex node. But no
complex features were used. Converted the execute pixel to simple
execution. And it sees that the crash does not happen.
Not sure if it is the issue is solved. I am going to let the user retest
with this revision.
This creates a list of splines to be rasterized in nitExecution which
is being called from main thread. This should resolve possible threading
issues discovered in tomato branch.
