Simplify the code:
- Pull a lambda function out of a `for`-loop (making it clearer that the
loop itself is pretty simple), and
- move the `ActionUserInfo` struct into the only function that uses it.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131424
Change how we visit embedded IDs. Apparently using
`BKE_library_foreach_ID_link()` to get those IDs is not the right way to
go.
Currently the only animatable embedded IDs are node trees, so now the
code just handles those explicitly. Since this is versioning code,
there's also very little chance that there will be new types of
animatable embedded IDs before 4.4 gets released.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131424
This patch adds an option to use the new perlin noise as a noise function for the FCurve modifier.
That fixes the issue of the old noise function which could produce values outside the -0.5/0.5 range (For a strength of 1).
The old way is still preserved and will be automatically used for old files.
Because of the different noise function, I've added two more parameters to the noise modifier.
The default values for those parameters are chosen to be as close to the original noise modifier as possible.
However the match is not 1:1
## Depth
With the new noise, the parameters for "Lacunarity" and "Roughness" are available to the user.
By default they are set in such a way that changing the "Depth" results in a similar noise pattern.
## Offset and Scale
The offset and scale parameters now behave differently. Before they would also shift the phase in some way, now all they do is shift or scale the noise.
## Amplitude
The biggest difference is in the amplitude of the noise.
Overall the amplitude is a lot smaller in general than with the legacy noise, but it does fix the issue of the amplitude reaching outside the -0.5/0.5 range.
By shifting the phase I was able to find points where the amplitude reaches 0.5 but never above that.
Pull Request: https://projects.blender.org/blender/blender/pulls/129535
Move `CD_CUSTOMLOOPNORMAL` to the newly added
`CD_PROP_INT16_2D` generic attribute type. This is similar to
previous commits moving specific custom data types.
The attribute name is `custom_normal`. When the attribute with
that name is on the face corner domain, the code will interpret it
as stored in the existing deformation-invariant spherical coordinate
space.
The API remains the same, with the additional opportunity to edit
custom normal data as an attribute directly (which admittedly is fairly
unintuitive currently).
See #130484.
Pull Request: https://projects.blender.org/blender/blender/pulls/130689
Splitting the write-loop into stages makes it easier to understand, debug and time.
All the complex filtering in `gather_local_ids_to_write` is the same as before.
With this and some previous refactors, it's also much easier to have a clean `write_id`
function that should also work for embedded IDs later on.
Pull Request: https://projects.blender.org/blender/blender/pulls/130983
With the introduction of the brush assets project, there were a number
of changes to the overall API and UI that affect how user-defined
keymaps were made.
In all modes, users could either assign activating a brush via
right-clicking on the toolbar and assigning a shortcut, which would
bind to the `wm.set_tool_by_id` operator, or by manually inserting an
entry for `paint.brush_select`
For tools that have a one to one mapping for versions prior to 4.3
and ones post brush assets, we migrate the `wm.set_tool_by_id` `name`
property to the new name
For manually added entries, we swap from `paint.brush_select` to
activating the specific essential brush asset.
For Sculpt mode specifically, the number of tools in the toolbar
dropped significantly, any shortcuts that were created for these need
to be transitioned to activating a particular asset.
Finally, there are certain brushes that were expanded from a single
entry into multiple (e.g. multiple cloth brushes, paint brushes, etc)
For all of these cases, a reasonable default was picked.
Pull Request: https://projects.blender.org/blender/blender/pulls/130930
Use StringRefNull for all function arguments and return types.
Not a StringRef but StringRefNull since there is still large
interaction with C api so null-termination usually necessary.
If string is expected to be not only empty but also a null then
optional is used. This change depends on #130935.
Pull Request: https://projects.blender.org/blender/blender/pulls/131204
We've had a bunch of inconsistency between `channel_bag` and `channelbag` in the
code base. After discussion with @dr.sybren, we decided to standardize on
`channelbag` and also rename the camelcase `ChannelBag` to `Channelbag` to be
consistent with that.
This PR implements those changes.
Note that the reason we standardized on `channelbag` rather than `channel_bag`
is because it makes things clearer when stringing multiple terms together in
type and function names. For example, in `channelbag_fcurves_move()` it makes
it clear that `channelbag` describes one thing, rather than `channel` and `bag`
being two separate things.
No functional changes intended.
Pull Request: https://projects.blender.org/blender/blender/pulls/130988
Previously, only one level of panels was supported. Now, they can be nested arbitrarily.
Panels still have to come at the bottom though.
The panel color used to be just the node color darkened a bit. Now it uses the
`TH_PANEL_SUB_BACK` theme setting which is also used by panels in other places
in Blender. However, the contrast of that is a bit weaker than what we had in nodes before.
Therefore I increased the contrast a bit.
Pull Request: https://projects.blender.org/blender/blender/pulls/128886
This is a leftover from an earlier version of overrides, but is effectively dead
code currently. It was used when there were proportional diffing capabilities.
However, Bastien mentioned that this would be implemented differently nowadays
anyway if it becomes necessary again.
This simplifies the write ID loop quite significantly.
Pull Request: https://projects.blender.org/blender/blender/pulls/130928
This PR renames `ActionSlot::name` to `ActionSlot::identifier` for both DNA and
RNA, and also renames related methods, functions, constants, and comments.
The purpose of this rename is to help make it clear that this is not a "name"
in the traditional sense, but rather is a composite of the slot name + id type
for lookup purposes.
Ref: #130892
Pull Request: https://projects.blender.org/blender/blender/pulls/130740
This replaces the existing C API of `BLO_Write_IDBuffer` with a C++ API. This
helps because:
* No need for explicit freeing.
* Can use more generic `DynamicStackBuffer` utility instead of having a separate
implementation of that.
Additionally, the API is changed so that a new `BLO_Write_IDBuffer` is created
for each `ID` instead of reusing the same for multiple IDs. This simplifies the
code quite a bit and allows for better use of the RAII pattern.
I expect the performance to be the same as before. In theory, there could be a
small speedup, because the `BLO_Write_IDBuffer` is not allocated separately
anymore, but that should be negligible.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/130452
Compositor: UI: remove snapping to nodes.
Snapping nodes to other nodes behaves in a very unpredictable way, which makes most snapping options useless.
The patch removes the following:
- Snapping options `Node X`, `Node Y` and `Node XY`
- Menu `Snap Node Element`
- Menu `Snap Target`
New behavior:
- Activating `Snap` always acts as 'Snap to Grid'
Part of https://projects.blender.org/blender/blender/issues/128612
Pull Request: https://projects.blender.org/blender/blender/pulls/127667
Add a Mesh implementation of triangulation, which is currently just
implemented for BMesh. The main benefit of this is performance and
decreased memory usage. The benefit is especially large because the
node currently converts to BMesh, triangulates, and then converts back.
But the BMesh implementation is entirely single threaded, so it will
always be much slower.
The new implementation uses the principle of "never just process a
single element at a time" but it also tries to avoid processing _too_
many elements at once, to decrease the size of temporary buffers.
Practically that means the work is organized into chunks of selected
faces, but within each chunk, each task is done in a separate loop.
Arguably I went a bit far with some optimizations, and some of the
complexity isn't necessary, but I hope everything is clear anyway.
Unlike some other Mesh ports like the extrude node or the split edges
code, this generates a new mesh. I still go back and forth on that
aspect, but reusing the same mesh would have required reallocating
face attributes from scratch anyway. Implicit sharing is used to
avoid copying vertex attributes though.
The result mesh is reorganized a bit. Unselected face data comes first,
then selected triangles, then triangulated NGons, then triangulated
quads. This makes attribute interpolation and internal calculations
more efficient.
The "Minimum Vertices" socket is replaced with versioning. In the new
implementation it would have an impact on code complexity, and for a
builtin "atomic" node it makes more sense as part of the selection.
The performance difference depends on the number of CPU threads, the
number of attributes, and the selection size. As all of those numbers
go up, the benefit will grow. The "modes" also affect the performance,
obviously.
With a Ryzen 7950x, I tested performance in a few situations (in ms):
| | Selection | Before | After | Change |
| -------------------------- | --------- | ------ | ----- | ------ |
| 1.4 m quads (fixed) | 50% | 1533 | 15.9 | 96x |
| 10 m quads (shortest) | 100% | 9700 | 165.0 | 59x |
| 1 m 10-side Ngons (beauty) | 90% | 3785 | 115.9 | 33x |
| 1 m quads many attributes | 100% | 54600 | 332.3 | 164x |
In follow-up commits, I'll move other areas to use mesh triangulation
instead of BMesh. This is the last geometry node using BMesh besides
the Ico Sphere primitive.
Pull Request: https://projects.blender.org/blender/blender/pulls/112264
This PR changes the default theme color for TH_FACE_FRONT, used by the
Face Orientation overlay, to have zero alpha. That way, by default, it
can be used always and not interfere with the display of (normal) front
faces.
Pull Request: https://projects.blender.org/blender/blender/pulls/130618
This commit adds extra filtering when applying versioning code to older
files to support the Image Editor paint brushes with brush assets.
Previously, the versioning code updated all of the View3D space tools
that used a paint context to have a specific hardcoded tool name - this
unfortunately misses the default startup.blend Texture Paint brush.
Pull Request: https://projects.blender.org/blender/blender/pulls/130560
The `fmt::format` can process the format string at compile time. Currently, we
don't seem to be using that as we don't use `FMT_STRING`. Starting with C++20,
that will be the default though, and one has to explicitly opt out in places
where the string is not known at compile time using `fmt::runtime(...)`.
Currently, our code does not compile as C++20 because of that. Unfortunately, we
have many places with runtime format strings, because of i18n.
Pull Request: https://projects.blender.org/blender/blender/pulls/130392
This adds a `write_bhead` utility function and also reduces the scope of
some `BHead` variables. The separate `write_bhead` function was quite
useful for #129751 and will likely be useful in a potential separate
implementation too.
Pull Request: https://projects.blender.org/blender/blender/pulls/130457
This allows using C++ types in the region runtime data, which will
make it easier to move the remaining runtime data out of the
`ARegion` DNA type and improve code readability in these areas.
Pull Request: https://projects.blender.org/blender/blender/pulls/130196
Currently the node behaves differently from the modifier by default
because it lacks the option to use the limit surface. This is mainly
an oversight, since the option gives better results and better
performance.
This adds a new "Limit Surface" option. Because it's on by default,
there is also versioning to turn it off for existing files.
Resolves#112912.
Pull Request: https://projects.blender.org/blender/blender/pulls/130243
There is actually a valid (rare) case where a Library ID can have a `0`
versionfile value during blendfile loading: if that library only
contains 'indirect weak' linked data.
These IDs are only actually read in the library blendfile if they are
also used by some other data, otherwise they are purposedly dropped and
removed, and the library blendfile can end up never being read at all.
This would lead to a completely empty library on blendfile loading,
which can then be removed from the data-base.
NOTE: this _does not_ affect cases where the whole library is missing,
or some linked IDs from that library are not found anymore.
NOTE: This also required some changes to Cycles code itself, who is now
directly including `BKE_image.hh` instead of declaring a few prototypes
of these functions in its `blender/utils.h` header (due to C++ functions
names mangling, this was not working anymore).
Pull Request: https://projects.blender.org/blender/blender/pulls/130174
This commit adds a minimal, simple detection for future, incompatible
blendfiles (in case the header itself is modified).
The current available info does not allow to be more specific, but at
least this avoids telling users that it is not a blendfile.
In the future, the new header format designed in #129309 for Blender 5.0
should allow for a better report (since the first 16 bytes of the header
should always have the same meaning from there on).
Pull Request: https://projects.blender.org/blender/blender/pulls/129875
`writedata` used to align the written buffer size to a multiple of 4. This
causes multiple issues:
* Writes uninitialized data.
* Crash with ASAN due to a heap buffer overflow if the buffer is not any longer
than what is passed in.
* Modifies the length of the buffer which can't be undone when reading the
buffer again.
I don't know of any reason for this alignment here. I'd think that it doesn't
matter when writing to a file. If it would matter, then we should probably align
to at least 8 nowadays because that's the alignment of pointers. The original
reason for this alignment seems to be lost to history. It was already part of
the initial commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/129821
This was likely never an issue so far, as no ID type has ever been
removed (that was written in blendfiles at least), and no new BHead type
has been added since ages.
However, current behavior of the main loop in the readfile code (in
`blo_read_file_internal`) is to consider any BHead type which is not
explicitely known and handled, to be an ID BHead, and directly try to
load it as such.
This commit addresses that potential issue by validating that a BHead
code actually matches a known ID type before trying to use it to read an
ID from the file.
Issue identified while working on designs for future 5.0 forward
compatibility breaking changes in blendfile format itself.
Pull Request: https://projects.blender.org/blender/blender/pulls/129693
With the introduction of brush assets, there are now two reasons that
motivate turning this setting on by default.
* More paint brushes - Previously, there was a single paint brush in
Sculpt mode, this made the setting for general usage less needed when
compared to the 10 brushes that are now included in the essentials
pack
* Brush settings are lost on reload - Unless the changes to a brush are
saved to the asset as a default, the color for a brush is now no
longer persisted between Blender sessions. It makes little sense to
save a specific color for a specific brush on the asset level unless
it is needed for the brush functionality.
This commit ensures that the appropriate Scene flag is set for the
unified color and defines the default primary and secondary colors as
000000 and FFFFFF, respectively.
Pull Request: https://projects.blender.org/blender/blender/pulls/129127
So far asset browsers always sorted assets by name, which resulted in
barely related assets being placed together, and related assets being
scattered. This can make navigating assets tedious, and introduces a lot
of visual noise because of scattered preview image styles.
Related assets are typically put into common asset catalogs, and related
catalogs are typically organized close to each other in the catalog
hierarchy. This makes catalogs a better characteristic to sort by,
solving the mentioned issues.
For asset shelves sorting by catalogs was introduced in 471378c666. This
PR exposes this feature to the asset browser, by introducing a new
option to sort either by name or by catalog. The new default is sorting
by catalog. Within a single catalog, assets are still sorted alphabetically.
Pull Request: https://projects.blender.org/blender/blender/pulls/129480
This happens because blender 4.3 only knows about GPv3 IDs, and
therefore stores a reference to a directly linked GPv2 obdata as a GPv3
one, which cannot be found again on next file load in the GPv2 library.
The idea of this fix is, if the looup of a idcode+idname fails, to also
search for the same name but with an older, deprecated ID code.
Pull Request: https://projects.blender.org/blender/blender/pulls/129220
