Make sure the code that alters the VSE thumbnail to add transparency
(for disabled strips) works on a copy of the image, so that the extra
transparency does not get "stored" into the thumbnail cache.
Pull Request: https://projects.blender.org/blender/blender/pulls/124689
The problem was basically that, after efd3c4b3c9, `test_cagep` started
to be used without being calculated.
`test_cagep` represents the closest 3D point on an edge.
The solution was to edit the `knife_snap_edge_constrained` function to
calculate the `test_cagep` instead of the `closest_ss` (which is the
projected point).
Calculating `test_cagep`(3D) instead of `closest_ss`(2D) is
advantageous as we avoid matrix transformations and achieve more
precision.
We also deduplicate the code a bit since `closest_ss` can be obtained
by projecting `test_cagep`.
This commit also adds comments to the code, and renamed some variables
and functions for more clarity.
Pull Request: https://projects.blender.org/blender/blender/pulls/124701
The projection was transformed by the object transform, but it's meant
to be in camera space, not affected by the camera view transform or by
the local object's transform. This fix makes viewport raycasting use
cases work without a manual fix in nodes.
Pull Request: https://projects.blender.org/blender/blender/pulls/124610
Currently the node tool operator stores the mouse position from
the first execution because it's not possible to retrieve it again from
the operator redo callback which doesn't have access to the event.
However, other inputs like the region size and the viewport transform
are retrieved again for every redo execution. This creates inconsistency
and generally makes redo less useful for node tools than it should be.
Generally tweaking an input in the redo panel should keep everything
else the same.
This commit adds the rest of the inputs as RNA properties just like
how mouse position is already handled.
Pull Request: https://projects.blender.org/blender/blender/pulls/124557
The `resolution` and `nurbs_order` attributes of curves are expected to be `>=
1`. Due to a bug, it was possible that they are initialized to zero: #124534.
This fix adds versioning code to fix the curves that have been written
incorrectly.
Pull Request: https://projects.blender.org/blender/blender/pulls/124539
Previously, it was fairly easy to create built-in attributes which have invalid
values, because attributes were generally zero-initialized. This was especially
problematic for attributes that had certain invariants that Blender relies on
and that should never be zero. For example, the curve resolution should always
be at least 1.
To reproduce the issue, add the `resolution` attribute from the attributes panel
to curves. They had a value of 0 by default. I found this while investigating
#124416.
Pull Request: https://projects.blender.org/blender/blender/pulls/124534
While investigating #124217 it was noticed that sometimes a >4 channel
ImBuf might be passed through to this api.
This would cause memory to be overwritten because the destination ImBuf
was created with only 4 channels of memory. Now we create it with the
proper number of channels.
Pull Request: https://projects.blender.org/blender/blender/pulls/124472
Properly guard the conditionals inside ImageNode::convert_to_operations
against null operations.
I've duplicated the null check in order to not add another layer of
nesting in an already very deep set of conditionals.
Pull Request: https://projects.blender.org/blender/blender/pulls/124473
Collection Export and File->Export were inadvertently sharing the
"last used" operator properties.
This would cause settings that were used during File->Export to
interfere, silently, when exporting the collections. Or vice versa.
Pull Request: https://projects.blender.org/blender/blender/pulls/124481
The swapping code incorrectly expected the link to have a start and end.
However, this was not necessarily the case when attempting to create
a link from a node to itself. This case has special handling in
`node_link_find_socket`.
Caused by a060e96103
This change restores the old behavior of pass name detection from
channel name prior to the offending commit.
The fix includes regression test based on the files from related
reports, to help catching possible issues in the future.
Being so close to the release this commit restored behavior prior
to the previous fix. Potentially this makes some files to detect
wrong pass name for some specific files, although it is not really
clear if such files exists in the wild.
Pull Request: https://projects.blender.org/blender/blender/pulls/124458
The lazy-function for a logical-or made the wrong assumption that
`try_get_input_data_ptr_or_request` returns null when `try_get_input_data_ptr`
returns null for the same input right before that. That's not true, because the
input might have been computed by another thread in the mean-time.
This wrong assumption lead to a bug because lazy-functions are always assumed to
either request more unavailable inputs, or compute all requested outputs. Here,
the lazy-function did neither. It wanted to request a new input, but it was
available already.
The solution is to handle the return value of
`try_get_input_data_ptr_or_request` properly.
Pull Request: https://projects.blender.org/blender/blender/pulls/124465
Moving a strip retiming key at the end of a strip, so that a strip
overlaps another one would leave them overlapped. The expected
behavior is that it acts according to the Overlap Mode, like it does
when moving a strip.
Co-authored-by: Richard Antalik <richardantalik@gmail.com>
Pull Request: https://projects.blender.org/blender/blender/pulls/124424
Lowering the speed of a strip that doesn't have user-created retiming
keys using the "Set Speed" operator would cause the strip to overlap
neighboring strips. The fix shuffles the retimed strip to avoid
overlap. This now matches the behavior of the same operator, when
using it on a user created retiming key.
Pull Request: https://projects.blender.org/blender/blender/pulls/124414
This addresses #124016. The report provides a scene to test the changes.
Currently, the Blender and MaterialX color spaces are not fully aligned,
but the linear/srgb heuristic should cover most cases however.
Pull Request: https://projects.blender.org/blender/blender/pulls/124315
Even if Cycles is not the active render engine, this
versioning code could affect Cycles if a material was
used with Cylces in another file (using linking).
Fix this by spliting the output node into another one
that only affects EEVEE.
The viewport compositor crashes when the scene is changed in some
situations. That's because the viewport compositor tries to use node
tree data that was freed in the last depsgraph update, while it should
have invalidate those references based on the same depsgraph update.
The source of this issue is in the depsgraph itself. In particular, when
the depsgraph evaluation happens in two passes, the ID recalculate flags
are backed up for every pass then restored at the end of all passes,
however, this doesn't happen for the ID Type Update table. So whenever
evaluations happen in two passes, changes will not be propagated to
engines that require those information, like the viewport compositor
engine in that particular case.
To fix this, we backup and restore the ID Type Update table in a similar
manner to the ID recalculate flags.
Fixes#107235, #124335, #116142.
Pull Request: https://projects.blender.org/blender/blender/pulls/124409
The math render tests were not passing on the AMD hardware.
This was due to some compiler behavior not returning 1
on the `floor((a - c) / (b - c))` calculation even if
`a` and `b` were equal.
When render border is active the default framebuffer view is changed
and results to rendering the HDRI previews inside the render border
and not in the bottom right corner of the 3d viewport.
This PR fixes it by resetting the viewport when drawing the HDRI
previews.
Also tried to pass the DRW default view during submission, but that
didn't fixed the issue.
Pull Request: https://projects.blender.org/blender/blender/pulls/124402
The option on NLA strips "Sync Length" (in the Action Clip dropdown of the N panel)
stops keys from being inserted if it is disabled.
This is due to the evaluation mode of the strip, which is set
to "Hold" internally but ONLY IF "Sync Length" is enabled.
Removing that condition allows to key in tweak mode regardless of that setting.
## History
This has been put in place by 89ee260ef2
Judging by the commit description, this was put in place to allow keyframing
in tweak mode. However, no explanation is given why this is only allowed
with "Sync Length" enabled. Potentially because there was no special
handling of tweak strips for keying evaluation, which has been put in
place later. (09709a7e64)
Pull Request: https://projects.blender.org/blender/blender/pulls/123902
Using a REGEX on an absolute path may not work reliably without
escaping the path. Remove the exclusion as these paths are no longer
part of Blender's sources.
If some developers happen to have these directories it's harmless as
they won't be used.
Also refactor definitions into a macro as they were exceeding the
line-length and wrapping.
Ref: !124275
Co-authored-by: Nathan Burnham <nathan@nathanburnham.uk>
When keys are realized, strip handle positions are used to ensure, that
left and right key exists. If strip content is offset to the right,
this caused crash. This happened, because `SEQ_retiming_add_key()`
clamped timeline frame to strip content only on right side.
Clamp timeline frame to strip content on both sides.
Pull Request: https://projects.blender.org/blender/blender/pulls/124207
When a mesh is shared between multiple objects, sculpting with a brush
with the Curve stroke type doesnt update normal values for the affected
nodes when using PBVH drawing. This is because when reevaluating the
depsgraph for the objects, the shared PBVH is destroyed and the nodes
are recalculated, losing the existing node flag updates.
This only occurs for the Curve stroke type because all of its stroke
steps are performed within a single call to the overall operator when
the user presses enter, unlike other brush strokes which apply on each
mouse movement.
To fix this, we simply force update the normals before destroying the
PBVH at the end of the stroke step.
Pull Request: https://projects.blender.org/blender/blender/pulls/124268
This is due to missing rebuild of outliner tree. Auto smooth operator
is cleared with shade flat execution but outliner is unaware of this and
the modifier tree element remains intact. This add a notifier.
Pull Request: https://projects.blender.org/blender/blender/pulls/124330
Prevent crash from a mesh created around the time of Blender 4.0 with
bad (negative) material indices on some faces.
The Poly Haven folks were poked to fix the actual asset as well but it's
simple enough for us to clamp in this code path, especially since we
were already doing it for the upper bound.
Pull Request: https://projects.blender.org/blender/blender/pulls/124026
Border pixels of the world probe were not
copied correctly to local sphere probes.
Maybe side effect of #123074 or maybe it was
always broken.
Fix is to use the same sampling functions as
regular sampling for biasing the UVs correctly.
Fixes render tests.
The functionality of the Bone Selection Sets add-on is now integrated
into Blender itself. Rigify has been updated to no longer check for the
add-on, but just assume that the functionality is available.
The keymap is still the same, and so are all the class names. This
ensures that there are no conflicts when people still have the old
add-on enabled somehow. And there is versioning code to remove the
'add-on enabled' state so that Blender won't complain it cannot find it
any more.
Compared to the add-on, the following changes are made:
- The 'bone' icon has been removed from the list of available selection
sets. It was the same for each entry anyway, and thus didn't provide
any information.
- The code has been split up into multiple files, with the UI elements
in `scripts/startup/bl_ui/properties_data_armature.py` and the
operators in `scripts/startup/bl_operators/bone_selection_sets.py`.
- Helper functions and classes are prefixed with `_` to indicate that
they are not part of any public API.
- The `Operator` helper subclasses have been transformed to mix-in
classes. This way the only subclasses of `Operator` are the actual
operators.
- Comments & descriptions have been updated for clarity & consistency.
This commit contains code by the following authors, ordered by number of
commits in the original add-on repository, highest first:
Co-Authored By: Ines Almeida <britalmeida@gmail.com>
Co-Authored By: Sybren A. Stüvel <sybren@stuvel.eu>
Co-Authored By: Campbell Barton <ideasman42@gmail.com>
Co-Authored By: meta-androcto <meta.androcto1@gmail.com>
Co-Authored By: Demeter Dzadik <Mets>
Co-Authored By: lijenstina <lijenstina@gmail.com>
Co-Authored By: Brecht Van Lommel <brechtvanlommel@gmail.com>
Co-Authored By: Aaron Carlisle <carlisle.b3d@gmail.com>
For the full history see the original add-on at:
https://projects.blender.org/blender/blender-addons/commits/branch/main/bone_selection_sets.py
Reviewed On: https://projects.blender.org/blender/blender/pulls/124343
Similar to !124267 and !124261
This normal data is eventually passed into `BKE_mesh_set_custom_normals`
and through to `mesh_normals_corner_custom_set` which expects normals to
actually be normalized per its documentation.
Not doing so would yield meshes with incorrect "sharp" data for affected
edges.
Thx @OmarEmaraDev for the initial patch
Pull Request: https://projects.blender.org/blender/blender/pulls/124336
