This caused build errors on the docs builder, I can't seem to reproduce
locally, so revert for now and have another look at some point in the
future.
Sadly as these changes usually go, this took 5c515e26bb and
2f0fc7fc9f with it as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/132559
Not entirely straightforward, some manual edits were done since when
this library was created, some of the work was already done.
- Remove any bf_imbuf_movie paths from INC
- Add a dependency though LIB when missing
- Add public dependency to bf_imbuf in bf_imbuf_movie since it uses the
imbuf headers in its public headers.
- Fix namespace not to have underscores
context: https://devtalk.blender.org/t/cmake-cleanup/30260
Pull Request: https://projects.blender.org/blender/blender/pulls/132407
This commit exposes the "Quality" option of the Open Image Denoiser
to the user for the denoise node in the compositor.
There are a few quality modes:
- High - Highest quality, but takes the longest to process.
- Balanced - Slightly lower quality, but usually halves
the processing time compared to High.
- Fast - Further reduce the quality, for a small increase in
speed over Balanced.
Along with that there is a `Follow Scene` option which will use the
quality set in the scene settings.
This allows users that have multiple denoise nodes
(E.g. For multi-pass denoising), to quickly switch all nodes between
different quality modes.
Performance (denoising time):
High: 13 seconds
Balanced: 6 seconds
Fast: 5 seconds
Test setup:
CPU: AMD Ryzen 9 5950X
Denoising a 3840x2160 render
---
Follow ups:
Ideally the "Denoise Nodes" UI panel in the render properties panel
would be hidden if the compositor setup does not contain any
denoise nodes.
However implementing this efficiently can be difficult and so it was
decided this task was outside the scope of this commit.
Pull Request: https://projects.blender.org/blender/blender/pulls/130252
Only attribute custom property names are expected to be unique.
But also, it isn't worth asserting over this here, so just use the
regular "add" method instead of "add_new".
Pull Request: https://projects.blender.org/blender/blender/pulls/132277
Avoids some binary noise in saved files, and will some day allow us to use runtime data on read without having to explicitly clean it up (unless we refactor this into an allocated pointer instead!).
Pull Request: https://projects.blender.org/blender/blender/pulls/132190
For some reason, the file in this report had its second mix shader socket with
the identifier "Socket.001" instead of the current "Socket_001". The age of
the file roughly corresponds to when we switched to the node declaration
system. I'm not sure why it has `.` instead of `_`, since the old socket template
system also used `_` as the deliminator. I vaguely remember some issue like
this but it's been a while and I can't find anything online.
The fix is to just manually change the socket identifier. The subversion bump
isn't conceptually necessary, it's just to stop the versioning from running
more often than necessary once the file is saved again.
Pull Request: https://projects.blender.org/blender/blender/pulls/132199
This renames the `Strip` struct to `StripData` and also renames
the `Sequence::strip` member to `Sequence::data`.
This is a first step towards naming the `Sequence` struct to `Strip`.
Pull Request: https://projects.blender.org/blender/blender/pulls/132165
When moving UV seams from special custom data types to attributes,
I considered them similar to mesh selection or visibility which are
"internal" attributes that aren't accessible procedurally and are
hidden from the UI. In retrospect that was the wrong decision; users
expect UV seams to behave more like bevel weights, and that makes sense.
This PR makes UV seams accessible in modifiers (geometry nodes) by
removing the leading period from the attribute name that indicated their
internal status.
The change of the attribute name is a breaking change of the API to some
extent, even though it's technically only mesh data. To mitigate that
issue, the `mesh.attributes["name"]` lookup function is modified to
support both the old and new names. Versioning code renames the
attribute to the new name when loading older files, and renames the
new name to the old name when saving files. That handling will be
removed as a breaking change in 5.0.
Pull Request: https://projects.blender.org/blender/blender/pulls/129803
- All movie related public headers now have MOV_ prefix instead of
IMB_movie_.
- All movie related public functions now have MOV_ prefix as well,
instead of IMB_movie_ or IMB_anim_.
- IMB_anim.hh -> MOV_read.hh (also ImBufAnim -> MovieReader), and
various utility functions not related to playback were split off
into MOV_util.hh.
- Other function name tweaks for clarity, e.g. IMB_suffix_anim
-> MOV_set_multiview_suffix and so on.
- All except one usages of MOV_get_fps (nee IMB_anim_get_fps) were
ultimately just converting returned value into a float. So make
MOV_get_fps just return that directly. For the (exactly just one)
place that needs numerator and denominator, have
MOV_get_fps_num_denom.
- Code comments on the public header functions.
- Removed never-used code paths inside movie timecode proxy building
file.
It might be easier to review each commit separately.
Pull Request: https://projects.blender.org/blender/blender/pulls/132145
This commit implements most features needed for simple text editing.
Active text strip can be edited in preview by pressing tab key, which
enabled text editing mode. With this mode active, outline matches text
boundary box and cursor is drawn.
Cursor can be moved with usual keys. Pressing shift starts selection.
Selection and navigation works when text is scaled or rotated. Mirrored
text is not supported in this PR. it can be done, but the text is
unreadable that way, so I kept it simple.
Multi line text is supported. Pressing return key starts new line.
Copy/paste operator uses OS copy paste buffer, so text from other apps
can be pasted.
Text is still limited to 512 characters. Text string property still
exists in side panel and is limited to single line. Individual
characters can not be styled in different way like in 3D viewport, but
the code is mostly ready for such feature.
Ref: #126547
Pull Request: https://projects.blender.org/blender/blender/pulls/127239
Previously, code related to reading/writing movie files via ffmpeg was
scattered around: some under blenkernel, some directly in generic
imbuf headers, some under intern/ffmpeg. Some of the files were named
with not exactly clear names. Some parts not directly related to movies
were including ffmpeg headers directly (rna_scene.cc).
What is in this PR:
Movie and ffmpeg related code is now under imbuf/movie:
- IMB_anim.hh: movie reading, proxy querying, various utility functions.
- IMB_movie_enums.hh: simple enum definitions,
- IMB_movie_write.hh: movie writing functions.
- intern: actual implementation and private headers.
- ffmpeg_compat.h: various ffmpeg version difference handling
utilities,
- ffmpeg_swscale.hh/cc: scaling and format conversion utilities
for ffmpeg libswscale,
- ffmpeg_util.hh/cc: misc utilities related to ffmpeg,
- movie_proxy_indexer.hh/cc: proxies and timecode indexing for movies,
- movie_read.hh/cc: decoding of movies into images,
- movie_write.cc: encoding of images into movies.
- tests: basic ffmpeg library unit tests that previously
lived under intern/ffmpeg.
Interface changes (at C++ level, no Python API changes):
- Mostly just movie related functions that were BKE_ previously, are now IMB_.
- I did one large-ish change though, and that is to remove bMovieHandle
struct that had pointers to several functions. Now that is
IMB_movie_write_begin, IMB_movie_write_append, IMB_movie_write_end
functions using a single opaque struct handle. As a result, usages
of that in pipeline.cc and render_opengl.cc have changed.
Pull Request: https://projects.blender.org/blender/blender/pulls/132074
The issue here was sometimes an output socket of a `Group Input` node has a
reference to a data-block. The value stored on these output sockets are never
used, and thus is not exposed in the UI which made it impossible for the user to
find that there still is a data-block reference.
The root cause for this seems to have been fixed a few releases ago. I can
reproduce that the pointer was set in 3.3, but not in 3.6.
This patch only adds some versioning to remove the unnecessary data-block
references to fix old files that might have this issue (e.g. the file from the
report).
Pull Request: https://projects.blender.org/blender/blender/pulls/131900
Previously, calling `clear()` on `Map`, `Set` or `VectorSet` would remove all
elements but did not free the already allocated capacity. This is fine in most
cases, but has very bad and non-obvious worst-case behavior as can be seen in
#131793. The issue is that having a huge hash table with only very few elements
is inefficient when having to iterate over it (e.g. when clearing).
There used to be a `clear_and_shrink()` method to avoid this worst-case
behavior. However, it's not obvious that this should be used to improve
performance.
This patch changes the behavior of `clear` to what `clear_and_shrink` did before
to avoid accidentally running in worst-case behavior. The old behavior is still
available with the name `clear_and_keep_capacity`. This is more efficient if
it's known that the hash-table is filled with approximately the same number of
elements or more again.
The main annoying aspect from an API perspective is that for `Vector`, the
default behavior of `clear` is and should stay to not free the memory. `Vector`
does not have the same worst-case behavior when there is a lot of unused
capacity (besides taking up memory), because the extra memory is never looked
at. `std::vector::clear` also does not free the memory, so that's the expected
behavior. While this patch introduces an inconsistency between `Vector` and
`Map/Set/VectorSet` with regards to freeing memory, it makes them more
consistent in that `clear` is the better default when reusing the data-structure
repeatedly.
I went over existing uses of `clear` to see if any of them should be changed to
`clear_and_keep_capacity`. None of them seemed to really benefit from that or
showed that it was impossible to get into the worst-case scenario. Therefore,
this patch slightly changes the behavior of these calls (only performance wise,
semantics are exactly the same).
Pull Request: https://projects.blender.org/blender/blender/pulls/131852
Give the `IDWALK_CB_…` enum an explicit name:
`LibraryForeachIDCallbackFlag`. This way the flags are type-safe, and
it's known where values come from. This is much preferred (at least by
me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_CB_NOP` as that has the same
value and is of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int` though.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Give the `IDWALK_…` enum an explicit name: `LibraryForeachIDFlag`. This way
the flags are type-safe, and it's known where values come from. This is
much preferred (at least by me) to just having `int flags`.
Uses of `0` have been replaced with `IDWALK_NOP` as that has the same value
and is of the right type.
One invalid use of `IDWALK_CB_NOP` was detected by this change, and is
replaced by `IDWALK_NOP`.
This change might be incomplete; I gave the enum a name, and then fixed
the compiler errors.
No functional changes.
Pull Request: https://projects.blender.org/blender/blender/pulls/131865
Two commits that basically do the same thing for two `enum`s: give
them a name.
- the `IDWALK_…` enum → `LibraryForeachIDFlag`.
- the `IDWALK_CB_…` enum → `LibraryForeachIDCallbackFlag`.
This way the flags are type-safe, and it's known where values come
from. This is much preferred (at least by me) to just having `int
flags`.
Uses of `0` have been replaced with `IDWALK_NOP` and `IDWALK_CB_NOP`,
as those have the same value and are of the right type.
One invalid use of `IDWALK_NOP` was detected by this change, and is
replaced by `IDWALK_CB_NOP`. And another one in the opposite
direction.
This change might be incomplete; I gave the enum a name, fixed the
compiler errors, and then also updated assignments like `int cb_flag =
cb_data->cb_flag`. I might have missed some assignments to `int`
though.
No functional changes.
----------
I intend to land this PR as its two separate commits. I just put them in the same PR so the buildbot can handle them in one go, and we don't have a stack of highly relatled PRs.
In the future this could also apply to the `IDWALK_RET_…` enum. This one I left out, though, because a proper cleanup there would also have to include their ambiguity on whether they are bitflags (like the enums in this PR) or not. Their values and the code in `BKE_lib_query_foreachid_process()` implies they are bitflags, but in practice they are never or'ed together and just used as discrete values.
Pull Request: https://projects.blender.org/blender/blender/pulls/131803
The "use attribute" and "attribute name" IDProperties were missing
the overrideable status and the static type status. This was an oversight
from when those tags were added.
This commit fixes the flag on new modifier properties as they're created
and applies versioning to old properties. It also fixes the poll of the toggle
input attribute operator so that it isn't possible on non-editable objects.
Pull Request: https://projects.blender.org/blender/blender/pulls/131768
Currently each node's position is stored in the coordinate space of
its parent. To find the location of a node on the canvas, we have to
apply the translation of each of its parents. Also, nodes have hidden
"offset" values used while transforming frame nodes. Together,
those made the system much more complicated than necessary,
and they made the Python API ineffective.
This commit removes usage of the offset values and moves nodes
to be stored in the "global" space of the node canvas. It also resolves
some weird behavior when resizing frame nodes, and fixes a few bugs.
The change is forward compatible, so we still write files with nodes in
the old parent-space format. In 5.0 the conversion when writing can be
removed. The existing Python API also stays the same. A new
"location_absolute" property gives node locations in global space,
and changing the old property also moves the child nodes of frames.
Resolves#92458, #72904.
Pull Request: https://projects.blender.org/blender/blender/pulls/131335
This improves the `write_libraries` function in a couple of ways:
* No need to split the `bmain` which I find somewhat hard to reason about. I
think it's good if `bmain` is as read-only as possible in this write-context.
Instead a more explicit C++ data structure (`MultiValueMap<Library *, ID *>`)
is used. I think this was the only place in write-code that used
`blo_split_main`.
* Deduplication of the check that determines whether a placeholder should be
written for a specific ID.
* General cleanup to avoid unnecessarily deep nesting when iterating over IDs.
No functional changes are expected.
Pull Request: https://projects.blender.org/blender/blender/pulls/131385
Missed in 9945d511a9
The previous commit fixed files that had not yet been saved in 4.3,
however, the versioning code was not bumped which means that a user who
had a file in a version prior to 4.2 that then saved with the full
release of 4.3 would not have the corrected versioning applied for their
texture paint workspaces.
This commit re-applies similar versioning code and bumps the version
to ensure files are up to date.
Pull Request: https://projects.blender.org/blender/blender/pulls/131337
Initialise the Action's `last_slot_handle` field to its default value.
The DNA 'defaults' system doesn't do this automatically when versioning
legacy Actions, so now it's done explicitly in the versioning code.
It's fine to only apply this to the existing versioning code, and not as
a new versioning rule. Existing slotted Actions should just keep that
field to whatever it is now.
The default value was introduced in be921b8ddb
Pull Request: https://projects.blender.org/blender/blender/pulls/131498
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
