Use `enum` type for the `filter_mode` parameter of many functions. This
makes debugging easier and just makes the code slightly easier to
understand.
Also make the function parameter `const` wherever possible. Unfortunately,
due to the `BEGIN_ANIMFILTER_SUBCHANNELS` and `END_ANIMFILTER_SUBCHANNELS`
macros (which modify `filter_mode`), this is possible less often than I'd
like.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/122882
Mainly correct/update some comments (e.g. missing reference to Boolean
type), and add some notes essentially about issues with current IDProp
String code (see also #86960 ).
No functional change.
In case a 'compatible' old IDProperty exists,
`update_input_properties_from_node_tree` would essentially reuse it
as-is, only keeping the UI data from the freshly new IDProp it created
for the socket.
This commit instead fully re-use the newly created idprop, only copying
(and converting as needed) the value from the old one.
That way, we can be sure that the actual type of the IDProperty is reset
to its expected type, instead of being kept forever in a 'wrong' type.
Having IDProps in a stable, expected type is a sounder behavior in
general, and critical for lower-levels of code to work as expected
(like RNA diffingi, and by extension, Library Overrides e.g.)
NOTE: This is a side-finding from work on #122743 to make some idprops
statically typed, and is a pre-requirement for this to work with the
GeoNodes modifiers case.
Pull Request: https://projects.blender.org/blender/blender/pulls/122876
The C++ classes that wrap DNA structs should never store any data.
Runtime data needs to be stored on the runtime classes/structs
and anything else needs to be put into DNA.
This adds static asserts to make sure (at compile time) that these
classes have the same size as the DNA structs (i.e. they don't store
additional data).
Change the `bAnimListElem` fields `type`, `update`, and `datatype` from
respectively `int`, `char`, and `short` to their actual `enum` types,
respectively `eAnim_ChannelType`, `eAnim_Update_Flags`, and
`eAnim_KeyType`.
To prevent compiler warnings, all `switch` statements that try to handle
these fields have been expanded with the missing `case`s. This should
help in the future when new channel types are added, as that'll cause
more compiler warnings in those places that need updating.
One `if`/`else if`/`else` chain was converted into a `switch` for
clarity. This was actually the place where my (upcoming) code is hitting
the `BLI_assert_unreachable()`, which was the final straw for this
refactor.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/122874
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
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
Fix of conversion identity quaternion to axis angle. Basically,
if the length of the imaginary part-vector is zero, it is
incorrect to normalize it. Simple identity should be returned.
Pull Request: https://projects.blender.org/blender/blender/pulls/119762
Fixed a crash when dynamic topology is active on multires displacement smear brush
Added a check for this case at the start of the brush stroke, with a user visible error message
and cancels the operator early so no topology is modified either.
Pull Request: https://projects.blender.org/blender/blender/pulls/122453
