`BKE_nlastrip_find_active()` and `update_active_strip()` now do a more
thorough search for the active strip, by also recursing into
meta-strips.
There were some assumptions in the NLA code that the active strips is
contained in the active track. This assumption turned out to be false:
when there is a meta-strip, the active strip could be inside that, and
then it's not contained in `active_track.strips` directly.
Apart from the above, there are other situations in which the track
pointed to by `AnimData::act_track` does *not* contain the active strip
(even indirectly).
Both these cases can happen when the transform system is moving a strip
that's in tweak mode. Entering tweak mode doesn't just search for the
active track/strip, but also falls back to the last-selected ones. This
means that the track/strip pointers & flags can be out of sync with
what's being tweaked/transformed. Because of this, the assumption that
there is any relation between "active strip" and "active track" has been
removed from the `update_active_strip()` function.
All this searching could be prevented by passing the `AnimData` to the
code that duplicates tracks & strips. That way, when the active
track/strip is dup'ed, the `AnimData` pointers can be updated as well.
That would require more refactoring and thus could introduce other bugs,
so that's left for later.
* Rename ambiguous rgb to scene_linear in some places
* Precompute matrices to directly go to scene instead of through XYZ
* Make function signatures more consistent
Between scene linear and sRGB, XYZ, linear Rec.709 and ACES2065-1.
And add some clarifications about color spaces in the docs.
Fixes T98267
Ref T68926
Differential Revision: https://developer.blender.org/D14989
Some RNA property update callbacks can already generate such modifier,
and only one is allowed per object, so had to adapt code actually adding
new modifiers in liboverride apply codebase.
Also fixed an unreported issue of incorrect interpolation of thickness.
Reviewed By: Aleš Jelovčan (frogstomp), Antonio Vazquez (antoniov)
Differential Revision: https://developer.blender.org/D15005
The final normalization step of sculpt normal calculation iterates over
all unique vertices in each node and marks them as done. However,
storing the done mask in a bitmap meant that multiple threads could
write to a single byte at the same time, because the bits for separate
threads could be stored in the same byte. This is not threadsafe
Fixing this issue seems to improve performance as well. First I tested
just clearing the entire bitmap after the normal calculation. Then I
tested using an array of booleans instead, which turned out to be
slightly better, and simplifies code a bit.
I tested on a Ryzen 3800x, on an 8 million polygon subdivided
Suzanne by using the grab brush with a radius large enough to
affect most of the mesh.
| Original | Clear Entire Bitmap | Boolean Array |
| --------- | ------------------- | ------------- |
| 67.9 ms | 59.1 ms | 57.9 ms |
| 1.0x | 1.15x | 1.17x |
Differential Revision: https://developer.blender.org/D14985
When labels in popups (typically headings) matched the name of a button,
the label would be activated instead of the button.
This caused the unwrap menu in the UV editor not to re-select "Unwrap"
when opening a second time.
The change was kind of intentional on {rB21e72496a629}.
That commit made mouse movement to "select" the contraint in Auto
Constraint a requirement.
This deduplicated the code a bit, but this requirement is not
comfortable for the first "selection" of the contraint.
So the constraint "selection" is now done in two ways:
- If there is no contraint, the "selection" is done immediately;
- If there is already a constraint, the "selection" is delayed by 1 event to simulate a constraint cancellation if there is no mouse movement.
Existing code for the `Move` operator, and some `Collections` panel
operations (Object properties) was absolutely not override-safe, and
sometimes not even linked-data safe.
That max number of `10000` level of recursivity was a typo (should have
been `1000`), but even that is way too high, typical sane situation
should not lead to more than a few tens of levels, so reducing the max
level to 200.
Also improve error message with more context info about the issue.
Found while investigating issues for the Blender Studio's Heist production.
That max number of `10000` level of recursivity was a typo (should have
been `1000`), but even that is way too high, typical sane situation
should not lead to more than a few tens of levels, so reducing the max
level to 200.
Also improve error message with more context info about the issue.
Found while investigating issues for the Blender Studio's Heist production.
In some cases (when there is an evaluated curve), the conversion code
would try to free the evaluated data-block twice, because freeing the
object would free it from `data_eval` and then the data-block was freed
again explicitly. Now check if the data-block is stored in `data_eval`
before freeing `object.data` manually. This is another area that's made
more complex by the fact that we change the meaning of `object.data`
for evaluated objects. The solution is more complicated than it should
be, but it works whether or not an evaluated mesh or curve exists.
It wasn't possible to temporarily orbit the view, then set back to an
axis-aligned view.
Details:
- It was possible to change RegionView3D.view_rotation while the view
kept the axis alignment value (Top, Left, Front .. etc) which
displayed in the viewport overlay.
Now changing the view rotation directly or via "view_matrix" resets
the axis-alignment - clearing when the view is no longer axis-aligned
or assigning the newly aligned axis.
- RegionView3D.is_orthographic_side_view added in [0] could be assigned
but wasn't useful as it treated an enum as a boolean only setting the
RegionView3D.view to RV3D_VIEW_USER or RV3D_VIEW_FRONT.
Now enabling this aligns the viewport rotation to it's closest
axis-aligned orientation setting RegionView3D.view & view_axis_roll
accordingly. Note that the "orthographic" term is misleading as the
property only relates to axis-alignment, not to the
perspective/orthographic setting. We could consider deprecating the
current naming.
[0]: 63bae864f4
View roll checked if the resulting roll was close to a view axis
but didn't write the aligned quaternion back to the final result.
Add ED_view3d_quat_to_axis_view_and_reset_quat since most callers
to ED_view3d_quat_to_axis_view will reset the quaternion when a view
aligned axis is found.
Issue revealed by rB90e12e823ff0. Hidden objects may not be fully
evaluated by the despgraph, do not attempt to restore edit/sculpt/etc.
modes for those.
Should also be backported to 2.93 LTS release.
Sometimes integers are mixed using float weights. In those cases
the mixed result has to be converted from into float again.
Previously, this was done using a simple cast, which was unexpected
because e.g. 14.999 would be cast to 14 instead of 15.
Now, the values are rounded properly.
This can affect existing files unfortunately without a good option
for versioning. Gladly, very few files seem to depend on the details
of the old behavior.
Differential Revision: https://developer.blender.org/D14892
This makes changes to the opensubdiv module to support additional vertex data
besides the vertex position, that is smootly interpolated the same way. This is
different than varying data which is interpolated linearly.
Fixes T96596: wrong generated texture coordinates with GPU subdivision. In that
bug lazy subdivision would not interpolate orcos.
Later on, this implementation can also be used to remove the modifier stack
mechanism where modifiers are evaluated a second time for orcos, which is messy
and inefficient. But that's a more risky change, this is just the part to fix
the bug in 3.2.
Differential Revision: https://developer.blender.org/D14973
Previously, the depsgraph assumed that every node tree might contain
a reference to a video. This resulted noticeable overhead when there
was no video.
Checking whether a node tree contained a video was relatively expensive
to do in the depsgraph. It is cheaper now due to the structure of the new
node tree updater.
This also adds an additional run-time field to `bNodeTree` (there are
quite a few already). We should move those to a separate run-time
struct, but not as part of a bug fix.
Differential Revision: https://developer.blender.org/D14957
If making liboverride of an empty collection, this (root of override
hierarchy) collection would get untagged in code when checking for
collections that do not need to be overridden, leading to not overriding
this root collection, and later in code to using NULL pointer.
Regression caused by [0] which changed node selection to use
PRESS for selection and CLICK_DRAG to transform the selection.
This conflicted with Alt-LMB which would select the node then
pass-though to node.background_sample, preventing the drag event
from being activated.
Resolve by only activating background-sample when the cursor
isn't over a node or socket.
[0]: 4c3e91e5f5
Issue was caused by treating such strip as meta and using
`seq->channels` directly, which is not valid for scene strips.
Pointer to channels is now provided by function
`SEQ_get_seqbase_from_sequence`.
We need to ensure `Main.filepath` is consistent with the current path
where we are saving the .blend file, otherwise some path processing code
can produce invalid results (happens with e.g. the code syncing the two
path storages in Library IDs).
The problem is that depsgraph evaluation happens before the OpenGL context
is initialized, and so modifier evaluation happens without GPU subdivision.
Later the BKE_subsurf_modifier_can_do_gpu_subdiv test in the draw code gives
a different result.
This just checks if the mesh has information for GPU subdivision in the draw
code, and if so uses it. This is only set if the test for supported GPU
subdivision passes in the modifier evaluation.
Additionally it may be good to perform OpenGL context initialization earlier
so background render can take advantage of GPU subdivision, but this is more
complicated.
Differential Revision: https://developer.blender.org/D14969
This patch fixes long standing issue of reverse mode only performing loop 2 times and then stops displaying.
Differential revision: https://developer.blender.org/D14921
A regression since 113b8030ce: circle selection operators does not
define properties like deselect_all and a special name callback is to
be used for those.
This is what was already done for circle select in the 3D viewport.
Some other spaces were using the generic pick operator for the circle
selection which causes error prints in the console.
Refactoring event click-drag detection broke click detection for
simulated events. Resolve this by sharing logic for update previous
values in `wmWindow.eventstate` for regular event handling
(no functional changes for non-simulated events). Failure to detect
clicks for simulated events broke the undo test
`test_undo.view3d_multi_mode_select` in `../lib/tests/ui_simulate/run.py`.
All undo tests now pass.
Moving Text.as_string() from Python to C [0] added an extra new-line
causing a round-trip from_string/to_string to add a new-line,
this also broke the undo test `test_undo.text_editor_simple` in
`../lib/tests/ui_simulate/run.py`.
[0]: 231eac160e
When texture painting, brush textures and brush texture masks were not
transformed to account for UDIM tiles.
Differential Revision: https://developer.blender.org/D14671
Fix a crash when a driver variable targets an object and uses
`data.shape_keys.key["name"].value` in its expression.
The fix consists of adding an extra relation from the targeted object's
`GEOMETRY` component to the driver evaluation. This ensures that its
`data` pointer has been evaluated by the depsgraph and is safe to
follow.
This also resolves the concern raised on rB56407432a6aa.
Reviewed by: brecht
Differential Revision: https://developer.blender.org/D14956
The 'OVERRIDE_HIDDEN' extra collection would often be mistakenly added
to a linked collection, which is totally forbidden and guaranteed to
crash on undo/redo.
Reworked the code instantiating that extra collection in a more generic
and hopefully robust way now.
We really need to fix how unprojected radius (scene unit) works.
What happened is the paint code updates the brush's normal radius
with the current unprojected pixel radius, which was then
used by texture brush tiled mode.
To fix this I just cached the pixel radius at stroke start in
UnifiedPaintSettings->start_pixel_radius.
