This extends the API for bundles in two main ways:
* Adds support for working with paths to reference nested bundles directly.
* Adds support for typed add/lookup, also taking into account implicit conversions.
Some unit tests have been added as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/142942
Use of `*.%s` in string formatting could cause the name to include
partial UTF8 sequences. While these were stripped before ID creation,
they would be set in operator properties which are expected to be UTF8.
Also remove redundant allocation.
The flags were converted with 96e549c092,
but the new values only used the new `Brush` level properties in
b472570875.
Additionally, the `CurveMapping` structs were not initialized inside
the various operations that depended on them, potentially leading to
a crash if custom curves are used.
This commit fixes what was missing from both previous commitsL
* Conversion of the HSV jitter values and their curves to the new
storage location.
* Correct initialization in relevant operators
Pull Request: https://projects.blender.org/blender/blender/pulls/142104
In #139438 we added three path template variables that get their values
from user-specified names:
- `scene_name`
- `camera_name`
- `node_name`
These names can contain characters that are illegal in filenames on some
systems, and also characters like "/" that would be interpreted as path
separators in a filepath. This can lead to unexpected outcomes.
For example, if a node's name is "Hue/Saturation" and the `{node_name}`
variable is used in a path, it would result in a "Hue" directory which
in turn contains a "Saturation" file. This is almost certainly not what
the user intended, because the slash in that name is not semantically
supposed to be a path separator.
This PR addresses this problem by splitting string variables into two
types: strings and filepaths. The contents of string variables are
sanitized to be valid filenames when substituted into a path template,
but the contents of filepath variables are left as-is.
Variables such as `blend_name`, `blend_dir`, etc. that actually
represent path components are then added as filepath variables, while
variables such as `scene_name` that represent plain strings without path
semantics are added as string variables.
Pull Request: https://projects.blender.org/blender/blender/pulls/142679
Add an explicit 'is owning' tag for libraries' FileData pointer, and
factorize code cleaning it up into a small util function.
Also allows to get rid of the weird ugly exception case in `link_end`
code for the 'root' library filedata, which is usually owned by caller
code and should not be freed here.
Pull Request: https://projects.blender.org/blender/blender/pulls/142723
The UV values for a face are contiguous anyway, there's no need
to put them into a temporary vector. Also compute them the UV
map windings in parallel, and avoid unnecessarily adding up the
size of every face.
Pull Request: https://projects.blender.org/blender/blender/pulls/142415
This commit moves 23 total existing runtime-only properties from the
`UnifiedPaintSettings` struct into the `PaintRuntime` BKE struct. This
shrinks the amount of persisted data by 224 bytes per paint mode per
scene.
In doing this conversion, fields that were previously `char` booleans
have been converted to `bool` types, and C++ math vector types have been
used where appropriate as well.
Some of these attributes may move again in the future to better
distinguish stroke level data from mode level data.
Pull Request: https://projects.blender.org/blender/blender/pulls/141366
Since 5.0 (subversion 33) `CurvesGeometry` data is read from and written
to the new attribute storage. See 68759af516.
For backwards compatibility, the `CustomData curve_data`
became `curve_data_legacy` and was only read and then converted in
the versioning code to the attribute storage format.
But since `CurvesGeometry::blend_read` is still reading
`curve_data_legacy`, we need to ensure that this data is valid.
When e.g. duplicating `CurvesGeometry`, the `curve_data_legacy` was left
uninitialized, so in an invalid state. Then the writing code would write
the embedded `CustomData` struct and the reading code would fail.
This could in theory also happen for other IDs that store legacy
custom data.
To ensure that the data is valid when reading, we do the following:
1) After the conversion code ran, we reset the legacy data. This makes
sure that we don't keep the legacy data around at runtime and
potentially when writing the embedded struct.
2) Before writing, we also reset the legacy data. This makes sure that
in case there is some garbage data in the unused struct (e.g. from
copying the ID), we don't write the garbage to file.
Pull Request: https://projects.blender.org/blender/blender/pulls/142327
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
Reordering layer nodes by drag-drop, move up/down, add new etc. swaps
layer attributes with wrong layers. This is due to mistake in map
`new_by_old_map`. Values of this map is used as indices in src array.
And keys are indices of dst array. Expected behavior is to copy attribute from
old position (`layer_i_old`) of src array to new position (`layer_i_new`) of
dst array. See: `array_utils::gather`.
Noticed during !141772.
Pull Request: https://projects.blender.org/blender/blender/pulls/141935
This PR switches out the internal scene context function
used from the sequencer. This is done in preparation for
#140271.
Using a separate context function allows us to keep the
existing `context.scene` to refer to the active scene
and use a separate context member to refer to the
sequencer scene in the workspace (which is added in #140271).
Previous attempts simply overrode the `context.scene`
to refer to a different scene than the active one in the window.
This has two issues:
1) Any operator that wants to use the active scene in the window
can't do it in the context of the sequencer. This is a problem for
example for poll functions of operators that don't have anything to
do with the sequencer.
2) For better or for worse, Blender expects the `context.scene` to
always exist. For the sequencer, we'd like to possibly have no
sequence selected.
Using a different context member for the sequencer has some
advantages:
1) Although we have to change quite a few places, it's limited to the
sequencer. We don't have to change other parts of Blender to make
things work.
2) It allows us to prepare for the future when we might want to
separate the VSE from the scene. This is a step in that direction.
Having a different context function makes it easy to find the places
that would need to be refactored.
Pull Request: https://projects.blender.org/blender/blender/pulls/141271
The asserts were added in 45ab790e80
for better error detection.
The assert was happening because the duplicated layer
was referencing frames of the source layer by default,
causing the actual user counts of the drawings to be
in an invalid state (they they were getting fixed
after the call to `duplicate_layer`, but they could remain
invalid! ).
To fix this, we ensure that the user counts are correct
after calling `duplicate_layer`. New parameters are added
to allow duplicating the frames (with empty drawings) or
duplicating the frames and the drawings.
Pull Request: https://projects.blender.org/blender/blender/pulls/142201
Resolve leak in new_from_object when preserve_all_data_layers=True and
a sub-surfaced mesh.
A copy was made, then BKE_mesh_wrapper_ensure_subdivision would return
the "mesh_eval" of the copy, leaking the mesh passed to
BKE_mesh_wrapper_ensure_subdivision.
Ref !142176
The main goal of the patch is to make the socket tooltips more useful. This is
achieved in two ways:
* Use better text formatting in the tooltip to make it easier to parse and to
better separate the current actual value from more general information about
the socket.
* Add some more information like implicit field inputs when the node is not used
currently or more details about a color.
This patch basically rewrites the entire tooltip generation, because it's quite
different from before (where we just created a single string for the entire
tooltip).
I'm using monospace for the actual current socket value and type, while the
normal font is used for general information about the socket like it's name,
description, allowed geometry types etc.
Pull Request: https://projects.blender.org/blender/blender/pulls/140540
The issue was that the `AnimData.tmp_slot_handle` had no RNA property associated with it
and so it couldn't be saved in the lib override.
The fix is to add the property. To ensure the correct code is called, most of the previous code
was replaced with a call to `blender::animrig::assign_tmpaction`
Pull Request: https://projects.blender.org/blender/blender/pulls/141395
- Tangent calculation functions no longer use the CustomData struct as
an input and output.
- The "orco" and UV map calculations are exposed as separate API
functions to avoid a confusing internal choice between the two
- Redundancy in the API is removed, function names are clarified
- Code is moved to C++ namespace
- The "orco" case is clarified in the mesh draw tangent VBO extraction
- CD_TANGENT layers are not stored in CustomData anymore, so some of
that infrastructure is removed.
- Broken logic for caching tangents in CustomData is removed. That
hasn't worked for many years, if it every worked. We could investigate
adding caching again later if that's helpful.
Overall the change is motivated by the need to move away from CustomData
for #122398. But the changes should be a general improvement that makes
the code easier to understand either way.
Testing for this PR included using the default render UV in materials,
referencing specific UV tangents by name, using the spherical position-
based tangents in a material, and baking textures (multires and normal
baking).
Pull Request: https://projects.blender.org/blender/blender/pulls/141799
Shape key interpolation was never implemented. Nowadays it's
probably better to implement similar features in different ways
rather than extending this system. Also some layer mapping
generation was unused. The motivation for this is easing some
cleanups to make this modifier less directly reliant on CustomData.
Pull Request: https://projects.blender.org/blender/blender/pulls/142131
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
Fixes crash in the remesh operator by moving mesh spatial organization
to appropriate execution contexts and using proper memory handling in
spatial organization's face offset calculations.
Pull Request: https://projects.blender.org/blender/blender/pulls/141842
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
This fixes the anonymous attribute lifetime inferencing for the closure zone and
the evaluate closure node. It also adds new regression tests for cases where a
closure outputs a field.
Pull Request: https://projects.blender.org/blender/blender/pulls/141925
Different operations may need to lock different part of the interface,
e.g. for rendering, the image editor may still need refreshing while the
interface is locked, but when baking data into a scene, the image editor
needs to be locked because it is not thread safe to get data from a
partially evaluated depsgraph.
This is a better fix on top of 7c8b8b2457
that addresses the root cause with more flexibility for future
operations that requires different interface locking strategy as
well.
Pull Request: https://projects.blender.org/blender/blender/pulls/141866
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
