When the tool settings or asset shelf header would draw with some
transparency, the separator line between regions would visibly overlap
the background behind buttons, which looked unpolished. Ensure there is
no overlap (but also no gap, which became visible after accounting for
the separator line in the background drawing).
Flickering caused by in-flight SSBO data
overwrites has been resolved by ensuring
data updates go into a new buffer while
existing data is in flight.
GPU_finish has also been removed from
SSBO read due to its frequent mid-frame use
limiting performance.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/113019
The Outliner exposed its context to the header as well which makes some
operators available there. While technically this is all fine, it's a
bit odd to the user, since they don't expect data-editing operations
when right clicking on a header that itself doesn't list data. Instead
only expose the Outliner context in the main region.
Don't assume existence of GPU backend in (background) preview rendering.
Also add null pointer checks and rely on assert instead to detect
invalid usage of GPU_render_begin/end, so that potential future mistakes
don't cause crashes.
Pull Request: https://projects.blender.org/blender/blender/pulls/112971
Add an overview of those bone collections the active/pinned bone is
assigned to.
This overview was originally there, showing the armature layers and the
bone group. This is now replaced by a list of the bone's collections. The
only possible interaction is unassigning the bone & toggling visibility
of the bone collections.
Lattices would give the choice of going to weightpaint mode (which would
fail immediately because of `vwpaint::mode_toggle_poll_test`) because it
was marked as a compatible mode in `ED_object_mode_compat_test`.
I dont think this was ever supported properly, why this was marked as a
compatible mode is unknown (I stopped tracing git history at
deebf4f8f0).
Even if it was at some point, weightpaint mode nowadays is totally
depended on Mesh, so seems better to just remove it from Lattices.
Pull Request: https://projects.blender.org/blender/blender/pulls/112411
The grid was pointer was moved to the next element at every loop, which
made `vi.grid` and `vi.mask` disagree. Instead, iterate the grid before
accessing data, so the pointers agree. To avoid unrolling the first loop
iteration or adding a branch for the first iteration, start the grid at
a -1 offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/113015
The array modifier used to output the start cap even if the
mesh is empty. This behavior was unintentionally changed in
8b2556e8d8. This patch brings back the old behavior.
The use case for this was to load an evaluated mesh of one
object into another object. So it was always kind of a hack, but
there is still no good reason to change the behavior.
Nowadays, one should just use the Object Info node in Geometry
Nodes to achieve the same result.
MPoly -> offset indices refactor (7966cd16d6) did not realize
that due to forced triangulation the mesh changes, so we need
to re-fetch the faces array after triangulating. Fixes#112011
For text objects, the CharInfo mat_nr material index used to start at 1
(not at zero like for meshes or nurbs).
Code was mostly considering this (but not in all places, so material
index handling (removing/moving) could still go wrong.
As an alternative to !109746 (where it was made sure all places would
make the right assumption about mat_nr starting at 1), this PR now
changes the mat_nr to be zero-based.
This is more in line with other places handling material indices.
Versioning code is in place to properly convert old files.
Fixes#109491
Pull Request: https://projects.blender.org/blender/blender/pulls/112954
This PR adds support for `GPU_framebuffer_blit` When used with `GPU_DEPTH_BIT`.
The challenge with is that not all GPUs support using a depth texture as a blit destination.
An AMD GPU doesn't support a depth buffer with stencil buffer as blit destination.
> NOTE: AMD GPUs don't support 24 bit unsigned normalized depth textures at all.
In all cases when we use depth blitting we are blitting the whole texture
and in stead we can use a texture copy.
A negative effect is that we need to unbind the framebuffer when copying
depth textures, but a positive effect is that we can use a data transfer function what should
theoretically be faster.
This should be revisited when we are investigating in areas to improve the
performance of the Vulkan backend.
Pull Request: https://projects.blender.org/blender/blender/pulls/112674
When initialy adding textures it wasn't possible to allocate during
initialization as its usage wasn't known. Bot Metal and Vulkan would do
a delayed allocation adding more checks when using textures.
Recently the behavior of setting texture usage was changed and now is
known when initializing textures. This PR makes advantage of this to
give correct feedback to the calling code if the texture can be created
and remove all the delayed allocating of textures.
Pull Request: https://projects.blender.org/blender/blender/pulls/112997
When the destination path isn't writable - the save callbacks wouldn't
run. Supporting this can be useful so handlers can unlock a file
before saving, see #88493.
When the type of an enum is known (char, short, int .. etc)
check the values used in the EnumPropertyItem are valid for that type.
This would have made the error from [0] fail at build time.
[0]: 928721c59e
After 97f2b01ea9, the iterator's mask data is just read only,
so there's no point in storing it as a pointer. This simplifies the code
using the mask data, since the default only needs to be handled once.
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
The expand operator reused `SCULPT_UPDATE_MASK` even when it
changed face sets, not the mask. That triggered incorrect behavior in
`node_update_mask_redraw` when there was no mask layer, which caused
nodes to be incorrectly marked as fully masked (and therefore optimized
out of later operations).
