You could basically not interact with the animation (except for
keyframes in the main region), channels region was totally empty, NLA
could not be used, ...
It is not something users will animate a lot, but we should still have
animation editors in mind when adding a new object type.
Just missing from cc31d7bb49
Pull Request: https://projects.blender.org/blender/blender/pulls/141449
Adjust angle threshold defaults to dissolve verts as before,
while preserving selected geometry.
The new behavior works as follows:
- If a dissolve terminates on an edge loop or the the corner vert of a
face, do the dissolve.
- If a set of dissolve edges (either a chain, or a set of 3+ edges)
crosses a loop cut, do the dissolve.
- If a chain of dissolve edges touch the corner of an unselected face,
and then leave in a different direction without crossing a loop cut,
preserve that vert. Just because the selection touches it doesn't mean
it should be altered.
- If a dissolve edge is separating two triangles,
then the face join creates a quad. Users generally prefer
and strive to create meshes that contain quads.
Instead of destructively dissolving the corners of the quad and
automatically turning it to a triangle or wire,
instead prefer to preserve the quad.
Ref !141097
Cursor is actually wrapped at the beginning with the help of function
`WM_cursor_grab_enable`. Though the `ND_MODE` event notifier added
inside `editmode_enter/exit_ex` further calls `region_cusor_set()`.
This resets the cursor to default at the bottom of
`ED_region_cursor_set()`. Such sitution could be avoided by creating a
dummy cursor function for hud region. But issue remains when we call
redo panel from F9. As Julian suggested, add condition for `grabcursor`
to avoid changing cursor when editing buttons.
Pull Request: https://projects.blender.org/blender/blender/pulls/133529
Use fixed speed values for translations in Fly mode to constant
values for each axis. Until now, after switching to the Fly mode,
the latest speed value calculated based on RegionView3D::dist
was used for translations.
Now, the translation speed in Fly mode is an adjusted constant
for each axis.
Ref !141285
It was applying the bounds clamp to each object individually,
which changed spatial relationships between objects. Make the logic
match what used to be done in the Python OBJ importer back in the day.
Pull Request: https://projects.blender.org/blender/blender/pulls/141446
The main armature deform functions compute a vector and/or matrix from
a weighted sum of bone deformations. This can be done either with
linear interpolation or using dual quaternions.
The linear and dual-quaternion methods were mixed together in the same
functions, which makes the code unnecessarily hard to follow. This patch
introduces a "Mixer" concept (similar to attribute math) that abstracts
the process of adding bone influence to the target vector/matrix. It also
takes care of finalizing the value. This way the code iterating over the
vertex group and/or bone envelopes can be agnostic of the target data.
The ArmatureUserData also receives significant refactoring to remove
unnecessary variables, utilize modern math classes, and generally improve
variable naming.
Pull Request: https://projects.blender.org/blender/blender/pulls/141348
As mentioned in 98c7e75897, the idea of "pinning" was to have certain
animation always visible (regardless of object selection -- e.g.
animating camera movement even while animating something else).
dea7ef4dd9 added a special case that would also
include the object regardless of it being selected or not if its
**object data** is animated and pinned.
It only fully implemented that for Cameras though (that was the primary
request at that time), leaving ugly blank/empty space (pin icon missing)
for other object data types.
It is understandable that it only did it for Cameras a that time, but
there is no reason to **not** do it for other (viewport selectable)
object data types as well (animators might as well be interested in
pinning other types as well for timing reference) -- which is what this
PR does.
Adding this to 4.5 (since it fixes the blank space (even though it is
somewhat adding a feature as well...)
Pull Request: https://projects.blender.org/blender/blender/pulls/141396
Seems like a mistake in dea7ef4dd9
The decision to display an object or not in animation filtering is done
in `animdata_filter_base_is_ok`
So e.g. if an **object** has `AnimData` and that one is pinned
(`ADT_CURVES_ALWAYS_VISIBLE`) it would be included regardless of it
being selected or not. dea7ef4dd9 added a special case that would also
include the object regardless of it being selected or not if its
**object data** is animated and pinned.
What dea7ef4dd9 did wrong though in that special case was that it also
required the object to **not** have animation.
This seems wrong, the object can have animation which itself is not
pinned (ultimately causing `animdata_filter_base_is_ok` to return
`false`).
So to resolve, remove the check for NULL object animation, it should be
entirely enough to have object data animation which is pinned to include the
object in animation filtering.
Pull Request: https://projects.blender.org/blender/blender/pulls/141379
- Add PyObject_GetOptionalAttrString (only available in Python 3.13).
- When registering RNA classes use optional attribute access to avoid
raising and clearing exceptions.
- Refactor macro that handles substituting Python's built-ins
with a `for` loop for better readability.
If `__name__` or `__doc__` were None, the property would be detected as
being set when checking if the property is set (for required properties).
This is more of a technical correction as its unlikely developers would
run into this in practice since `__name__` should never be None and
the description is not a required property.
This commit changes the `SubdivCCGAdjacentEdge` and
`SubdivCCGAdjacentVertex` structs to be simple wrappers around standard
container types, avoiding the need for manual memory management.
Pull Request: https://projects.blender.org/blender/blender/pulls/141163
When a paint stroke is executed instead of processed via the modal
handler, prior to this commit, the `paint_brush_update` function was
not called. This method handles initialization of some temporary stroke
data inside `UnifiedPaintSettings`, which is used by dyntopo when
performing edge collapse.
This had the result of causing a divide by 0 with certain uninitalized
settings when using a brush with dyntopo enabled and calling the
operator from the python API (e.g. from unit testing), resulting in
nonsensical deformations.
There are a number of weak points with the current design:
* This issue was only exposed because of the refactor to the
`UnifiedPaintSettings`, indicating that despite these values being
runtime-only, they were still persisted in some cases in .blend files
* The data stored as individual stroke steps is not sufficient to
reconstruct a paint stroke given a list of screen-space locations, and
this data is populated outside of the common `stroke` callbacks.
Both of the above issues are wider reaching than this PR is intended to
fix.
This commit ensures that `paint_brush_update` is called in the `exec`
codepath and updates the related test image.
Pull Request: https://projects.blender.org/blender/blender/pulls/141314
External render engines, like Cycles, do not use the paint BVH for
rendering. As part of the stroke update process, normal caches are
tagged as dirty. These normals need to be recalculated to be valid on
the next stroke step.
This commit is a mitigation for the reported issue, but does not
fully fix the underlying issue that causes the cycles data to
be in this state.
Pull Request: https://projects.blender.org/blender/blender/pulls/140503
This renames `UI_block_layout` API as `blender::ui::block_layout`,
following uiLayout refactors.
This function now returns a layout reference instead of pointer,
this changes applies this return type where the layout can be used
as such reference.
Changes includes the use of `blender::ui::LayoutDirection` and
`blender::ui::LayoutType` as typed enum parameters.
Part of: #117604
Pull Request: https://projects.blender.org/blender/blender/pulls/141401
Tune the grain size used for the parallel_for to alleviate excessive
mutex contention inside `handle_fan_result_and_custom_normals`.
I happened to notice that the 4004 Moore Lane USD scene[1] experienced a
load time regression compared to the prior release. It looks due to the
grain size used and here are some 3-run averages for the import:
```
Grain | Time in seconds
256 (main) | (14.6+14.6+14.8)/3 = 14.6667
1024 | (13+12.8+12.9)/3 = 12.9
4096 | (13.3+13.1+13.1)/3 = 13.1667
16384 | (12.2+12+ 12.5)/3 = 12.2333
65536 | (9.4+9.2+9.6)/3 = 9.4
131072 | (7.9+7.7+8)/3 = 7.8667
262144 | (7.3+7.1+7.2)/3 = 7.2
max(16384, #verts/2) (PR) | (7.1+6.9+6.8)/3 = 6.9333
```
This PR gets the scenario loading in just under 7 seconds now compared
to over 14 originally.
[1] https://dpel.aswf.io/4004-moore-lane/
Pull Request: https://projects.blender.org/blender/blender/pulls/141249
Currently drag and drop expects to selection to be in the same folder,
but blender internal file browser allows to select files from different
folders when recursion is active.
When writing to operator properties the `directory` is taken now from
the first file provided, and `files` are now relative to this
`directory` instead of just taking the file name.
When reading from operator properties filepaths are normalized.
I notice this issue while reading about #140942, the issue would
require a proper fix too.
Pull Request: https://projects.blender.org/blender/blender/pulls/140948
As noted in [0], locking or atomics are not required for merging
requests for a single mesh, because there is no multithreaded iteration
over objects that will process the same mesh in multiple threads. This
locking was added preemptively over the years and has made code
needlessly complicated, even while the final design for parallel object
iteration isn't completely clear. This PR removes the locks to simplify
some changes necessary for mesh attribute storage refactors.
[0]: b6764e77ef
Pull Request: https://projects.blender.org/blender/blender/pulls/141405
While calculating the scaling factor when rasterizing SVG files to
cursors there is an extra code line left in that was only used
during testing. Basically the size is correctly calculated and then
this extra line does it again, but in a different way. This can result
in the very bottom single line of the cursor being cut off at some
sizes.
Pull Request: https://projects.blender.org/blender/blender/pulls/141410
Most gizmo parts have a hit space larger than the visible part. Some
parts have a hardcoded expanded hitspace, while some parts have a
(hidden) expansion of the line widths during selection. So when using
the Transform widget most pieces are easier to hit than they appear.
Except for the "cubes" at the end of the scaling arrows. This means
they are hard to hit when in orthographic views since the rotation
lines are on top of them. This PR increases the size of the cubes
during selection so they are wider than the rotation lines. This also
similarly increases the selection hit size of the arrowheads, but
mostly wider. The little squares for plane translation are also
increased but just a bit.
Pull Request: https://projects.blender.org/blender/blender/pulls/141362
This was only true when the mode was set to World.
Make it consistent with the Custom backgroubnd option and
fallback to Theme background color for lookdev and render.
