The sample distribution was biased toward 0, which
created sharper details than expected.
However the downside is that the subsurface is now
more jittery because of the low amount of samples.
As an initial step to creating automated regression tests for sculpt brushes,
make our existing performance test script into an automated performance
test. The test uses the brush active in each file and runs the brush stroke
operator on a large generated grid. The time is just for the brush evaluation,
it doesn't include building the PBVH, drawing, etc.
I'm not sure about the consequences of conditionally disabling
`view3d_operator_needs_opengl`, but it was needed to make the test
work in background mode.
Pull Request: https://projects.blender.org/blender/blender/pulls/123148
Setting this option to a value above zero replaces the lambertian Diffuse term
with the modified energy-preserving Oren-Nayar BSDF, which matches the OpenPBR
behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/123616
This replaces the usage of the old `BKE_blendfile_write_partial` API by
the new `PartialWriteContext` class, in the code generating the 'copy
buffer' blendfile used for copy-pasting video sequences.
This is an interesting example of advanced/complex ID dependencies
handling with the new `PartialWriteContext`, as the 'main. scene storing
VSE data needs to be created (instead of copying the existing scene),
and then the ID dependencies of its sequences need to be filtered based
on their types.
There is no behavioral changes expected here.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
Pull Request: https://projects.blender.org/blender/blender/pulls/123993
This makes code behind the `bpy.data.libraries.write()` API use the new
`PartialWriteContext` class, instead of the old
`BKE_blendfile_write_partial` API.
NOTE: This also means that the `blendfile_io` tests using this python
API are now using the new class.
No behavioral changes are expected here.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This commit introduces a new `PartialWriteContext` class, which wraps
around a regular Main struct. It is designed to make writing a set of
IDs easy and safe, and to prepare for future 'asset library editing'
low-level code.
The main goal of this refactor is to provide the same functionalities
(or better ones) than existing partial write code, without the very
bad hacks currently done.
It will replace within the coming weeks all current usages of the
`BKE_blendfile_write_partial` API.
Essentially, it allows to:
* Add (aka copy) IDs from the G_MAIN to the partial write context.
* This process handles dependencies and libraries automatically.
* A refined handling of dependencies is possible through an optional
'filtering' callback.
* Keep track of added IDs, to allow de-duplication in case data is added
more than once.
* Cleanup the context (i.e. remove unused IDs).
* Write the context to disk as a blendfile.
Since the context keeps information to find matches between its content
and IDs from the G_MAIN, its lifespan is expected to be _very_ short.
Otherwise, changes in G_MAIN (relationships between IDs, their session uid,
etc.) cannot be tracked by the context, leading to inconsistencies.
A partial write context should typically be created, filled, written and
deleted within a same function.
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
Also make ID pointer parameter passed to `BKE_main_idmap_remove_id`
const.
There is no behavioral changes expected from that commit.
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This commit allows to initialize and clear a Main struct which
allocation is handled separately.
There is no behavioral change expected from this commit.
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
The new `LIB_ID_MAKELOCAL_INDIRECT` option will force indirectly linked
data to also be made local. Note that this was already the case when a
whole library was made local.
Also some cleanup of options for 'make local', and pass
`IDWALK_IGNORE_MISSING_OWNER_ID` to the ID copying code for ID
management, since typically the owner pointer of embedded IDs at that
point is not yet set to its valid value.
There is no behavioral changes expected from this commit (even though
technically it does affect existing ID copying's behavior, there should
be no change in practice).
This is a requirement for incoming rewrite of the PartialWrite code
(see #122061 and !122118).
Pull Request: https://projects.blender.org/blender/blender/pulls/122118
This was caused by the light culling system not
allocating enough tiles to cover the sphere lightprobe
render target.
Taking the max size between the lightprobe target and
the film fixes the issue.
Fixes#117444
Part of #118145.
Duplicate the function three times so it can be implemented specifically
for each data structure. The duplication can be reduced in the future by
using the same methods as the sculpt brush refactor.
This also fixes the incorrect usage of `PBVH_ITER_ALL`, which doesn't
just also iterate over hidden vertices like was probably intended, but also
processes vertices shared between different PBVH nodes multiple times,
one for each node they're contained in.
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
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
