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
The theme property for group socket nodes was set to `#000000` for
default themes, which looked out of place against the other node
header colors. This patch adds colors to both the Blender Dark & Light
themes that should resemble their counterparts before 2ea3cd2188.
Colors:
Blender Dark - `#1d1d1d`
Blender Light - `#3d3d3d`
Pull Request: https://projects.blender.org/blender/blender/pulls/141011
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
This patch removes the Texture node from the compositor, which was based
on the legacy Internal Textures system in Blender. The main motivation
for removing this node is as follows:
- Procedural texturing nodes that previously existed in shading and
geometry nodes are now supported in the compositor, which cover 95% of
what is previously possible using and even adds new possibilities like
Gabor, Bricks, and various improvements to existing texture types.
- The old texture system did not support GPU evaluation, so it was
always computed and cached on the CPU, which causes bad performance
especially for interactive use in the viewport compositor. While the
new nodes are fully GPU accelerated and do not require any caching.
- The Texture node didn't support Texture nodes, so it was not fully
supported and we so far had a warning about that.
- The general direction in Blender is to remove the old texture system,
and the compositor was one of the last main users of it. 5.0 is thus
the ideal time to remove such use.
- The Texture node was always and still is a source of bugs, since it
relies on proper tagging for cache invalidation and updates, which is
so far not perfect. It also suffers from UI/UX issues, since it needs
to be adjusted from the properties panel, which can break if there are
other texture nodes in the context.
This is a breaking change and no versioning was attempted since:
1. It is impossible to get the same results as before due to the use of
different random number generators, so any versioning would just give us
the general look.
2. The Texture node supports a lot of possible configurations. For
instance, each general texture can have many options for the basis type,
and each basis type might have multiple options. So versioning all of
that will take a lot of time, code, and effort.
Pull Request: https://projects.blender.org/blender/blender/pulls/140545
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
Maths nodes in files saved in late v4.5 will load as undefined in 5.0.
That's because versioning ran for versions before 4.5, not after. To fix
this, we move versioning to 5.0 to cover such cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/140868
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
Recently, panel styling was moved to a global setting instead of being
per-editor. However, the panel's title and labels inside still rely on
the per-editor region's text and title settings.
Move panel title and text colors to the global "Panel" settings.
See PR for details and screenshots.
Part of #135192
Pull Request: https://projects.blender.org/blender/blender/pulls/140726
