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)
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.
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 -
