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.
For sure actual issue is in carve's triangulation system which need
to be investigated and fixed. For now only fixed by re-shuffling a
bit existing degenerative faces check and added extra checks there.
Would look into actual fix a bit later.
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.
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.
* [#32040] size-input of a blur-node is uniform for the whole picture
* [#32062] Blur node Size input is not working with
* [#32140] Blur Node using a greyscale input as size multiplier fails
to work
Node now has a new option (new compositor cannot detect if the connected
part is a single value, or an image connected).
With this option the use of a reference image to multiply the size of
the blur per pixel can be enabled/disabled.
Regards,
Jeroen
- At Mind -
