This fixes a bug that happens when two drawings in the same grease pencil
data-block reference the same array. In this case, the same attribute array
pointer is written to .blend files for both drawings. However, when loading the
.blend file, it was not detected that the data is shared. Instead each drawing
would think that it was the single owner of the array even though it was shared.
The same problem can technically occur for all kinds of shared data, and not
just for grease pencil. However, only grease pencil shows this issue currently,
because it can easily happen that the same attribute is shared between different
`CustomData` within the same data-block. This very rarely happens with meshes or
curves, because different `CustomData` usually have different sizes and don't
share the same arrays.
A previous fix (cc891aa699) solved pretty much the same issues for the case
when two layers in the same `CustomData` share data. This original fix is now
generalized and is integrated with `BLO_read_shared` which makes it less error
prone. For each data-block, the `BlendDataReader` now remembers which shared
data it has loaded before so that it is not loaded again.
In the future this could be extended to support data that is shared between
data-blocks, but that's not as straight forward as one would hope currently. For
various reasons, different data-blocks could store independent data at the same
pointer. I specifically noticed that with a regression test file:
`blender/tests/data/modeling/geometry_nodes/attributes/attribute_statistics.blend`.
To support it, one solution could be to tag `BHead` in .blend files to indicate
that a specific pointer is shared and unique within the entire file. But that's
for another day.
Pull Request: https://projects.blender.org/blender/blender/pulls/122780
The buttons to upgrade or sync extensions called extension
operators via bpy.app.handlers, requiring awkward glue-code
which didn't show error reports in to the user.
Remove these operators and call the upgrade & sync operators directly.
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
Update PBVH GPU argument initialization to prefer using the PBVH mesh
attributes instead of the evaluated mesh attributes for color.
The values can be out of sync due to differences with the evaluated
and original mesh data.
Pull Request: https://projects.blender.org/blender/blender/pulls/122850
Originally this would replace scripts that come bundled with Blender,
but it's unclear how this is useful.
Searching for this online mainly leads to people asking how they can
use it to add scripts. For example in a studio environment you might
want to deploy add-ons and startup scripts for all users.
Even if you wanted to use it for replacement though, it wasn't really
doing that and inconsistent for different types of scripts:
* startup: ignored
* modules: replaces bundled scripts
* presets: adds to bundled scripts
* addons (in 4.1): ignored
* addons_core (in 4.2): ignored
* startup/bl_app_templates_system: replaces bundled scripts
This change makes it add scripts from this path for all. This is a
breaking change, though arguably this feature was just broken to
begin with and not used much in practice because of that.
The alternative would be add a new set of environment variables to
avoid breaking existing behavior. But that also means keeping around the
broken behavior or fixing it in another way.
Supporting multiple paths may be used too, but for now just support
a single one as doing this for all BLENDER_SYSTEM variables is
non-trivial. The main use case for that would be add-ons anyway, and
those will mainly be handled through upcoming
BLENDER_SYSTEM_EXTENSIONS instead.
Ref #122512
Pull Request: https://projects.blender.org/blender/blender/pulls/122689
Seems to be dependent on specific compiler/cmake version.
Is a typical mixture of missing dependencies between libraries,
object files which do not get referenced from other files in the
target, and whole-archive linking of the blender_test target.
Pull Request: https://projects.blender.org/blender/blender/pulls/122801
The code for recalculating bounds was fairly tricky to understand, with a
mixture of various flags, a mixture of recursive and parallel code, and
the "original bounds" concept.
This commit separates that update code into two separate paths. The regular
bounds update is split from the resetting of original bounds, which is only
needed in a few places and is best described by a separate function call.
The bounds update itself is split clearly into a parallel update of leaf node
bounds and a recursive merging of child node bounds.
The high level goals this helps to support are:
1. Use data-oriented storage to replace PBVHNode struct.
2. Document concepts like "original bounds", provide a self-descriptive API.
3. Allow brushes to update bounds themselves, for better CPU cache use.
Pull Request: https://projects.blender.org/blender/blender/pulls/122746
There is a mechanism to store config files in the same folder as the
Blender executable. The typical use case is putting Blender on a USB
drive and taking the config with you.
However the problem is that this is using the 4.2/ folder, which is fine
for config/ but with e.g. addons, studiolights and now extensions this
is mixing user and system files. This requires exceptions, doesn't
work well in some cases and is just generally not great design.
Instead use a folder named portable/ that is separate.
Pull Request: https://projects.blender.org/blender/blender/pulls/122778
Previously, the "Simplify" option was a world space distance threshold.
This meant that zooming in and out of the view changed the way
this option behaved. There were complaints from artists about this.
This change improves two things:
* The simplify algorithm uses the screen space coordinates rather than the
3D positions.
* The UI setting is in pixels making it much easier to tweak (no need
for values in the 1e-4 range).
Pull Request: https://projects.blender.org/blender/blender/pulls/122719
In GPv2 the brush strength was it's own setting in the
`brush->gpencil_settings`. Now we just use the `brush->alpha`
like all other brushes.
Note: The versioning will be done when GPv3 becomes the default.
Pull Request: https://projects.blender.org/blender/blender/pulls/122565
The Film-like curve mapping option in the RGB Curves node in the
compositor produces bad results when editing its RGB curves. That's
because Film-like curve mapping only works with the combined curve by
definition, since it is a hue preserving mapping. Furthermore, the
Film-like option ignored the white balancing step altogether.
To fix this, we hide the current curve option for the File-like option
and only allow editing the combined curve, handing the same case for
versioning and RNA updates. Further, we port the implementation from the
realtime compositor which is both correct and takes white balancing into
account.
Pull Request: https://projects.blender.org/blender/blender/pulls/122762
This patch implements blue-noise dithered sampling as described by Nathan Vegdahl (https://psychopath.io/post/2022_07_24_owen_scrambling_based_dithered_blue_noise_sampling), which in turn is based on "Screen-Space Blue-Noise Diffusion of Monte Carlo Sampling Error via Hierarchical Ordering of Pixels"(https://repository.kaust.edu.sa/items/1269ae24-2596-400b-a839-e54486033a93).
The basic idea is simple: Instead of generating independent sequences for each pixel by scrambling them, we use a single sequence for the entire image, with each pixel getting one chunk of the samples. The ordering across pixels is determined by hierarchical scrambling of the pixel's position along a space-filling curve, which ends up being pretty much the same operation as already used for the underlying sequence.
This results in a more high-frequency noise distribution, which appears smoother despite not being less noisy overall.
The main limitation at the moment is that the improvement is only clear if the full sample amount is used per pixel, so interactive preview rendering and adaptive sampling will not receive the benefit. One exception to this is that when using the new "Automatic" setting, the first sample in interactive rendering will also be blue-noise-distributed.
The sampling mode option is now exposed in the UI, with the three options being Blue Noise (the new mode), Classic (the previous Tabulated Sobol method) and the new default, Automatic (blue noise, with the additional property of ensuring the first sample is also blue-noise-distributed in interactive rendering). When debug mode is enabled, additional options appear, such as Sobol-Burley.
Note that the scrambling distance option is not compatible with the blue-noise pattern.
Pull Request: https://projects.blender.org/blender/blender/pulls/118479
PBVH_UpdateRedraw was always combined with PBVH_UpdateBB.
The use for the "redraw update" isn't clear anyway, since there are
more specific tags for everything that would require a redraw.
This handles the transition to EEVEE-Next (now EEVEE).
This removes some things that make no sense to keep
even for compatibility.
- Scene.eevee.light_cache_data
- Scene Light cache operators
- Scene Light cache RNA properties
The remaining legacy properties will be removed later
on to avoid python API breakage.
We keep the identifier of EEVEE-Next as `BLENDER_EEVEE_NEXT`
to avoid addons being incorrectly silently made compatible
with the EEVEE-Next where the Python API is different.
This renaming should be done in 5.0 release.
Thank you EEVEE-Legacy, you served us well.
Pull Request: https://projects.blender.org/blender/blender/pulls/122433
This commit changes how users can interact with handles:
Unselected handles are not drawn anymore by default. Handles are bit
thinner. If handle can't be selected, because strip is too small,
it is not drawn.
When hovering over strip handle a cursor is changed to represent a
handle shape. It is possible to select 2 handles at once if strips are
adjoined.
When tweak event happens on unselected handle, handle selection is lost
ater tweaking.
This behavior can be disabled in preferences:
Editing > Video Sequencer > Tweak Handles.
Moving strips with G key works same way as before.
Pull Request: https://projects.blender.org/blender/blender/pulls/109522
By capturing multiple attributes with one node, the user can make sure that those
are evaluated together in the same context. This can be quite a bit more efficient
compared to capturing multiple fields separately (also because we don't optimize
grouping multiple capture nodes together yet).
The change is fully backward compatible. Forward compatibility has been added
for some cases. Especially, files created in older versions that are saved with this
newer version will still work in the older version.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/121665
This ports the `lock_material` layer property to GPv3.
For this, the `layer_index` is also required in `retrieve_editable_points`
and `retrieve_editable_strokes` to choose strokes based on
the `lock_material` property.
In `retrieve_editable_elements` we now pass the `MutableDrawingInfo`
to get both the `drawing` and `layer_index`.
Pull Request: https://projects.blender.org/blender/blender/pulls/119913
Move extension update display from the splash screen to the status bar.
Based on !122413 with minor changes & removal of splash text.
Co-authored-by: Harley Acheson <harley.acheson@gmail.com>
Move the bounding box synchronization to the geometry evaluation component.
This way it is ensured that it is only done when the geometry is actually
evaluated, solving the problem of accessing stale data when object level
flags are modified.
Pull Request: https://projects.blender.org/blender/blender/pulls/122509
