Mesh filter modes that use averaged neighbor data were not passing in
the mesh `hide_poly` attribute data, leading to incorrect behavior when
calculating averaged positions. To fix this and account for hidden
elements since we are operating on the entire mesh, we pass in the
attribute and use the `neighbor_data_average_mesh_check_loose` method to
account for vertices with no neighbors.
Pull Request: https://projects.blender.org/blender/blender/pulls/129886
No idea why this was not reported before... Kind of critical info here.
Committed directly to 4.2 as:
* This is trivial change with extremely small risk of causing issues.
* Gold team at the studio needs it to better cleanup the production
files for publication.
Follow what was already done with the "reload" operator and tag the
Image ID during "replace".
A tag of "0" is used for now until we can investigate why the other more
appropriate values are not working.
Pull Request: https://projects.blender.org/blender/blender/pulls/129619
The label was hidden explicitly when saving changes wouldn't be
possible. But this was done for an earlier design iteration where there
would be a button to save changes, not just a label as indicator. The
indicator should always be shown when applicable.
This would happen if the viewport with large enough
and a tile resolution of 1:1 was choosen.
This changes the fallback behavior from simply clamping
the resolution (which did break a lot of math downstream),
to simply finding the next largest tile size that fits
the hardware requirements.
Crash manifested after the inclusion of #128877.
The very tall 3D texture tested by the new code
were not supported / tested by the Metal Backend.
Simply adding the appropriate upfront checks fixes
the issue.
Needs to be backported to 4.2
Adding a dummy storage buffer to the classification shader
seems to fix the issue on Qualcomm drivers (WoA).
The workaround is added to the force workaround option to
allow other platforms to test the fix.
Rel #122837
Pull Request: https://projects.blender.org/blender/blender/pulls/129857
Code used library reloading which would reload all data-blocks from a
data-block library. Since the essentials brushes are stored in a single
.blend file (one per mode), they would all be reset. In general this
violates the design where multiple brushes in a single .blend file
should be usable just fine. (A single file per brush is only necessary
to allow saving edits to that file without opening it.)
Instead of library reloading, delete the brush from the current file and
re-link it.
The link/append API should probably get support for reloading a single
data-block (and optionally its dependencies) but for now this is not
supported yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/129866
Some modifiers expect the curves to be of type `POLY`.
For such modifiers we need to resample the curves to the
evaluated points so that the modifiers work as expected.
Resolves#129859.
Pull Request: https://projects.blender.org/blender/blender/pulls/129860
The issue was that with a96f1208cc the clamping
of the `View2D` happened in the drawing function
of the channel list. That of course won't work if the
channel list isn't drawn.
The fix is to ALSO clamp in the drawing function of
the main area. The reason this has to be in addition, is that
(I think) the channel box is drawn first. So if the clamping doesn't
happen there, the channels and their keys can lose their vertical
alignment.
Pull Request: https://projects.blender.org/blender/blender/pulls/129864
Armature::collection_array was indexed with -1,
returning an invalid collection.
When the collection index isn't usable, create a new collection
with the default name.
Ref !129608
This reverts commit 0a70360eb69fb67b5ca4b6488b79edc507bf1417. That's
because it caused issue #129366 which is much more serious, and the
cause is not obvious so far. Another fix will be submitted for the
original issue.
When using AMD official driver clearing depth attachments can fail.
I assume it is related to previous pipeline states and dynamic rendering
that don't require the correct pipeline state for clearing depth
attachments.

Co-authored-by: jeroen@blender.org <Jeroen Bakker>
Pull Request: https://projects.blender.org/blender/blender/pulls/129852
This was likely never an issue so far, as no ID type has ever been
removed (that was written in blendfiles at least), and no new BHead type
has been added since ages.
However, current behavior of the main loop in the readfile code (in
`blo_read_file_internal`) is to consider any BHead type which is not
explicitely known and handled, to be an ID BHead, and directly try to
load it as such.
This commit addresses that potential issue by validating that a BHead
code actually matches a known ID type before trying to use it to read an
ID from the file.
Issue identified while working on designs for future 5.0 forward
compatibility breaking changes in blendfile format itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/129693
Missing in db1443249c.
Need to tag positions as changed.
Also send `ND_DRAW` notifier to be sure we fully redraw (makes e.g.
gizmos update accordingly as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/129848
Previously the `W` menu was only available for brush tools (brush and
eraser), it should be available to all tools, thus putting the key map
registering function into `km_grease_pencil_paint_mode`.
Pull Request: https://projects.blender.org/blender/blender/pulls/129837
The sample index node specifies the supported geometry types and Grease
Pencil was missing. Note that only the layer domain will work since it's
the only domain accessible by index on GP data directly.
Pull Request: https://projects.blender.org/blender/blender/pulls/129758
When doing action baking, the option "Clear Constraints" mentions
it's doing visual keying while not actually using that option.
Just fixing the description, even though a better solution
would be to revisit the design of the options to see if they
even make sense in some configurations.
Pull Request: https://projects.blender.org/blender/blender/pulls/129052
The issue is that the action line may be there, but containing no action,
`bAnimListElem->data` pointer is a nullptr.
caused by b952782a44
In this refactor the function call was changed from
`BKE_action_frame_range_get` which could handle
the case of a nullptr passed to it.
Pull Request: https://projects.blender.org/blender/blender/pulls/129648
Vulkan backend selection will be hidden behind developer extras. There
are some issues which would not be inviting for users to start testing.
- Some basic functionality are not working (object selection, depth
testing)
- NVIDIA UI artifacts are annoying and unsure where the error is.
- AMD artifacts
- Memory leaks
The backend will still be part of Blender 4.3 only hidden behind an
additional flag.
Ref: #129265, #129262, #127225, #128624, #127768, #127223
Pull Request: https://projects.blender.org/blender/blender/pulls/129799
Qualcomm driver can not handle the optimized SPIR-V that Blender
creates. According to their driver engineers this is an issue in
shaderc. As we are late in the release process they asked us to disable
the optimizations.
In Blender 4.4 we are planning to update shaderc what might fix the
issue. This should be retested after the update.
Pull Request: https://projects.blender.org/blender/blender/pulls/129775
RNA update function called from `rna_property_override_apply_default`
does not have access to active `Scene`, so it is explicitly set to null.
Use `ptr->owner_id` instead of scene provided in argument.
Pull Request: https://projects.blender.org/blender/blender/pulls/129562
Interpolating these attributes as integer values isn't meaningful or
helpful and is potentially problematic. So far I'd guess this is unlikely
to happen in practice which is why it probably hasn't been noticed yet.
Fixes part of #129691.
Pull Request: https://projects.blender.org/blender/blender/pulls/129809
When using the Voxel Remesh operator, there are two possible sources of
crashes currently:
* TBB task stealing in nested parallel loops with thread local data
* Null dereference of PBVH data when pushing sculpt undo steps
To fix the former issue, this commit guards the
`threading::parallel_for` internal function with
`threading::isolate_task` to prevent possible task stealing and
corruption of the thread local data.
Additionally, it has the effect of fixing debug asserts inside
`array_utils::gather` due to the this task stealing.
To fix the latter issue, this commit adds a call to
`BKE_sculpt_update_object_for_edit` to ensure that this data is
populated.
Pull Request: https://projects.blender.org/blender/blender/pulls/129704
The issue is caused by the new way to compute the projection
matrix that tries to recreate it from view3d properties.
This is needed for proper overscan support.
However, this breaks for VR as the view3d is only partially
setup.
Skip the setup in VR and remove overscan for VR to avoid any
possible issues with it.
This fix avoid changing the behavior of the
`ED_view3d_draw_offscreen` which is exposed from our pyGPU
API. The pyGPU API is kind of broken if using custom
projection matrix + overscan, but that's a different issue.
Fix#125456
Pull Request: https://projects.blender.org/blender/blender/pulls/129813
Using array_utils::gather inside an already parallel context with TLS
variables has the possibility of causing data corruption due to task
stealing.
This commit changes them to the sculpt specific gather_mesh_data call
to avoid the nested parallel loop issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/129770
Don't try to use MetalRT by default unless the device explicitly reports that RT is supported. We shouldn't just rely on an assumption that it's supported for M3 and beyond, ad infinitum.
Pull Request: https://projects.blender.org/blender/blender/pulls/129688
This was caused by uninitialized values at border. The correct
number of bricks were reserved but only the unpadded volume
was uploaded. Which was not touching the data of the border
bricks if the size was divisible by `IRRADIANCE_GRID_BRICK_SIZE - 1`.
Fix#127215
Pull Request: https://projects.blender.org/blender/blender/pulls/129810
In the Dope Sheet, show regular keyframes for GreasePencil object data.
The GPv3 transition missed a few cases in the animation
channel/filtering code to add the channels from regular Actions on
GreasePencil data blocks.
Pull Request: https://projects.blender.org/blender/blender/pulls/129807
First issue is that `BKE_modifiers_uses_armature` wasnt working for GP
objects and the second one is that vgroup names are stored in
CurvesGeometry for GP (so that needs special handling, now done, same as
in `BKE_object_defgroup_set_name`).
Pull Request: https://projects.blender.org/blender/blender/pulls/129794
Accidentally added in d70b10dcd4 and moved in dc652aeedb89, the
`GREASE_PENCIL_OT_stroke_trim` operator is meant for usage in draw mode
(as the Cutter tool), but not in editmode. It is not the same as the
GPv2 Trim operator, see 4fbef3dc6b9b63da30188e84fc222a27d6ac64f4
To resolve, remove this from the menu again.
Pull Request: https://projects.blender.org/blender/blender/pulls/129805