Since [0] notifiers were cleared and left in the queue, while harmless
it meant the call to remove the notifier from the set was redundant.
Now set aside a category to tag notifiers as having been cleared and
skip them entirely.
[0]: 0aaff9a07d
With rBe6a557952ead, concerns were reported about missing updates when
the view is moved other than through the Edge Pan system.
Although the transform operator blocks navigation in general, it is
good to avoid these cases.
The view offset, calculated by the Edge Pan system, only affects the
position of the nodes, but forget to update:
- snapping data
- final value of transform
- values used for custom drawing
Therefore, to avoid having to update a lot of scattered data, the
`transformViewUpdate` utility has been implemented to recalculate input
values when the view changes.
This utility does more than is necessary to fix the bug, but with that,
it can work in any situation.
The view offset, calculated by the Edge Pan system, only affects the
position of the nodes, but forget to update:
- snapping data
- final value of transform
- values used for custom drawing
Therefore, to avoid having to update a lot of scattered data, the
`transformViewUpdate` utility has been implemented to recalculate input
values when the view changes.
This utility does more than is necessary to fix the bug, but with that,
it can work in any situation.
The function does modify the object since it changes the name of a layer
it owns. Ideally this wouldn't be possible, but raw pointers don't have
ownership semantics so this is a common problem with CustomData.
The calculation was revised to address two issues:
* Discontinuities occurring when detail was a non-integer greater than 2.
* Levels of detail in the interval [0,1) repeating the levels of detail in
the interval [1,2).
This fixes Cycles, Eevee and geometry nodes.
Differential Revision: https://developer.blender.org/D15785
The blendfile_liblink and blendfile_io python tests in debug fired an
assert that WMWinMan object was in Main database, but not in the ID
name map. This was caused by wm_window_match_do going into case 3
there: the new WM list is completely empty, the old list is not empty,
and it was directly using the old/current list (via
wm_window_match_keep_current_wm function), without actually
registering/validating the objects in it through the name map.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D15787
The blendfile_liblink and blendfile_io python tests in debug fired an
assert that WMWinMan object was in Main database, but not in the ID
name map. This was caused by wm_window_match_do going into case 3
there: the new WM list is completely empty, the old list is not empty,
and it was directly using the old/current list (via
wm_window_match_keep_current_wm function), without actually
registering/validating the objects in it through the name map.
Reviewed By: Bastien Montagne
Differential Revision: https://developer.blender.org/D15787
While converting types from callbacks isn't a bug, it's unlikely
we ever want to do this on purpose and can hide mistakes such as
silently converting floating point values to ints as happened
with Sequencer.frame_start.
Those collections were so far mainly just tagged as fake user (even
though a few places in code already incremented usercount on them).
Since we now clear the fakeuser flag when linking/appending data, ensure
that these collections are preserved by making these usages regular ID
refcounting ones.
Reviewed By: brecht
Differential Revision: https://developer.blender.org/D15783
Commit is not working as expected in some cases, as revealed by
liboverride testcase entering infinite loop.
Code needs some more thinking.
This reverts commit ee7bd79b54.
Usually, when overriding collections, the linked reference ones are
removed from the ViewLayer, and the overrides replace them.
This change to `layer_collection_sync` code makes it so that in case
there is a free viewlayer hierarchy matching the linked collection, it
gets re-used for the override one, instead of re-creating everything
from scratch.
To achieve this, resync process is split into two steps, first regular
collections are processed, then the override ones. This should ensure
an override does not steal the layers of its reference if the later is
still instantiated in the view layer.
Since rBb100bdca25b1 the parent inverse was always reset in
ED_object_parent (also for just changing the parent type).
This does make sense (since there is no point keeping it when e.g
changing from "Bone" to "Object" or "Vertex" to "Object", for this to
really make sense it would have to be properly recalculated anyways
which does not happen afaict).
The reported issue was that setting the prop to the same value as it was
before (e.g. from "Object" to "Object") would still reset the parent
inverse which was really unexpected since from a user standpoint,
nothing has changed here.
So in case the value does not really change, we now just early out and
skip `ED_object_parent`.
Maniphest Tasks: T100599
Differential Revision: https://developer.blender.org/D15771
Added [0] which notes in most cases results are the same but in some
cases the result seems better. While true at the time of writing since
then mat3_to_quat has been improved and used for nearly all matrix
to quaternion conversion.
0: 876cfc837e
Making the callers responsible for this isn't practical as matrices are
often passed indirectly to a functions such as mat3_to_axis_angle,
BKE_object_mat3_to_rot & BKE_pchan_mat3_to_rot.
Or the matrix is combined from other matrices which could be negative.
Given quaternions calculated from negative matrices are completely
invalid and checking only needs to negate matrices with a negative
determinant, move the check into mat3_to_quat and related functions.
Add mat3_normalized_to_quat_fast for cases no error checking on the
input matrix is needed such as blending rotations.
