Following the uiLayout refactor, this converts each layout estimate
function as virtuals methods, so w_ and y_ properties can become
protected. This includes missing structs for each layout type in
`uiItemType`, but without the `ui` prefix (they eventually will be
moved to the to the `blender::ui` namespace instead)
Pull Request: https://projects.blender.org/blender/blender/pulls/146049
This adds support for `Bézier` and `Catmull Rom` curve types to the
interpolation tool.
When interpolating between to curves of different types, a priority
system is used.
The priorities from highest for lowest are in the order
`NURB`, `Bézier`, `Catmull Rom` and `Polyline`.
The reasoning for this order is that:
- `NURBs` can be degree order 5 or greater, were as `Bézier` is only
order 4.
- `Bézier` can match the form of both `Catmull Rom` and `Polyline`, so
should be higher priority.
- `Catmull Rom` is continuous.
- `Polyline` is the simplest and is not smooth, so it should be last.
Note: This does add some simple `NURBs` interpolation, but proper
handling is more complicated and will be save for a future PR.
Resolves: #141178, #143377, #133948 and #136087
Pull Request: https://projects.blender.org/blender/blender/pulls/145683
* Removes `USER_DEVELOPER_UI` conditional check for
`USER_EXPERIMENTAL_TEST` since the options are always exposed in alpha
builds.
* Adds `USER_DEVELOPER_TOOL_TEST` as a helper macro for developer
options.`
Pull Request: https://projects.blender.org/blender/blender/pulls/146116
This PR introduces a 'Developer Tools' section of the user preferences,
enabled when the `Developer Extras` option is enabled. This menu will
not be hidden when the release cycle is no longer in alpha, allowing
developers to use this for common debug options instead of having to use
`G.debug_value` and arbitrary values.
This has the benefit of allowing for an ease of debugging in non-alpha
builds as well as being able to use multiple options that would have
been considered exclusive debug options at once.
None of the existing values bound to a specific `G.debug_value` have
been migrated yet.
Pull Request: https://projects.blender.org/blender/blender/pulls/145215
Addresses #145680.
In one (relatively extreme) test file with the surface deform modifier,
memory usage goes from 14 GB to 4 GB, and an annoying freeze
from preparing an undo step after every operation is gone.
Pull Request: https://projects.blender.org/blender/blender/pulls/145705
This option has been removed in vs2026 and will cause a build error,
disabling this option results in our default /DEBUG being used
which is equivalent to /debug:full which is the suggested
replacement
The fix introduced a high severity bug where exiting Blender after
working with the GPU compositor crashes Blender. We consider #144526 to
be less severe than the newly introduced bug, hence the revert for now.
This reverts commit b2b23e3619.
Pull Request: https://projects.blender.org/blender/blender/pulls/146096
"Enable modifier" was using the eye icon, which usually indicates
only visibility, but this actually affects render.
Also in the future there could be other visibility toggles, like
regular modifiers.
Reviewed with Falk and Dalai in person.
There is no CMake version yet that support VS2026, support is
currently limited to ninja based builds.
CMake does not know where to look for the MSVC 2026 Runtime
it copies the wrong CRT leading to startup issues, for this reason
WITH_WINDOWS_BUNDLE_CRT has been disabled for VS2026 + CMake < 4.2.0.
Builds done with VS2026 are for this reason *NOT* distributable to
end users at this point in time.
CMake 4.2.0 Is *expected* to have VS 2026 support [1]
But further testing is likely required.
Things of note:
- They stopped using the "preview" channel and have rebranded to
"Insiders" the make.bat options have been updated accordingly to
select the 2026 Insiders build, you need to pass 2026i to make.bat
- All tests seem to pass on my system
- No new warnings, pretty smooth update
[1] https://gitlab.kitware.com/cmake/cmake/-/merge_requests/11168
Pixel buffers will be imported by Cycles in Cuda/OneAPI/HIP
when supported. However the priority and export field is not filled correctly,
resulting in that the priority is always 1 and the buffer is never exported.
Should be backported to 4.5 as Cycles GPU interop isn't working
when using Vulkan.
Regression introduced by: !144422
Pull Request: https://projects.blender.org/blender/blender/pulls/146090
Only use when Windows Automatic Color Management (ACM) is enabled.
That way we know Windows will automatically convert from extended sRGB
linear to the appropriate color space for the display.
When we previously tried this there were some issues, but I think it was due
to ACM being off. This has been confirmed to work on NVIDIA and AMD, and
Intel is not expected to support this (yet) for the same reasons there is no HDR.
Pull Request: https://projects.blender.org/blender/blender/pulls/146041
Display the active keying set name as label, and an icon to indicate
the current keyframe type.
This also adds a descripition/tooltip to the keying popover, so it's
easier to understand when the keying set name is not clear.
See PR for details and screenshots.
Pull Request: https://projects.blender.org/blender/blender/pulls/145963
Some of the color space settings are not validated on load to be set to
a valid values. To deal with those cases better bake it so color management
module does not make assumption on validness of the input data.
This is an oversight in the !140729.
Pull Request: https://projects.blender.org/blender/blender/pulls/146084
It is usually nice to unroll loops with a different number of
iteration based on a macro. This commit adds this functionality
to our shader preprocessor so that we don't have to manually unroll
these loops.
Pull Request: https://projects.blender.org/blender/blender/pulls/146043
The Convolve node crashes Blender if used with GPU device and its output
is used multiple times. This is due to a use after free error, because
the convolve node ignored the reference count of the output.
To fix this, we retain the reference count of the output by stealing the
data of the GPU-side buffer, instead of overwriting the output with it.
Pull Request: https://projects.blender.org/blender/blender/pulls/146074
When using `emboss=False` on a UI prop, if `property_split` was
enabled, all subsequent props in the same layout would also be
unembossed.
This is because of the way the emboss status was set.
When drawing a prop, the previous emboss status was stored in a
temporary variable `prev_emboss`. This status was retrieved from the
uiLayout (`this`), but restored to a `layout` uiLayout that could be
another one, because it could be reassigned in the mean while.
Instead the status should just be restored to `this`, otherwise the
layout can keep the same unembossed status for subsequent props.
Pull Request: https://projects.blender.org/blender/blender/pulls/145883
Although this doesn't lead to any different behaviour or fixes any issue
it was an oversight as this would not wait for empty render graphs to be
finished in the order of submission
Pull Request: https://projects.blender.org/blender/blender/pulls/146066
The destructor needs to be set to virtual. Otherwise the base object
(`PenToolOperation`) will not be destroyed with the derived object
(`GreasePencilPenToolOperation` or `CurvesPenToolOperation`).
Pull Request: https://projects.blender.org/blender/blender/pulls/146047
This patch replaces the `PBONE_SELECTABLE` macro with functions.
There is a slight functional change in that for pose bones: the visibility
is now correctly accounted for. Before this change it would always look
at the `Bone` visibility. This is no longer the correct way to
check for that since a43359eb88
moved that to the pose bone
Part of #138482
Pull Request: https://projects.blender.org/blender/blender/pulls/145974
Border links (links going from an outer zone to an inner zone) need special
handling. When requesting the value of a linked socket from outside of the
current zone, the compute context of that parent zone has to be used.
Pull Request: https://projects.blender.org/blender/blender/pulls/146059
`GHOST_SwapWindowBuffers` doesn't fit well when using swapchains. In
that case an approach where swap chain images are acquired and released
would map better. This PR introduces `GHOST_SwapWindowBufferAcquire`
and `GHOST_SwapWindowBufferRelease` to be more in line with vulkan swap
chains.
Previous implementation would first record all GPU commands based on
the last used swap chain. In case a swapchain needed to be recreated
(window resize, move to other monitor) the recorded commands would
not match the swap chain and could lead to artifacts.
OpenGL only implements the release functions as they don't
have a mechanism to acquire a swap chain image. (Need to validate with
the Metal API how this is working and adapt is needed).
Currently when starting blender on a HDR capable display the first frame
would be based on an sRGB surface and presented on an extended RGB
(or other) surface. As these don't match the first frame could be incorrect and
also lead to UBs as another surface is expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/145728
This makes the shader node inlining from #141936 available to external renderers
which use the Python API. Existing external renderer add-ons need to be updated
to get the inlined node tree from a material like below instead of using the
original node tree of the material directly.
The main contribution are these three methods: `Material.inline_shader_nodes()`,
`Light.inline_shader_nodes()` and `World.inline_shader_nodes()`.
In theory, there could be an inlining API for node trees more generally, but
some aspects of the inlining are specific to shader nodes currently. For example
the detection of output nodes and implicit input handling. Furthermore, having
the method on e.g. `Material` instead of on the node tree might be more future
proof for the case when we want to store input properties of the material on the
`Material` which are then passed into the shader node tree.
Example from API docs:
```python
import bpy
# The materials should be retrieved from the evaluated object to make sure that
# e.g. edits of Geometry Nodes are applied.
depsgraph = bpy.context.view_layer.depsgraph
ob = bpy.context.active_object
ob_eval = depsgraph.id_eval_get(ob)
material_eval = ob_eval.material_slots[0].material
# Compute the inlined shader nodes.
# Important: Do not loose the reference to this object while accessing the inlined
# node tree. Otherwise there will be a crash due to a dangling pointer.
inline_shader_nodes = material_eval.inline_shader_nodes()
# Get the actual inlined `bpy.types.NodeTree`.
tree = inline_shader_nodes.node_tree
for node in tree.nodes:
print(node.name)
```
Pull Request: https://projects.blender.org/blender/blender/pulls/145811
It is possible for the simple vertex normal calculated during Paint
BVH normal updates to have a length of 0 if the connected faces cancel
each other out. This is a generally unlikely scenario, but will almost
always lead to further corruption of the mesh with the new normal.
If we detect this case, set the vertex normal to (0, 0, 1)
Pull Request: https://projects.blender.org/blender/blender/pulls/146004
Caused by NaN propagation. If a face becomes 0 area, the resulting
normal becomes a zero vector. This normal cannot be used to calculate
the distance to a plane.
To fix this case more generally, we clamp the strength to 1.0 at most
to avoid introducing scenarios where a given vertex can have a zero
vector normal.
Pull Request: https://projects.blender.org/blender/blender/pulls/145952
These `BLI_assert`s could be triggered by converting curves that were
already the desired type.
`curves.is_single_type` Checks if all of the curves are the desired
type, not if all of the selected curves are the type.
So the asserts can be triggered when only the destination type curves
are selected and other curve types exist.
Pull Request: https://projects.blender.org/blender/blender/pulls/145529
