#138435 was an attempt to fix the issue in #138168 where the Smooth
Operator modifies locked vertex groups. Unfortunately, the fix actually
changed some already-correct code to be incorrect to compensate for the
buggy code in the Smooth Operator.
This reverts that fix and applies a correct fix, which is to exclude
locked vertex groups in the Smooth Operator's code itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/141093
This PR sets the default frame method for camera background images from
the current `Stretch` to `Fit`. For a lot of use cases, `Fit` is the
desired frame method, rarely `Crop` is used, with `Stretch` being even
more rare. This saves the user from having to manually set the frame
method after adding an image. This can also prevent cases where an
artist adds a reference image that's close to the camera aspect ratio
but doesn't match it completely, giving a slight distortion that they
might not immediately notice, and causing confusion down the line.
Pull Request: https://projects.blender.org/blender/blender/pulls/141075
This check was meant to catch unknown failure cases but instead it
meant any attribute with an empty array (e.g. from a mesh with no
faces) would not be loaded. Instead the failure case should only be
when there is no data when the array is not meant to be empty.
Pull Request: https://projects.blender.org/blender/blender/pulls/141096
This adds support for scene assets.
* Scenes can be marked like any other ID as assets (e.g. by right-clicking on a scene ID selector).
* Scenes will generate previews by rendering the view from the active camera in solid view.
Note that this requires the scene to have an active camera.
* When dragging a scene asset onto anywhere in a window (except the asset browser itself),
it will import the asset (or use the local ID) and set the scene as the active one in the window.
Pull Request: https://projects.blender.org/blender/blender/pulls/141081
This PR adds several more built-in variables for path templates:
- `scene_name`: name of the current scene.
- `camera_name`: name of the current camera.
- `node_name`: only for paths owned by a node; the name of the node.
- `blend_name_lib`: name of the blend file of the ID the path property
is on, sans file extension.
- `blend_dir`: path up to (but not including) the currently open blend
file.
- `blend_dir_lib`: path up to (but not including) the blend file of the
ID the path property is on.
Additionally, adding support for `node_name` required re-thinking the
"path template type" system a bit:
Previously, the the `PropertyPathTemplateType` of a property completely
dictated what variables were made available to it. However, if we stuck
with that system then we would need to split
`PROP_VARIABLES_RENDER_OUTPUT` into two enum items: one for "normal"
render output paths like the one that lives on the `Scene`, and one for
"node" render output paths like the ones on the File Output node.
Instead of doing that, this PR makes `PropertyPathTemplateType` only
responsible for dictating the "purpose-specific" variables. In this
case, render-specific variables like fps, resolution, etc. Then the
availability of variables like `node_name` are instead based on what
owns the path (a node or not, in this case). There are also general
variables, like `blend_name`, that are now available to all path
templates.
(Part of #133001)
Pull Request: https://projects.blender.org/blender/blender/pulls/139438
When armature is selected for custom shape of a bone, we run into
stack overflow due to recursive calls. To prevent this situation,
exclude armature object type from the custom shape list.
This also clears the `pchan->custom` pointer after loading/linking a
blend file. Otherwise a linked Armature object can still be assigned
indirectly, by renaming objects in the library file.
Fixes: #140747Fixes: #140959
Co-authored-by: Sybren A. Stüvel <sybren@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/140851
`IDP_ARRAY` properties storing `IDP_GROUP` data would not duplicate
these on copying, leading to two different array properties sharing the
same groups data...
NOTE: Uunclear how bad this issue was actually, since Blender itself will
never create such arrays of group IDProps afaik. At least could not find
any.
We really need to cleanup this code and add actual cpp-level unittests.
This patch adds support for the experimental structure types currently
used bu Geometry Nodes. Pixel nodes were declared as function nodes,
which gives dynamic structures for all their sockets. Other nodes now
explicitly declared their inputs as dynamic if not single value, while
the compositor_expects_single_value marker was removed in favor of the
StructureType::Single type.
Pull Request: https://projects.blender.org/blender/blender/pulls/140910
Saved files in 4.5 with a compositing node tree containing a Normal
Node with animated 'Dot' input crash in 5.0.
A test case with animated dot and normal inputs was added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/140908
Caused by change in `AVCodecID` enum. Our `IMB_Ffmpeg_Codec_ID` enum,
which was stored in .blend file did match `AVCodecID`. But after change
in external library headers it fails to initialize correct codec.
Function `MOV_av_codec_id_get()` was added to map these 2 enums and
the values are no longer hard coded.
Functions, that accepted `int codec_id` argument were modified to accept
`IMB_Ffmpeg_Codec_ID` or `AVCodecID` types.
Because `codec_id` was still stored as integer in DNA, get/set struct functions
were added. This way, compiler always knows what type is used and emit
error/warning when incompatible types are used.
Unfortunately, there is no way to ensure, that DNA `codec_id` field is not
accessed directly in future code other than comment.
Pull Request: https://projects.blender.org/blender/blender/pulls/140745
For files saved with the new format, the versioning can incorrectly
replace the AttributeStorage data with whatever is inside of CustomData,
even if that's nothing. So far this is only in one unlikely case for
point clouds, but these functions will soon be used for Grease Pencil
and curves.
Add a "ForUninitialized" utility function and use copy construction
correctly. This doesn't make a difference yet because we only
have trivially constructible attribute types so far.
This doesn't yet touch lines that use the `ReshapeGridElement` or
`ReshapeConstGridElement` structs, those require further cleanup
elsewhere before making such changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/140782
The metaball selection radius was inside the cube and could only
be selected with wire-frame shading.
Resolve by expanding the radius by the dimensions of the cube.
The goal here is to reduce our reliance on the existing field inferencing code
and use the new and more general structure inferencing code instead.
This patch changes patch refactors link drawing so that whether links are drawn
dashed does not depend on field inferencing anymore. Same for the invalid field
links.
I don't expect that this changes the drawing of any existing links. It just
makes it easier to fully remove the old field inferencing in the future.
Pull Request: https://projects.blender.org/blender/blender/pulls/140869
This commit cleanly splits IDProperties storage for its two very different
usages:
* "User-defined" data, also known as "custom properties". Mostly exposed
in UI and as 'dictionary' in Python scripting, these are unique to each data
(each object can have its own set of custom properties).
* "System-defined" data, mainly as backend-storage for runtime RNA
structures and properties. While these are not necessarily present in the
storage, they are registered for a data type, and therefore always available
to all data of that type through RNA access.
See #123232 for rationales, designs and alternative investigated solutions.
## User-facing Changes
When using Blender, the only noticeable change is that python-defined RNA
data are not listed anymore in the Custom Properties panels (e.g. Cycles
data).
From a Python API perspective, the main changes are:
* Runtime RNA structs defined by sub-classing `PropertyGroup` and
registering them are no more accessible through the 'dict' syntax.
* They remain accessible through a dedicated 'bl_system_properties_get()`
callback, but its usages are only expected to be for testing and
debugging.
* The result of this call will be `None` by default when there has been
nothing written into it yet, unless its optional `do_create` parameter
is set to `True`.
* Some types (like `Node`, `UIList`, etc.) cannot store raw IDProperties
anymore (using the 'dict' syntax).
## Technical Details
* Adds System idprops to some data types (IDs, ViewLayer...).
* Moves some other containers (e.g operator properties, or some UI types like
UILists) to only have system-defined properties.
* For a few specific types (like `PropertyGroup`), the same storage is used,
but exposed in RNA as both user and system properties.
* Adds RNA API accessor callback to system idprops.
* Adds a function `bl_system_properties_get()`, which wraps system-defined
idprops and gives 'dict-like' access to them. Currently mainly used by some
unittests.
* System IDProps are always ignored by RNA diffing code (and therefore
liboverride processing), as their value is already exposed through RNA
properties, and should always be processed through these RNA properties.
* Modifies bpy rna binding to use these new system idprops for property
accesses, and keeps using user-defined idprops for 'dict-type' accesses.
* Handles versioning by copying 'user idprops' (existing ones) into new
'system idprops'.
### IDProperties Split
These types keep their historic IDProperty storage for user properties,
and get a new `system_id_properties` storage for system properties:
`ID`, `ViewLayers`, `Bone`, `EditBone`, `BoneCollection`, `PoseBone`, `Strip`
These types can both be extended with registrable RNA properties, and
expose Custom Properties in the UI.
### IDProperties become System Ones
These types keep a single IDProperties storage (their DNA struct does not
change), but it is now exclusively used for system-defined properties.
`OperatorProperty`, `View3DShading`, `UIList`, `AddonPreferences`,
`KeyConfigPreferences`, `GizmoProperties`, `GizmoGroupProperties`,
`Node`, `NodeSocket`, `NodeTreeInterfaceSocket`, `TimelineMarker`,
`AssetMetaData``
Since user properties were never available in the UI for them, they lose
their 'dict-like' IDProperties access in the Python API.
### Single Storage, Exposed as Both in API
These types still use a single IDProperty storage, but expose it both as
user properties and as system ones through RNA API.
* `PropertyGroup`: They need both access APIs since they are both
used for raw IDProperty groups (the 'dict-like' access), and
internally to access data of runtime-defined RNA structs.
* `IDPropertyWrapPtr`: Done mainly to follow `PropertyGroup`.
* `NodesModifier`: cannot become purely system idprops currently, as
there is no other access than the 'raw ID properties' paths to their
values. This can be changed once #132129 is finally implemented.
Pull Request: https://projects.blender.org/blender/blender/pulls/135807
Previously, there was the issue that `SocketValueVariant` had a constructor that
took a forwarding reference as parameter. This was problematic, because this
could potentially hide copy/move constructors which is not intentional. This
patch makes sure that these special constructors are not overridden and adds two
static utility functions to make sure it's still straight forward to construct
the `SocketValueVariant` on a single line.
Clangd also warned about this case.
Pull Request: https://projects.blender.org/blender/blender/pulls/140842
Historically, the `UnifiedPaintSettings` struct has been used to
provide users the ability to set brush values at a scene level. Examples
of such attributes are the brush size, strength, and color, to name a
few.
Instead of these values being shared across all of the grease pencil,
mesh painting, and curves sculpting modes. This commit migrates the
data to the `Paint` struct, meaning that each individual mode (e.g.
Sculpt, Vertex Paint, Grease Pencil Draw) now has the ability to change
these values without affecting other modes.
While this change is large, the majority of the work is simply
refactoring access to the `UnifiedPaintSetting` struct. to ensure the
correct property is being retrieved.
Resolves#134077
Pull Request: https://projects.blender.org/blender/blender/pulls/139766
