Move the `bAnimListElem` struct down in its header file, so that it sits
underneath the `enum` types that it uses. This move is necessary for an
upcoming refactor where the struct actually declares its fields to be of
those enum types.
Separating the move from the actual change in type will help with
clarity in the diffs.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/122874
This modifies the 3D viewport keyframing operators to work with layered
actions. The functionality is relative basic, and still leaves some things out.
Of particular note:
- Keyframing with keying sets does not yet work.
- User preferences such as the `XYZ to RGB` flag and the keyframe interpolation
type are not yet used/respected.
- Something not caused by this PR but revealed by it: when the last keyframe of
an fcurve is deleted in a layered action, the fcurve still sticks around. This
is different from legacy actions, which delete fcurves when their last key is
deleted. Since the "Only Insert Available" feature is based on the existence
of fcurves, that makes the feature appear broken in some circumstances right
now with layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/121661
This fixes a bug that happens when two drawings in the same grease pencil
data-block reference the same array. In this case, the same attribute array
pointer is written to .blend files for both drawings. However, when loading the
.blend file, it was not detected that the data is shared. Instead each drawing
would think that it was the single owner of the array even though it was shared.
The same problem can technically occur for all kinds of shared data, and not
just for grease pencil. However, only grease pencil shows this issue currently,
because it can easily happen that the same attribute is shared between different
`CustomData` within the same data-block. This very rarely happens with meshes or
curves, because different `CustomData` usually have different sizes and don't
share the same arrays.
A previous fix (cc891aa699) solved pretty much the same issues for the case
when two layers in the same `CustomData` share data. This original fix is now
generalized and is integrated with `BLO_read_shared` which makes it less error
prone. For each data-block, the `BlendDataReader` now remembers which shared
data it has loaded before so that it is not loaded again.
In the future this could be extended to support data that is shared between
data-blocks, but that's not as straight forward as one would hope currently. For
various reasons, different data-blocks could store independent data at the same
pointer. I specifically noticed that with a regression test file:
`blender/tests/data/modeling/geometry_nodes/attributes/attribute_statistics.blend`.
To support it, one solution could be to tag `BHead` in .blend files to indicate
that a specific pointer is shared and unique within the entire file. But that's
for another day.
Pull Request: https://projects.blender.org/blender/blender/pulls/122780
Disabling the last Subdivision Surface modifier was removed by mistake
in
blender/blender-addons/commit/bc801d7b1dad4be446435e0cab4d3a80e6bb1d04
This patch restores the mistakenly removed code that disables the last
Subdivision Surface modifier when the option to export FBX Subdivision
Surface is enabled.
The add-on's patch version has been increased.
Pull Request: https://projects.blender.org/blender/blender/pulls/122841
Since [0] there was no way to refresh local repositories,
with the poll messages suggesting to restart Blender to see updates
which isn't practical for developers.
The ability to refresh was prevented when "Online Access" was disabled,
meaning a developer couldn't easily develop their own add-ons unless
they were online.
[0]: 651621da0d
The buttons to upgrade or sync extensions called extension
operators via bpy.app.handlers, requiring awkward glue-code
which didn't show error reports in to the user.
Remove these operators and call the upgrade & sync operators directly.
Instead of using "box" layouts for these import/export operators, use
panels instead. Many choices for the layout and organization has come
from the `universal-scene-description` branch though it's not a 1:1
equivalent.
Motivation for using panels is two fold.
Firstly the use of panels instead of boxes is more consistent with other
parts of Blender and with the other IO features.
Secondly, in the case of an Import invoked from drag-n-drop or Export
configured on a Collection, the large number of options exposed results
in a very long layout. Panels allow us to close some sections by default
and allows the user to open/close panels based on their own needs in
general.
Along the way some effort went into standardizing the layout and wording
used as much as possible.
Pull Request: https://projects.blender.org/blender/blender/pulls/122415
Support for "System" extensions as an alternative to the current
"User" extensions repository.
The purpose of this change is to support bundling extensions for
offline work or in environments where users setting up thier own
extensions isn't desirable, see #122512.
Details:
The default "System" repository on Linux will for example use:
- `/usr/share/blender/4.2/extensions/{system}` For system installs.
- `./4.2/extensions/{system}` For portable installs.
- Blender's default startup now has a "System" repository
which users or administrators may populate.
- Repositories can select between User/System paths,
setting a custom path overrides overrides this setting.
- Add "BLENDER_SYSTEM_EXTENSIONS" (matching "BLENDER_LOCAL_EXTENSIONS").
Ref !122832
Changes in view3d_id_path_drop_copy from 8b6a21c122 assumed that
drag-drop filepaths was handled only with FileHandlers in View3d. This
adds the missing drop-box to FileHandler conversion for .vdb files.
Pull Request: https://projects.blender.org/blender/blender/pulls/122839
A few of the recently added submenus are not included in the list of builtin
menus, so node assets under those catalog names will generate redundant submenus.
Fixes same issue as b49c84276c for newly added nested menus.
Pull Request: https://projects.blender.org/blender/blender/pulls/122855
If the mesh has a curve builtin attribute that's not stored on the point domain,
the creation of the attribute will fail and it can't be interpolated. Possibly this
could be supported somehow, by averaging all the values in the curve's points
or so, but for now just avoid the crash.
Only the evaluated positions were changed when deform or subsurf
modifiers were active. This was caused by only writing to the
evaluated positions owned by the PBVH and assuming these were
aliased with the mesh positions.
There were also quite a few TODOs in the area related to an extra
positions array that was passed around that was conceptually
unnecessary. Brush deformations should be based on the evaluated
positions, but only the original positions should be written to.
This PR resolves those TODOs while resolving sculpting with deform
modifiers and shape keys. We do this by only writing to the original
mesh positions. For shape keys we use the existing translations from
the brush rather than recomputing them, and only copy the mesh
original positions to the active shape key.
This also makes it easier to remove the PBVH's copy of vertex
positions in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/122842
Update PBVH GPU argument initialization to prefer using the PBVH mesh
attributes instead of the evaluated mesh attributes for color.
The values can be out of sync due to differences with the evaluated
and original mesh data.
Pull Request: https://projects.blender.org/blender/blender/pulls/122850
The goal is to simplify debugging the "current" simulation step. Previously, when a frame
was cached already, one would have to go back to the beginning to cache everything again.
Now, the last cached simulation step is discarded and simulated again if any property that
affects it is changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/122736
