Changes to an extensions manifest weren't accounted for.
This was particularly a problem for "System" extensions which aren't
intended to be managed inside Blender however the problem existed for
any changes made outside of Blender.
Now enabled extensions are checked on startup to ensure:
- They are compatible with Blender.
- The Python wheels are synchronized.
Resolves#123645.
Details:
- Any extension incompatibilities prevent the add-on being enabled
with a message printing the reason for it being disabled.
- Incompatible add-ons are kept enabled in the preferences to avoid
loosing their own preferences and allow for an upgrade to restore
compatibility.
- To avoid slowing down Blender's startup:
- Checks are skipped when no extensions are enabled
(as is the case for `--factory-startup` & running tests).
- Compatibility data is cached so in common case,
the cache is loaded and all enabled extensions `stat` their
manifests to detect changes without having to parse them.
- The cache is re-generated if any extensions change or the
Blender/Python version changes.
- Compatibility data is updated:
- On startup (when needed).
- On an explicit "Refresh Local"
(mainly for developers who may edit the manifest).
- When refreshing extensions after install/uninstall etc.
since an incompatible extensions may become compatible
after an update.
- When reloading preferences.
- Additional info is shown when the `--debug-python` is enabled,
if there are ever issues with the extension compatibility cache
generation not working as expected.
- The behavior for Python wheels has changed so they are only setup
when the extension is enabled. This was done to simplify startup
checks and has the benefit that an installed but disabled extension
never runs code - as the ability to install wheels means it could
have been imported from other scripts. It also means users can disable
an extension to avoid wheel version conflicts.
This does add the complication however that enabling add-on which is
an extension must first ensure it's wheels are setup.
See `addon_utils.extensions_refresh(..)`.
See code-comments for further details.
This was caused by the denoiser of the slight out of focus
pass having too much influence at low CoC values.
Making the transition start at 0.5 fixes the issue.
Fixes#123822
This happened in scenes with high light count and
with some local light being culled.
The culled lights indices would still be processed
and load undefined data. This undefined data
might be interpreted as a sunlight and go into
the cascade setup loop with an undefined number
of levels.
This created loops of 1 billion iteration per thread
which triggered the TDR on windows.
The fix is to skip the culled light indices.
Fixes#123413Fixes#123190
This writes the `init_time` curve attribute and the `delta_time`
point attribute.
These are used by the build modifier in the "natural drawing speed"
mode to mimic the actual speed at which the stroke was drawn.
Pull Request: https://projects.blender.org/blender/blender/pulls/123899
The new brushes don't update `SculptSession::orig_cos` (which is good, it's
not necessary since it's just a copy of the active shape key data or the original
mesh's vertex positions). To fix the problem with the undo system, access those
two arrays directly instead. Once all the uses of the "proxy" system are removed,
`orig_cos` can be removed too.
Pull Request: https://projects.blender.org/blender/blender/pulls/123922
Avoid copying positions and normals from their source arrays. This is
simplified by using separate loops for the original data and accumulate
cases. I observed a performance improvement in the typical benchmark file
of about 13%, from 0.54s to 0.48s for a brush stroke affecting most of a
6 million vertex grid.
Avoid the need to acess mesh data for every node which will become more
important if we decide to make nodes smaller. Also makes some possible
performance improvements simpler.
Part of #118145.
Similar to 851505752f.
This doesn't affect performance much at all, the vast majority of time
in typical scenarios is spent modifying topology anyway. It does significantly
ease development though, because now we can just do slight modifications
on the "new" version of brush code instead also creating a refactored "old"
version.
This fixes a kernel crash on NVidia GP100.
This splits the tilemap finalize shader into another shader
and split the valid tile gather into its own loop.
Simplifying the shader seems to avoid the issue. But the
cause of the issue remains unknown.
Pull Request: https://projects.blender.org/blender/blender/pulls/123850
When preview is downscaled and transformation origin is not the center
of the image, this causes unexpected offset. This happened, because one
matrix combined image downscaling, so it fits into preview and user
defined scale. When origin was not center of the image, this results in
incorrect offset.
Solved by splitting 1 matrix in `sequencer_image_crop_transform_matrix`
into 2 matrices. First matrix just centers and scales image to expected
size. Second matrix performs rest of transform operations. This code is
bit easier to read as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/123776
Delete operator was shared for strips and retiming keys, which was not
ideal. Operator logic relied on invoke function setting proper context
which was also hidden from users.
Split these operators and make dedicated operators for removing retiming
keys - `SEQUENCER_OT_retiming_key_delete`.
This operator returns `OPERATOR_CANCELLED | OPERATOR_PASS_THROUGH` if
executed in non-retiming context, or no key is selected.
Pull Request: https://projects.blender.org/blender/blender/pulls/123767
No need for an additional view item button lookup when the context menu
is built for that button itself. Only do a lookup if the context menu is
built for a button drawn on top of the view item button.
Caused by floating point error in `BLI_rctf_transform_pt_v()`
The error is not fixed, but intead of recalculating each strip offset
with this function, only offset for {0, 0} is calculated and added to
easch strip.
Pull Request: https://projects.blender.org/blender/blender/pulls/123825
So far the brush refactors haven't affected the multires implementations
much. Besides replacing the vertex iteration macro they are fundamentally
the same. This commit refactors the multires implementations to use the
same structure as the base mesh code. The motivations are improving CPU
cache use, removing constant checks from hot loops, and allowing use of
SIMD. This generally works by gathering the AoS multires format into
local arrays.
Quite a few brush evaluation functions have been duplicated to work on
non-indexed data. This will be necessary as we start to handle brushes
that use original data anyway. I don't think this duplication is very
bad though; since the functions are right next to each other it's easy
to change them at the same time. In the future we might investigate
gathering data into local arrays for the mesh implementations too.
In the brush benchmark file from #118145, this improved brush evaluation
performance by roughly 15%, mostly by removing the separate step of
accumulating changes with the proxies system.
Pull Request: https://projects.blender.org/blender/blender/pulls/123703
The code which is responsible for applying data from coordinate grids to
displacement grids could be run as part of modifier evaluation, hence
using the safe version of accessing mesh data was returning a nullptr.
Pull Request: https://projects.blender.org/blender/blender/pulls/123907
The GPU compositor frees some of the cached resources when it gets
canceled during interactive editing, making the experience less smooth.
This is because when the compositor gets canceled mid-evaluation, some
of the operations won't get the chance to mark their used resources as
still in use.
To fix this, we skip the cache manager reset after canceling,
effectively only resetting when a full evaluation happens, giving all
operations the chance to keep their cached resources.
Pull Request: https://projects.blender.org/blender/blender/pulls/123886
Linked images that share the same name as an image in the file will fail
to load in the GPU compositor. That's because cached resources are keyed
using only their ID name, while they should also be keyed by the library
name.
Pull Request: https://projects.blender.org/blender/blender/pulls/123898
Remove the `pbvh_colors.cc` file, since dealing with color attributes should
generally not be the responsibility of the PBVH. Move the color API functions
to the `color` namespace, replacing the two existing `SCULPT_color`
functions. Also replace `SCULPT_has_colors` and `SCULPT_has_loop_colors`
which are redundant with checking the easily accessible attributes directly.
Remove `PBVH::color_layer`, `PBVH::color_domain`, and remove `vcol`, `mcol`,
`vcol_domain`, and `vcol_type` from `SculptSession`. Instead, retrieve attributes
and other arrays from the mesh as necessary and pass them around separately.
This adds more arguments to some functions but it makes their responsibilities
clearer.
Part of #118145.
Use vertex indices instead of `PBVHVertRef`. This doesn't lose functionality
because color attribute painting is only supported for base meshes anyway.
The next steps are refactoring the code to have the same structure as the
new brushes and using the same methods to add code paths for the other
data structures.
This patch adds two theme entries for data before/after the current frame.
Those entries control what color to use when displaying
reference data from a different point in time (motion path, onion skins).
They are under the `3D Viewport` section of the theme in the user preferences.
## User Facing Changes
### Grease Pencil
When `Custom Colors` is disabled it will now use the theme instead of the layer default color.
Currently this setting is enabled by default. Disable it to get Blender to use the theme.
### Motion Path
If Custom Color is disabled, read from the Theme.
### Annotations
If onion skin is enabled, and custom onion skin colors is disabled, read from the theme.
**Grease Pencil**
* previously the color used for onion skinning (without custom colors) was `U.gpencil_new_layer_col`. This is used in other places as well so it cannot be removed with this PR
* By default, custom colors are enabled with Grease Pencil objects. I specifically did **not** change that with this PR. I will instead let the GP module handle that on their terms.
This PR has been discussed in the Grease Pencil module meeting
https://devtalk.blender.org/t/2024-05-21-grease-pencil-module-meeting/34755#meeting-notes-2
and in the A&R module meeting
https://devtalk.blender.org/t/2024-05-24-animation-rigging-module-meeting/34813#patches-review-decision-time-4
Pull Request: https://projects.blender.org/blender/blender/pulls/120558
Keep track of which IDs are animated by which Action Binding. This will
be necessary for display in the Action editor, where animation data that
is unrelated to the active object can be shown (when "show all bindings"
is on).
Note: animation evaluation will not be using this cache, at least not in
the near future. Potentially when we introduce animation-level
constraints this will change, but that's for the future.
The user cache isn't actually used in this commit. It will be used soon
in !122672.
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
Add a function to get the `Main *bmain` pointer from a
LibraryForeachIDData struct. Since the struct is opaque to the
`..._foreach_id` functions, a separate function like this is necessary
to get that pointer.
Not used yet, but will be in a followup commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
Pass a non-`nullptr` `bmain` to `BKE_library_foreach_ID_link()` wherever
that `bmain` is known at the call site. This will be used in a followup
commit.
This should not introduce any functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123187
This was the case when the slot index in the active object is greater
than the available slots of other selected objects.
Code was trying to avoid searching all materials by using
`BKE_object_material_get` to get an appropriate index (an addition to
D4441 added in 6b39dc7672). That function has the behavior of clamping
if a target index is greater than the available slots (for good
reasons), so we cant rely on the slot index being the same if
`BKE_object_material_get` finds a material. So in essence, this is not
what we want to use in this case.
Now use the much simpler `BKE_object_material_index_get` to get the
index [this might be less performant in certain scenarios, dont think
this is critical though and correctness should beat performance here]
Pull Request: https://projects.blender.org/blender/blender/pulls/123718
When copying the depth aspect of a depth+stencil image the incorrect
barriers where created. The barrier needs to have the full aspect, even
when we only copy a single aspect from the image.
Pull Request: https://projects.blender.org/blender/blender/pulls/123890
