Grease Pencil dash modifier wasn't merging strokes from strokes that are
unfiltered, resulted in only filtered strokes being shown afterwards.
This fix joins generated strokes with what's left behind so there's no
stroke missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/135705
Grease Pencil dash modifier wasn't merging strokes from strokes that are
unfiltered, resulted in only filtered strokes being shown afterwards.
This fix joins generated strokes with what's left behind so there's no
stroke missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/135705
Reduce size of last endpoint gizmo on line primitives `size_primary` 8.0f
to be the same size of `size_tertiary` 3.0f. Circle and Box primitives are
unchanged as they don't have endpoints and a bigger gizmo doesn't affect
visibility. Motivation for this change is to increase visibility of the endpoint
while drawing since the default is too big for these type of lines and it
blocks the view of it.
Pull Request: https://projects.blender.org/blender/blender/pulls/135658
The curve widget in the redo popup would sent an undo push which it
shouldn't really. Since 1bde901bf2 such undo pushes will lead to
clearing of the last operation data, which is exactly what the redo
popup displays.
Buttons in operator redo UIs shouldn't send undo pushes. 179169d6c7
disabled them for the "Adjust Last Operation" panel, but not for this
redo popup. In fact there was other code to disable undo for these
buttons, but 2d2f23de10 put this into a wrongly scoped conditional
branch, so it was only executed on the first full redraw.
We can revert 179169d6c7 too now (confirmed already), but I'll do that
separately and not in the release branch.
Confirmed that the following related issues are all (still) fixed with
this:
- #55348
- #134505
- #135655
Pull Request: https://projects.blender.org/blender/blender/pulls/135730
Since the introduction of e53ac805af, viewer and previews were not
computed when rendering, because we assumed those would only be useful
during interactive compositing. But we received multiple reports that
this is broken. So users generally expect rendering to compute viewers
and previews.
This patch makes a distinction between background rendering and F12
renders, where the latter computes viewer and previews. This should not
have significant effect on the render time, because typically viewer
results are already computed as part of computing composite results.
Pull Request: https://projects.blender.org/blender/blender/pulls/135723
Use anonymous namespace to prevent naming collision allocating
structs of the same name.
Should resolve#134419 although I was unable to redo this bug.
Ref !135726
In the case of interpolating from a single-point curve to a larger curve
the interpolation tool did not fill the destination indices and factors
arrays, because the "segments" count is zero.
Handle this as a special case to avoid breaking assumptions in the rest
of the sampling code.
Pull Request: https://projects.blender.org/blender/blender/pulls/135720
The issue was that the multiframe editing toggle is a tool setting and not
stored in the object data anymore (which was changed in 4.3 so that users
don't have to toggle it in every object).
The batch caches of all Grease Pencils will include the multiframes even
when they are not active.
This leads to the issue that inactive objects don't rebuild their batch cache
when the setting is toggled and we access memory that is out of bounds.
To fix this (for now), toggling the multiframe setting tags all the Grease Pencil
IDs for an update. Obviously this is less than ideal, but the safest option as
of right now.
In the future, we should create a batch cache for each frame.
Then the render engine can request each frame when it's needed,
and we no longer need to tag all the objects for an update when
the setting changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/135636
This was cause by the legacy undo recreating the depsgraph for
every update.
Depsgraph is recreated for each undo step which make the update
counter stay at 1. The fix is to protect for this case using a
global atomic counter.
The Mix Color shader node does not retain the alpha channel of the first
input in both the Linear Light and Soft Light modes, while it is retain
for other modes. Further, result clamping also ignores the alpha due to
using the vector clamp function, which introduces implicit conversion
that removes the alpha.
This does not matter for EEVEE because it does nothing with the alpha
channel. But the code will now be shared with the compositor, which does
care about the alpha channel. So adjust the code accordingly to retain
the alpha in those cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/135632
Blender already had its own copy of OpenSubDiv containing some local fixes
and code-style. This code still used gl-calls. This PR updates the calls
to use GPU module. This allows us to use OpenSubDiv to be usable on other
backends as well.
This PR was tested on OpenGL, Vulkan and Metal. Metal can be enabled,
but Vulkan requires some API changes to work with loose geometry.
# Considerations
**ShaderCreateInfo**
intern/opensubdiv now requires access to GPU module. This to create buffers
in the correct context and trigger correct dispatches. ShaderCreateInfo is used
to construct the shader for cross compilation to Metal/Vulkan. However opensubdiv
shader caching structures are still used.
**Vertex buffers vs storage buffers**
Implementation tries to keep as close to the original OSD implementation. If
they used storage buffers for data, we will use GPUStorageBuf. If it uses vertex
buffers, we will use gpu::VertBuf.
**Evaluator const**
The evaluator cannot be const anymore as the GPU module API only allows
updating SSBOs when constructing. API could be improved to support updating
SSBOs.
Current implementation has a change to use reads out of bounds when constructing
SSBOs. An API change is in the planning to remove this issue. This will be fixed in
an upcoming PR. We wanted to land this PR as the visibility of the issue is not
common and multiple other changes rely on this PR to land.
Pull Request: https://projects.blender.org/blender/blender/pulls/135296
It has been confirmed that the latest release of AMD drivers has fixed
issues for both OpenGL and Vulkan. Users should use AMD driver 25.3.1
or later. Removing the workaround as it has performance penalties on
RDNA2 based GPUs.
Reference: #135516
Pull Request: https://projects.blender.org/blender/blender/pulls/135630
Previously in 6f80d722c6 there was a fix for
not removing layers from evaluated data when their visibility is animated,
however it overlooked that the same thing could happen to layer groups.
This fix basically duplicated the same check for layer groups.
Pull Request: https://projects.blender.org/blender/blender/pulls/135450
Due to recent code changes, `knife_calculate_snap_ref_edges` relied on
the (not yet computed) `kcd->curr.mval` to compute the raycast ray.
The solution is to pass the computed ray right before.
Also `knife_snap_update_from_mval` is now called on the modal to update
the edge as soon as the button is pressed.
Pull Request: https://projects.blender.org/blender/blender/pulls/135649
In the report, the bounds didn't include the curves generated from the
original legacy curve object. Generally we need to access the evaluated
geometry bounds here when the object is a geometry object.
This depends on 06f6d77979 for consistent behavior with
curve radii. That's why the fix is limited to main rather than 4.4.
Pull Request: https://projects.blender.org/blender/blender/pulls/135639
Caused by 21aef81714
Now, pass along `uiname` as `std::optional<StringRef>` early on (and use
`std::nullopt`).
Without this, the `(!uiname || !uiname->is_empty())` condition in
`ui_item_enum_expand_elem_exec` wont be true, resulting in the empty
label.
Pull Request: https://projects.blender.org/blender/blender/pulls/135621
Unlike the legacy type, the radius isn't included in the bounds for the new
curves type. This hasn't been obvious because the drawing is quite broken
and doesn't use the radius properly.
This commit adds a separate cache for the bounds with the radius, which
is now used by default. The old cache is kept around for backward
compatibility in the bounding box geometry node, where a new
"Use Radius" option accesses the old behavior.
Pull Request: https://projects.blender.org/blender/blender/pulls/135584
The name of each instance geometry is the character. This makes debugging
in the spreadsheet much easier, and the objects from "Visual Geometry to Objects"
are actually usable too.
Pull Request: https://projects.blender.org/blender/blender/pulls/135599
The issue was happening because the `is_render_depth_available`
state flag was false leading to the depths being cleared.
When we use `is_depth_only_drawing`, we expect
that the depth is valid because the Grease Pencil
engine will write them.
Pull Request: https://projects.blender.org/blender/blender/pulls/135619
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
MEM_[cm]allocN<T> templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use MEM_new (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135626
When renaming bones, vertex groups that has the same name as the old
name of the bone will be renamed to the new name, but this may cause
name collision in the vertex group list. When this happens, we should
not change the vertex group's name. Now a warning message will show.
Pull Request: https://projects.blender.org/blender/blender/pulls/135492
The main issue of 'type-less' standard C allocations is that there is no check on
allocated type possible.
This is a serious source of annoyance (and crashes) when making some
low-level structs non-trivial, as tracking down all usages of these
structs in higher-level other structs and their allocation is... really
painful.
`MEM_[cm]allocN<T>` templates on the other hand do check that the
given type is trivial, at build time (static assert), which makes such issue...
trivial to catch.
NOTE: New code should strive to use `MEM_new` (i.e. allocation and
construction) as much as possible, even for trivial PoD types.
Pull Request: https://projects.blender.org/blender/blender/pulls/135620
