This PR adds the *Line Hide* tool and the corresponding
`PAINT_OT_hide_show_line_gesture` operator to Sculpt Mode.
*Line Hide* supports common modal functionality including:
* Snapping to angles
* Flipping the selection area
* Moving selection area
Addresses one of the tools in #80390
Pull Request: https://projects.blender.org/blender/blender/pulls/119671
Also access the evaluated deform mesh with a function rather than
directly from object runtime data. The goal is to make it easier to use
implicit sharing for these meshes and to improve overall const
correctness.
See b99c1abc3a for more information about how using fewer
threads for just copying data can improve performance. In my simple
test file with mesh data re-uploaded every frame, this improved
performance from 23.5 FPS to 25.5 FPS (almost 9%).
After bace4c9a29, the vertex position and vertex normal VBOs
are split. The `overlay_paint_point` shader depends on the normals VBO
because the selection is stored in the `.w` component of the vector.
SubdvigCCG is null for the evaluated mesh in the render depsgraph
because of the `!for_render` check in `MOD_multires.cc`. But the PBVH
type is still `PBVH_GRIDS`. That's a weird inconsistency that ideally
wouldn't happen, but probably isn't simple to change. The simplest and
most obviously harmless fix is to just check whether the list of PBVH
nodes to update is empty.
Recently an internal compiler error has been popping up for folks
stemming from our MatBase matrix `operator<<`.
My guess is that the nested fold-expression (coming from `unroll`) and
the lambda is causing MSVC to become very upset in some instances.
Regardless of the actual cause, using simple for loops results in less
generated code and the use of `unroll` isn't required since these output
operators are mainly for debugging.
Unfortunately I've been unable to reproduce it in simpler contexts to
report it upstream.
Pull Request: https://projects.blender.org/blender/blender/pulls/119982
The issue seems to be caused with the recent NVidia drivers, which will
crash if OptiX context is created prior to the OpenGL context on Linux.
This happens with drivers 545.29.06, 550.54.14, 550.67 and kernel 6.8
on Ubuntu 24.04, and also happens with NVidia driver 550.67 on Gentoo.
While it does seem the issue is likely on the driver side, the timeline
for it being resolved there is unknown. Until then it is possible to
apply workaround on Blender side, which will initialize GPU context
prior to rendering with an external render engine when it is known the
GPU context will be needed later on.
Note this is not a complex fix, because in general it's still possible to
render a frame without and then with grease pencil, in which case OptiX
will still be initialized first. But we don't want to always initialize
OpenGL, and we can't predict future operations.
Pull Request: https://projects.blender.org/blender/blender/pulls/120026
For some reason, the vertex paint modal operator
was calling `CTX_data_ensure_evaluated_depsgraph` on
every event update. For obvious reasons, this caused
performance to go down drastically in bigger files.
Specifically in one of the Blender Studio files.
The fix uses `CTX_data_depsgraph_pointer` instead to
get the `Depsgraph` pointer, avoiding a full reevaluation
of the scene.
No functional changes.
The function `get_keyframe_values` existed twice.
Once in a legacy state, which also did NLA logic.
And also in a new implementation where it only returned keyframe values.
This PR removes the legacy function and moves the NLA logic to a separate function.
Pull Request: https://projects.blender.org/blender/blender/pulls/119798
The issue was that the `PointerRNA` passed to `BKE_animsys_get_nla_keyframing_context`
needs to point to an `ID` which wasn't the case when keying bones.
That is because internally the `FCurve` path is used to resolve the property.
This can only work from the `ID` because the `FCurve` path is always stored relative to that.
While the function doesn't fail when the property can't resolve the path, it won't actually do
the remapping when passing it to `BKE_animsys_nla_remap_keyframe_values` later.
Pull Request: https://projects.blender.org/blender/blender/pulls/120008
Handling animation of GPv3 in itself is relatively straightforward, it's
mainly a matter of duplicating animdata into the new GreasePencil ID.
In case some propoerties need to be remapped, this will be done in a
similar way as e.g. GP object's modifiers animation for Object-level
animation.
The complex and ugly part of this PR is in the need to move animation
from GPdata to Object level for some properties. This PR tackles the
'layer adjustments to modifiers' aspect (i.e. adjustments on tint and
thickness).
Known limitations currently with these GPData to Object animation:
* NLA is not supported (i.e. if an NLA in legacy GP data controls these
adjustments animations, it won't be converted to Object-level NLA to
control matching modifiers settings).
* Drivers targets are not handled either, i.e. in case a driver is using
data from legacy GPdata as input, these will be left as-is (this is
true for all anim handling currently).
* There is no adjustments of values for animation (e.g. the thickness
adjustment values would need to be devided by 2000).
Most of these limitations can be addressed at some point, depending on
how critical they are to support. This would have a cost (in time and
code complexity) though.
Pull Request: https://projects.blender.org/blender/blender/pulls/119214
This patch unifies the Defocus node between the CPU and GPU compositors.
Both nodes now use a variable sized bokeh kernel which is always odd
sized for a center pixel guarantee. Further the CPU implementation now
properly handles half pixel offsets when doing interpolation, and always
sets the threshold to zero similar to the GPU implementation.
The Defocus node maximum size option has no effect if Z Depth is not
enabled. That's because the code incorrectly uses the maximum CoC radius
even though it is not relevant if Z Depth is disabled. To fix this, use
the maximum size option directly in case of no Z Depth.
We disable the button for a layers depending on the
state of the parent group. E.g. if the parent group is hidden
the layer button to toggle the visibility was disabled
to indicate that toggling it won't actually change the
visibility of the layer (since the whole group is hidden).
This wasn't the case for layer groups though and this
change fixes that.
This patch unifies the CPU and GPU implementation for the Bokeh Image
node. The bokeh is now evaluated at the center of pixels and allows
different sizes for the output kernel.
This PR implements the background blurring for studiolight/lookdev HDRIs.
The visual appearance matches EEVEE-Classic closely.
**Technical details**
- LOD0 is skipped as the regular background color can be used. The
regular background color is blended towards LOD1.
- Volume probe is mixed in to remove baked in artifacts in the higher LODs.
Pull Request: https://projects.blender.org/blender/blender/pulls/119872
Annotation layer widget was missing on the Tool Settings bar and the
side bar for some of the editors, as well as both color and layer
widgets on the Tool tab of the Properties editor.
Also fixed the Tool Settings bar not updating when drawing annotations
on the Image editor viewport, and the Tool panel in Properties editor
not updating when drawing annotations on the 3D scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/112688
When no shadow views are needed Blender could signal a division by
zero. This change fixes this by safe guarding the division by zero
ensuring the there is always a view to update.
Reordering vertex groups (move up/down or sort) wasn't handled yet for
GPv3, resulting in an assert in `BKE_object_defgroup_array_get()`.
This PR fixes that.
Pull Request: https://projects.blender.org/blender/blender/pulls/119979
Caused by 6a79a6a24a
`Mask` `AnimData` is read by `BKE_animdata_blend_read_data` since above
commit, so `BLO_read_data_address` on `AnimData` is already done there.
However, `mask_blend_read_data` does it again
Similar calls to `BLO_read_data_address` in `blend_read_data` callbacks
were usually removed in 6a79a6a24a, Masks being an exception.
Accoding to @mont29 the reason while a double remapping will fail is
because there can only be one remapping from old addresses to new ones.
Once the new address has been read, this new address cannot be used as
'key' again (it will likely map to nothing, or worse, remap to something
completely unrelated!)
Pull Request: https://projects.blender.org/blender/blender/pulls/119961
The root of the issue was checking against the wrong RNA type to decide
whether a collection's item resolution could use the stored ID pointers
or not, leading to always only relying on names in CollectionObjects
case, leading to a lot of false 'need resync' detections in case names
would get out of sync between liboverrides and linked reference data.
Note that this probably had no other effect than resyncing when not
needed, since actual liboverride apply and resync code would already
do the right thing here.
Campbell Barton
Sean Kim
Hans Goudey
Germano Cavalcante
Jesse Yurkovich
Falk David
Sergey Sharybin
Christoph Lendenfeld
Brecht Van Lommel
YimingWu
Jeroen Bakker
Bastien Montagne
Omar Emara
Clément Foucault
Pratik Borhade
Milan Davidović
Sietse Brouwer
Philipp Oeser