This triggered an "almost parallel" case in setting the
offset meet points, which is OK but code needed improvement
put the meet point in a more accurate place.
This ia fix for part of the report T61214.
This partially reverts bf2c5217 and makes it so animation is evaluated
for datablocks which were never evaluated within the dependency graph.
Not ideal, but safest way currently.
Animation for already evaluated datablocks will only be evaluated on
manual edits, so the initial bugfix is still valid.
This is unreliable for cases when multiple dependency graphs
are to be updated.
The only reason why it was attempted to be made is to deal
with cases when ID appears in the dependency graph for the
first time. But even then it should be smart enough bring
itself to an up-to-date state without any extra tricks.
Right clicking on a menu item now closes it's sub-menus and opens
the button's context menu.
This is needed for adding them to the quick favourites menu.
Resolves T58729, T61015.
Also capture event to avoid Move transform.
Note: Now it's using a report message. Maybe this can be removed, but without the message, the event is captured by move transform.
Previously, the curve self snapping would only snap to points that were
earlier in the curve structure. This was because of a simple coding
snafu of using break when meaning to use continue.
This was caused by curves pointing to each other
creating a cyclic dependency.
While the dependency graph detects this, generating a mesh for render
recursively generates data which cashes in this case.
Add in a check to detect cyclic links.
Note, this bug exists in 2.7x too - but only crashes on render
since 2.7x didn't use 'for_render' when converting data.
By default wire would z-fight against the surface.
Increase the bias, also don't adjust the 'w' component
since it causes bias that depends on the view direction.
There is no reason not to duplicate Actions too here, especially when
Materials' Actions are pretty much impossible to edit from current UI
(afaik, DopeSheet editor does not has any way to change them?).
Values outside the 0..1 range produce negative colors, so now clamp to that
range everywhere. Also fixes improper handling of hue > 2.0 in some places.
Usual legacy/history crap in NodeTree code... Datablocks's specific
freeing code should never, ever do refcounting management, this is
handled by higher-level code from BKE_library area.
Nuke away old nodeCopyNode(), much better to use new BKE_node_copy_ex(),
which behaves as expected for the various optional flags that can be passed.
This also removes the need to handle ID refcounting in calling code
(ugly!) and allows us to remove an even uglier name from our codebase! :D
Note that this fixes three related issues actually, that bug was also
affecting copy/paste of nodes, and 'Separate with copy' operator (the
latter being actually fully wrong, since it was not refcounting
anything, not even node->id pointer...).
More or less same code was being executed twice during ID copying.
Makes no sense to add yet another switch-by-ID-type to handle
specificaly runtime data during ID copying, we already have
BKE_xxx_copy_data() functions for that.
For OIIO 2.x we must use unique_ptr. This also required updating the
guarded allocator for std::move to work. Since C++11 construct/destroy
have a default implementation that also works this case, so we just
leave it out.
Was a use-after-free during relations update.
Now we do similar dependency graph tags, but without any
extra animation update logic, which was accessing various
pointers.
Was found when looking into a file from T56635.
