Existing code was confusing, as existing `FileData::bmain` was not
really documented, and it could be in some cases the 'library bmain' of
a library filedata, instead of the 'main' Main (i.e. the local data of
the currently editied blendfile, the one containing all local IDs).
Now, `FileData::bmain` is always the 'main' root Main.
The new `FileData::fd_bmain` is assigned with the Main matching that
filedata and its blendfile: either the same 'main' Main (when used to
read the main edited blendfile), or the 'library' Main (when used to
read a library blendfile).
This is mostly no-op change in current code (with one exception, see
below), as this pointer is currently mostly used either:
* In a context whgere it is also always the 'main' Main, or...
* In a context where it is only used to access the (shared among all
Mains) list of `Main::split_mains`.
But having a clear and sane definition of this data gets much more
important with packed linked data (see !133801), as there we have data
that 'belong' to a library, but must e.g. be read from another FileData,
with the added complexity of different versions etc.
NOTE: The only effective change in this commit is
`read_library_file_data`, which used to assign the _library_ Main to the
new (library) `FileData::bmain`. This should not have any effect in
practice in current code, as this Main is only used to access its list
of split_mains.
Pull Request: https://projects.blender.org/blender/blender/pulls/142384
Ultimately, the issue was caused by updating sound sequence handle in
`AUD_SequenceEntry_setSound` on each new frame regardless if the
modifier data has changed.
This commit fixes the issue by implementing a means for modifiers to
check, if their parameters or inputs are changed.
This is done by storing these parameters in `StripModifierDataRuntime`
struct, that is shared between all modifier types. This is not ideal,
but it significantly simplifies dependency graph runtime store/restore
code.
Function `strip_update_sound_modifiers` passes boolean `needs_update`
to strip stack update functions. If any needs to be updated, it sets
value of `needs_update` to true allowing following update functions to
skip parameter checking to speed up the process.
Original code updated sound sequence handle twice. Once by function
`BKE_sound_update_scene_sound` then by `strip_update_sound_modifiers`.
If sound modifier is used, only `strip_update_sound_modifiers` needs to
be called, so there is condition to decide which one of these functions
is called.
Also fixes#139605
Pull Request: https://projects.blender.org/blender/blender/pulls/141595
This issue occurred because versioning was applied twice.
The history:
* First I created 05aac73b45 which fixed the issue on main (4.5 at the time), version `405, 14`
* Then I created a backport for 4.4.3 f1e829a459 which also added versioning, version `404, 32`
That means all files created with 4.4.3 (`404, 32`) already had versioning
applied. However then opening it in 4.5 applied the versioning again since that only checked
if the version was at least `405, 14`
The fix is to exclude files that have already been saved with `404, 32`
Pull Request: https://projects.blender.org/blender/blender/pulls/142208
This commit moves the freestyle edge and face mark tags to become
generic attributes, similar to other changes over the past years. The
attributes are called "freestyle_edge" and "freestyle_face", and they're
now propagated like regular boolean attributes.
Compatibility wise, forward and backward blend file compatibility are
maintained (for forward compatibility this is implemented a bit
differently than in the past because of the ongoing `AttributeStorage`
transition). In the Python API, `use_freestyle_mark` has been removed;
the attribute API should be used instead (just like bevel weights).
The BMesh (`freestyle`) accessors are removed too.
The conversions benefit from the fact that bit-wise, the old structs are
the same as `bool`, so we can convert to the old and new formats without
reallocating arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/141996
So far, only node group were able to have menu input sockets. Built-in nodes did
not support them. Currently, all menus of built-in nodes are stored on the node
instead of on the sockets. This limits their flexibility because it's not
possible to expose these inputs.
This patch adds initial support for having menu inputs in built-in nodes. For
testing purposes, it also changes a couple built-in nodes to use an input socket
instead of a node property: Points to Volume, Transform Geometry, Triangulate,
Volume to Mesh and Match String.
### Compatibility
Forward and backward compatibility is maintained where possible (it's not
possible when the menu input is linked in 5.0). The overall compatibility
approach is the same as what was done for the compositor with two differences:
there are no wrapper RNA properties (not necessary for 5.0, those were removed
for the compositor already too), no need to version animation (animation on the
menu properties was already disabled).
This also makes menu sockets not animatable in general which is kind of brittle
(e.g. doesn't properly update when the menu definition changes). To animate a
menu it's better to animate an integer and to drive an index switch with it.
### Which nodes to update?
Many existing menu properties can become sockets, but it's currently not the
intention to convert all of them. In some cases, converting them might restrict
future improvements too much. This mainly affects Math nodes.
Other existing nodes should be updated but are a bit more tricky to update for
different reasons:
* We don't support dynamic output visibility yet. This is something I'll need to
look into at some point.
* They are shared with shader/compositor nodes, which may be more limited in
what can become a socket.
* There may be performance implications unless extra special cases are
implemented, especially for multi-function nodes.
* Some nodes use socket renaming instead of dynamic socket visibility which
isn't something we support more generally yet.
### Implementation
The core implementation is fairly straight forward. The heavy lifting is done by
the existing socket visibility inferencing. There is a new simple API that
allows individual nodes to implement custom input-usage-rules based on other
inputs in a decentralized way.
In most cases, the nodes to update just have a single menu, so there is a new
node-declaration utility that links a socket to a specific value of the menu
input. This internally handles the usage inferencing as well as making the
socket available when using link-drag-search.
In the modified nodes, I also had to explicitly set the "main input" now which
is used when inserting the node in a link. The automatic behavior doesn't work
currently when the first input is a menu. This is something we'll have to solve
more generally at some point but is out of scope for this patch.
Pull Request: https://projects.blender.org/blender/blender/pulls/140705
Only major and minor versions are available at that point, not the
blendfile subversion.
Version info is available in both `bpy_library` items returned by the
context handler, as a `version` property that is a tuple of two numbers.
Co-authored-by: Campbell Barton <campbell@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/141462
LZO and LZMA is only used for compressing point caches inside of
Blender. As we already use ZSTD for compressing other data in Blender it
makes sense to remove LZO and LZMA to simplify our library requirements
(and lessen our library maintenance burden).
I've talked to Sergey about this and he suggested that I leave the LZO/LZMA
libraries and code around but effectively disabled until beta, so if there is a
huge uproar, we can easily reinstate the support.
Pull Request: https://projects.blender.org/blender/blender/pulls/141461
Node:
- Rename "Z Combine" node to "Depth Combine"
Sockets:
- First input "Image" -> "A"
- Second input "Image" -> "B"
- First Z -> "Depth A"
- Second Z -> "Depth B"
- Output Image -> "Result"
- Output Z -> "Depth"
This is a breaking change for the Python API
Pull Request: https://projects.blender.org/blender/blender/pulls/141676
The numeric levels have no obvious meaning. This removes the distinction
between severity and levels, instead there is a single list of named levels
with defined meaning.
Debug means information that's mainly useful for developers, and trace is for
very verbose code execution tracing.
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
* Remove bke, ed and wm prefixes
* Add prefixes like: geom, object, blend, lib.
* Shorten some category names
* A few log level changes to improve --log-level info output
Pull Request: https://projects.blender.org/blender/blender/pulls/140244
This commit introduces the extension modes to the transform node and
further streamlines the node properties by wrapping all props in a node
storage. Therefore, the interpolation mode has been removed from the
custom properties of the node and moved into the node storage.
Pull Request: https://projects.blender.org/blender/blender/pulls/141487
Allows to use regular constructor/destructors. And standard CPP data
like string, maps, etc.
Main is defined as non-movable and non-copyable for the time being.
The existing creating/deleting API is kept as-is, moving to direct
MEM_new/MEM_delete usages in the code is kept as a later cleanup commit.
The 'ListBase' of split-by-libraries Mains has been replaced by a VectorSet.
This is an unfortunate consequence of making Main a non-trivial C++
struct: it is no more guaranteed that next/prev pointers required for
ListBase remain immediately at the top of the struct anymore - and on
Windows they indeed don't.
So move to a more modern form of storage for split-by-libraries mains,
with a few other related changes to internal readfile code.
WARNING: This is quite a sensitive change, extensively tested locally
(including library-related changes across undos and redos, in complex
production scenes).
Pull Request: https://projects.blender.org/blender/blender/pulls/141086
This commit moves Curves and Grease Pencil to use `AttributeStorage`
instead of `CustomData`, except for vertex groups. This PR mostly
involves extending the changes from the above commit for point clouds
to generalize to other geometry types.
This is mostly straightforward, though a couple non-trivial places of
note are the joining of Grease Pencil objects (`merge_attributes`), the
"default render fallback" UV for curves objects which was previously
unused at the UI level and just ended up being the first attribute, and
the `update_curve_types()` call in the curves versioning function.
Similar to:
- fa03c53d4a
- f74e304b00
Part of #122398.
Pull Request: https://projects.blender.org/blender/blender/pulls/140936
This commit introduces the `radial_symmetry` property on the `Mesh`
datablock and simultaneously removes the `radial_symm` property in
Sculpt, Vertex Paint, and Weight Paint.
This allows users to have these symmetry values defined on a per-object
basis instead of needing to reconfigure it for each mesh.
Current values stored on the `ToolSettings` on a per-scene basis are not
copied to each mesh in a scene. This is done to avoid introducing
potentially inaccurate data to a large number of meshes at the cost of
some minor backwards incompatibility.
Part of #108107
Pull Request: https://projects.blender.org/blender/blender/pulls/141108
This patch introduces a new Extension Mode option to the Translate node,
replacing the current repeat option and adding an extra Extend mode when
the nearest boundary pixel is sampled. The option allows choosing from
Zero, Repeat, and Extend for each of the axis independently.
A new generic sample method was added to the Result class for sampling
with arbitrary interpolation and extension modes.
Pull Request: https://projects.blender.org/blender/blender/pulls/140607
The same logic was duplicated in two places, now factorize it into its
own function.
This code reads (peeks) _some_ ID info from a blendfile, without actually
reading the full ID data. And it also decides if the given ID BHead
should retained, or skipped.
This is mainly used to show a list of available IDs or assets to link or
append.
Pull Request: https://projects.blender.org/blender/blender/pulls/141103
The same logic was duplicated in two places, now factorize it into its
own function.
This code reads (peeks) _some_ ID info from a blendfile, without actually
reading the full ID data. And it also decides if the given ID BHead
should retained, or skipped.
This is mainly used to show a list of available IDs or assets to link or
append.
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
Code to read placeholder IDs from other library vs. reading actual ID
from current library was virtually the same, so de-duplicate it into its
own utils.
NOTE: Done while investigating support of embedded linked IDs in
libraries, which will require some fairly involved changes in this area.
Pull Request: https://projects.blender.org/blender/blender/pulls/141049
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
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
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
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
The versionning was not inside `do_versions_after_linking_`
which made files created before 4.2 not switch back to
`BLENDER_EEVEE`.
# Conflicts:
# source/blender/blenloader/intern/versioning_500.cc
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
Text strip had a fixed size buffer of 512 bytes to hold the displayed
text (this can be much fewer actual characters with non-English
languages). Switch to dynamically allocated buffer instead, which can
hold longer text.
In order to support forward/backward compatibility, TextVars continues
to hold the 512 byte buffer in memory. When writing out the .blend file,
dynamic text buffer is copied into the fixed one. If it is longer, the
text is truncated, so opening the .blend file in an older version
will contain the first 512 bytes of the longer text. When reading
existing files without the dynamic text buffer, it is created from the
static buffer. Conceptually this approach is similar to constraints
name length increase PR !137310.
The text strip editing code was switched to operate on the dynamic
buffer, resizing it as needed. seq::CharInfo internal struct was
switched to be more independent of the actual buffer address; now
each char entry just stores an index into the buffer instead of direct
pointer (side effect: makes the struct smaller as well).
Pull Request: https://projects.blender.org/blender/blender/pulls/140733
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
This patch removes the Dot output from the Normal node. This previously
computed negative the dot product of the normalized inputs. We are
removing it because we now have a Vector Math node that can compute the
dot product, and because it output is confusing, considering it computes
the negative of the product and it implicitly normalized the input.
The node was moved to the input category, and might be later extended to
allow normal picking from the scene or normal passes.
Fixed#132770.
Pull Request: https://projects.blender.org/blender/blender/pulls/140599
Add a footer region which contains essentially the playback and frame
range buttons from the Timeline Editor, to the following editors:
- Dope Sheet
- Graph
- NLA
- Sequencer
Available in the View menu in each editor, hidden by default.
The motivation is to provide a convenient way to access these
often used controls, and in the near future adjust these footers
to add more playback functionality related to each editor.
See PR for details and screenshots.
Pull Request: https://projects.blender.org/blender/blender/pulls/135697
At the moment, only menus and tooltips have a shadow. However, other
elements can benefit from having a shadow. This PR adds shadows to
panels in overlapped regions. Makes the default shadow size slightly
larger, but less opaque so it's not so prominent. While dragging a
panel this makes the shadow larger for a "floating" effect.
Pull Request: https://projects.blender.org/blender/blender/pulls/139847
Remove barely used theme settings for "Navigation Bar" and
"Execution Region".
These properties were only used in two areas, which already had a good
candidate to be replaced with.
Visually it should look exactly the same by default.
Part of #135192, simplifying and cleaning up theme settings.
See PR for details and screenshots.
Pull Request: https://projects.blender.org/blender/blender/pulls/140352
