Blender doesn't render the scene even though a Cryptomatte node exists.
That's because Blender only considers Render Layer nodes, but
Cryptomatte node can reference scenes as well. This patch fixes that by
putting Cryptomatte nodes into consideration.
Pull Request: https://projects.blender.org/blender/blender/pulls/123814
The 'Filter' F-Curve modifier type was never actually implemented, so
it's now properly removed from the code.
The enum entry `FMODIFIER_TYPE_FILTER` in `DNA_anim_types.h` is kept, so
that it's clear that this once existed (which explains what would
otherwise be a hole in the values of the enum entries).
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Avoid looping over all F-Curves in `bke::action_foreach_id()`. This was
only necessary to support the possible ID* in custom properties on the
Python F-Curve modifier, but that modifier has been removed in the
preceeding commit.
Even though `BKE_fcurve_foreach_id()` exists, it is only relevant for
drivers, but the F-Curves stored in an Action are always just animation
data, not drivers.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Remove all traces in the source code of the never-properly-implemented
'Python' F-Curve modifier type. It was introduced in 44e5b7788b.
This modifier was never coded to completion, couldn't be created, didn't
have a GUI, and probably would have caused severe performance issues if
it were ever implemented.
Not only that, but the modifier had space for custom properties
(IDProperties), which means that it could point to any ID. This in turn
means that `bke::action_foreach_id()` would have to loop over every
F-Curve and every F-Curve modifier to handle such relations. By removing
this modifier type, that loop can also be removed from that function.
Note that F-Curves can only refer to other IDs when they are used as a
driver. However, the F-Curves stored in an Action as animation data are
never drivers.
`BKE_fcurve_foreach_id()` is now only relevant when the F-Curve is a
driver, which I've added to its documentation.
The enum entry `FMODIFIER_TYPE_FILTER` in `DNA_anim_types.h` is kept, so
that it's clear that this once existed (which explains what would
otherwise be a hole in the values of the enum entries).
No functional changes should be observable by Blender users, as this
feature doesn't seem to have ever existed in a way that could be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Instead of using hard-coded array indices that happen to match the
`FMODIFIER_TYPE_...` enum values, actually use the enum items.
Also add some assertions that those indices actually match the type
numbers declared by the `FModifierTypeInfo` structs.
To avoid rewrapping long lines, remove comments that basically repeat
the code anyway.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123906
Currently, the Render mode of the GPU Cryptomatte mode extracts the
Cryptomatte layers based on information in the RenderResult of the
scene. This means the node will not work if no RenderResult exists,
which is typically the case for the viewport compositor, and especially
after #123378.
To fix this, we simply acquire the passes directly from the appropriate
view layer based on the node's layer name. The render compositor context
implementation will handle the extraction from the RenderResult, while
the viewport compositor will just return the DRW passes.
Pull Request: https://projects.blender.org/blender/blender/pulls/123817
Extensions with a manifest that can't be parsed caused can exception
in the add-ons UI.
Account for errors loading the manifest, falling back to dummy values
& show a warning that the exceptions manifest could not be parsed.
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
