The issue was that the data-blocks of two different undo steps were detected to
be identical, even if the attributes changed. That's because even if the
implicitly-shared data was different, they were turned into the same pointer by
cadb3fe5c5 on write.
This patch makes it so that for undo steps, implicitly shared data does not use
the pointer stability feature (in a sense, implicit-sharing itself provides
pointer stability for undo steps already).
The main tricky aspect is that we need to know if a pointer is implicitly shared
in `writestruct_at_address_nr` and oftentimes that's called before the
corresponding shared data is actually written with `BLO_write_shared`. The
solution is to enforce that the blend-write code has to know what pointers are
implicitly-shared before they are written the first time. The simplest way to
ensure that is to call `BLO_write_shared` first. However, that's not always
possible, especially when the pointer is directly embedded in an ID. Therefore,
there is a new `BLO_write_shared_tag` function that can be used in such cases.
The undo performance for the file in #141262 is still fixed with this change.
Pull Request: https://projects.blender.org/blender/blender/pulls/148144
`socket.socket_typeinfo()` can be nullptr when reading blend files that
contains custom socket types that are not registered yet. This fix
prevents crashing when this happenes (but the socket will stay
unregistered).
Pull Request: https://projects.blender.org/blender/blender/pulls/148103
Instead of reordering edges to be able to map them with hash sets, new
edges order (since 157e7e0351) is kept as-is in order to not
touch edge attributes. In early return in case of correct mesh this new
ordering was missed. This was found in file from #147694.
Pull Request: https://projects.blender.org/blender/blender/pulls/147872
Fix playhead snapping to seconds, when the frame rate is less than 0.5
FPS.
This makes it possible to snap to fractions of frames, to support setups
with multiple seconds per frame. Of course this only has any effect
(apart from not crashing) when sub-frames are enabled.
I've also added unit tests, and verified that the values are the same
from before this refactor.
Pull Request: https://projects.blender.org/blender/blender/pulls/148074
Regression in [0] caused printing integers to crash.
While this function isn't widely used it could crash logging
key-map items.
Also add tests for IDP_reprN.
Ref !148109
[0]: 92cf9dd2f2
While uncommon, brush initialization does happen in some addon
workflows. Prior changes to use custom pressure curves in more places
did not initialize the `CurveMapping` struct correctly.
Pull Request: https://projects.blender.org/blender/blender/pulls/147840
Currently, the scene strip preview uses the existing dependency
graph built for that scene. This was not a big issue before
the sequencer scene was introduced, because the user would have
to create two main Blender windows to run into problems.
Now with the sequencer scene, it's possible to look at the scene
of a scene strip within the same window.
When the user is editing the scene (e.g. moving an animated object)
any open sequencer preview will cause the edits to be flushed.
This can e.g. result in visual jumping of animated objects, and more.
This PR attempts to fix the issue in a straightforward way: Use
a separate dependency graph for rendering the sequencer preview.
While this fixes the immediate issues, there are some consequences:
* The memory usage of the scene dependency graph _can_ roughly
double (since there are now likely two instances of the same
dependency graph). Because of implicit sharing, unmodified data
will not be copied. But for example modifiers on meshes would
currently create two copies of the evaluated data in the two
dependency graphs.
* Creating the dependency graph can be costly, which will cause the
first frame that the scene has to render to be slower.
Note: The current code changes some properties of the original scene
like the frame, subframe etc. before rendering and then restores
the original state. In theory, this part of the code can be removed,
but may be a bit too risky for just a fix. This should be improved
at a later stage.
Also resolves#146769, #139501.
Pull Request: https://projects.blender.org/blender/blender/pulls/147457
This speeds up drawing of the UI of the Geometry Nodes modifier, especially for
very large node trees like in the files from #146949.
A couple previous commits and #147883 speed up the inferencing significantly
already. However, there is a certain limit to how fast this can be on large
complex node trees. While there is some more optimization potential, this patch
implements a cache on the Geometry Nodes modifier level. This means that as long
as the inputs and the node tree stays the same, the inferencing only has to
happen once, instead of on every redraw.
The main difficulty with this cache is that we don't have a good way to
invalidate it eagerly when any of the modifier inputs changes. That can
hopefully become simpler with #138117. For now, we have to check all input
values on redraw to check if anything has changed compared to the last redraw
and recompute the cache if there is any change.
Pull Request: https://projects.blender.org/blender/blender/pulls/147930
I think the special handling for string input node, added in #139478,
was broken by #146033. The early check for src_value (`if (!src_value)`)
caused the string-specific logic to be skipped. This PR moves the
string-specific handling before the src_value check.
Pull Request: https://projects.blender.org/blender/blender/pulls/147697
This list can be used as a source of truth for what needs to be
supported in CustomData vs. AttributeStorage for some ongoing work.
These comments just make it a bit more useful.
Root cause is, that reverse playback would not call
`BKE_sound_play_scene()`, however `BKE_sound_stop_scene()` was called
always.
There was some weird logic in `ED_screen_animation_play()` where
condition for what sound scene was to be stopped exactly was inverted
for sequencer and duplicated for non-sequencer scene. This may also
be incorrect if somebody manages to start playback in active scene, then
create sequencer scene and stop it there.
Fortunately `ScreenAnimData` keeps pointer to scene which started
playback, so this is used to also stop the playback.
To make this code bit more readable, the function was split into
functions starting and stopping the playback, so the logic can also be
simplified a bit.
Finally, `sound_device_use_end_after()` was modified to do sanity check.
If the number of users is already 0, it does nothing and returns.
There assertion to catch this in debug builds.
Pull Request: https://projects.blender.org/blender/blender/pulls/147613
This patch mixes the alpha channel of the color in the Mix mode of the
Mix node. This has no effect on EEVEE/Cycles since they do not support
alpha, but affects the Compositor, Geometry Nodes, and Texture Nodes.
Previously, the alpha of the first color was assumed, which meant mixing
two images with transparency using a mask in the compositor resulted in
part of the image having bad alpha and required manually mixing of the
alpha channel. And this is the main motivation of this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/146461
This fixes the root cause of #147541. However, the file in the report is still
in a bad shape. It needs to be resaved after this patch so that appending the
node group works as expected.
The issue was that making a data-block local did not clear the
`ID_FLAG_LINKED_AND_PACKED` flag.
Pull Request: https://projects.blender.org/blender/blender/pulls/147603
The issue here was that the node-tree-update code was accessing data in `bmain`
when it shouldn't. The fix is to just use the correct API for this use-case when
updating a temporary node tree. It doesn't need `bmain` in this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/147611
On its own this change is just noise and not really worth it. The point
is to make a future diff for #122398 smaller and more legible. Also it's
semantically more consistent with the way we usually handle early
returns: the "special case" comes first, then the expected normal path
continues un-indented.
The fix in this case is to properly use the stored builtin attribute defaults
when capturing the field on the mesh. I extracted that to a function so
the code would read better with early returns.
Pull Request: https://projects.blender.org/blender/blender/pulls/147646
Code executing in parallelized context should never attempt to resync
viewlayers, this is just not safe.
So instead, explicitly call `BKE_main_view_layers_synced_ensure` and
forbid further updates before entering the multi-threaded part of
`BKE_lib_override_library_main_operations_create`.
This should make issues like #147565 less likely to happen in the
future.
`BKE_view_layer_synced_ensure` would report success and clear the 'out
of sync' flag of the viewlayer, even if the call to `BKE_layer_collection_sync`
could not actually perform the resync (e.g. because resync is forbidden
by one or more calls to `BKE_layer_collection_resync_forbid`).
While logically fairly bad, this issue did not seem to have any
practical consequences. So would rather not backport this to the 5.0 beta
branch.
This fix also reveals at least one place where the usage of
`BKE_view_layer_synced_ensure` and related is muddy and not ideal: the
Scene's `foreach_id' code. This is patched as best as possible in this
commit, but is something that will have to be properly fixed at some
point most likely.
Also add some documentation to this API - although the whole thing needs
a real reafctor at some point still, name-wise and organization-wise.
Pull Request: https://projects.blender.org/blender/blender/pulls/147635
Support loops at the GLSL level instead of relying on
NOD_shader_nodes_inline.
This improves compilation and runtime performance, avoids causing
recompilations on iteration count changes, and allows supporting
dynamic iteration counts.
(EEVEE-only)
Pull Request: https://projects.blender.org/blender/blender/pulls/145269
