Part of "improve filtering situation" (#116980), now strip scaling filter defaults to "Auto" which has logic like:
- No scale, no rotation, integer positions: Nearest (fastest)
- Scaling up by more than 2x: Cubic Mitchell, so you get nicer blending between pixels than with bilinear,
- Scaling down by more than 2x: Box, so that many pixels are averaged properly without too much aliasing,
- Otherwise: Bilinear
Existing strips that use Bilinear (which is default) get switched to Auto when loading older files.
All of this has an advantage that unless you have some special needs for your look, you can leave it at default and it will look decently good at either large up-scaling or large down-scaling, but not waste performance if you don't use any scaling at all. Previously none of the choices were good in "all cases": box (née subsampled3x3) only looks good when scaling down, cubic only looks good when scaling up, default bilinear leaves performance on the table when you don't use any scale/rotation, etc.
On something like Gold movie current edit, most of the strips effectively use Nearest now, except some that are translated into non-integer pixel positions; those stay effectively Bilinear.
Pull Request: https://projects.blender.org/blender/blender/pulls/117853
- "can not" -> "cannot" in many places (ambiguous, also see
Writing Style guide).
- "Bezier" -> "Bézier": proper spelling of the eponym.
- Tool keymaps: make "Uv" all caps.
- "FFMPEG" -> "FFmpeg" (official spelling)
- Use MULTIPLICATION SIGN U+00D7 instead of MULTIPLICATION X U+2715.
- "LClick" -> "LMB", "RClick" -> "RMB": this convention is used
everywhere else.
- "Save rendered the image..." -> "Save the rendered image...": typo.
- "Preserve Current retiming": title case for property.
- Bend status message: punctuation.
- "... class used to define the panel" -> "header": copy-paste error.
- "... class used to define the menu" -> "asset": copy-paste error.
- "Lights user to display objects..." -> "Lights used...": typo.
- "-setaudio require one argument" -> "requires": typo.
Some issues reported by Joan Pujolar and Tamar Mebonia.
Pull Request: https://projects.blender.org/blender/blender/pulls/117856
This avoids the need for manual memory management/raw pointers,
improves const correctness, improves type safety, simplifies iteration,
and simplifies the process of registering a new asset shelf type.
Pull Request: https://projects.blender.org/blender/blender/pulls/117770
This adds support for baking the volume component of a geometry. Previously,
volumes were just removed in the simulation and bake node.
On disk, each volume geometry is written to a separate `.vdb` file that is stored in
the bakes `blobs` directory and referenced from the corresponding meta `.json` file.
Technically, it would also be easy to write the volume data to the same `.blob`
files that we also write e.g. mesh attributes to. However, since `.vdb` is a well
known file format, it seems reasonable to just store it as a separate file. The
serialization code doesn't really care whether it's a separate file or embedded into
a bigger file, so this decision could be made at a higher level.
Just like with other geometry types, materials are preserved. Just note that when
using the written stand-alone .vdb files, materials are not preserved.
Currently, volume grids are not deduplicated on disk. This could be added in the
future if necessary.
Pull Request: https://projects.blender.org/blender/blender/pulls/117781
Replace: {BLENDER_RESOURCE_PATH_USER}/scripts/extensions
With: {BLENDER_RESOURCE_PATH_USER}/extensions
This makes more sense as not all extensions are scripts.
This adds hash-based data deduplication when baking in
geometry nodes. All arrays that are written to `.blob` files
are hashed. If an array is detected to have the same hash
as a previously written array, it is not written again. Instead
the same memory is reused.
We already have a similar optimization, but that only worked .with data that was already implicitly shared. Doing this kind
of deduplication with implicitly shared data has the benefit,
that the equality check is constant time. The hash based
approach implemented here requires linear time in the size
of the array, but works on all kinds of data. Both optimizations
work together. So the hashing is skipped if possible.
The hash-based deduplication primarily benefits cases where
the data is regenerated on each frame, so the data between .frames is not shared. One example used to require 2.9 GB
disk space. Now it only requires 542 MB. Additionally, the
duplicate arrays will now be implicitly shared between frames
when reading the baked data later.
An extended version of this approach which also detects partial
duplicates is implemented in #117749.
Pull Request: https://projects.blender.org/blender/blender/pulls/117768
- Use unique_ptr instead of raw pointers
- Use Vector instead of a linked list
- Use a destructor instead of a free function
- Remove the space type template-- it's much clearer to copy functional code
Pull Request: https://projects.blender.org/blender/blender/pulls/117766
Part of overall "improve image filtering situation" (#116980), this PR addresses
two issues:
- Bilinear (default) image filtering makes half a source pixel wide transparent
border around the image. This is very noticeable when scaling images/movies up
in VSE. However, when there is no scaling up but you have slightly rotated
image, this creates a "somewhat nice" anti-aliasing around the edge.
- The other filtering kinds (e.g. cubic) do not have this behavior. So they do
not create unexpected transparency when scaling up (yay), however for slightly
rotated images the edge is "jagged" (oh no).
More detail and images in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/117717
Store the 'expanded/collapsed' state of the bone collection tree view in
the DNA data of the bone collections themselves. This way the tree state
is restored when loading the file.
This commit also adds some code to the abstract tree view classes, for
supporting synchronisation of the extended/collapsed state between it
and external data. It follows the same approach as the handling of the
active element.
RNA wrappers have been added to make it possible for Python code to
expand/collapse parts of the tree.
Library overrides are supported for this property, so the
expanded/collapsed state of linked armatures can be locally saved. If
there is no override, the `is_expanded` property is still editable;
changes will not be saved to file in that case, though.
Pull Request: https://projects.blender.org/blender/blender/pulls/116940
The function name "operator poll message set" is rather troublesome, as:
- the message is only used when the operator is disabled, and
- the message is shown if the operator is disabled by any means, and not
just limited to the `poll()` function returning `false`.
A better name would be `CTX_wm_operator_disabled_msg_set`, but refactoring
that is for another time. Now at least the behaviour is documented.
No functional changes.
- Adding new repositories now differentiates between "Online" & "Local"
where adding a local repository doesn't prompt for a URL.
- Support removing repositories and their files (uses confirmation
defaulting to "Cancel" to avoid accidents).
- Show an error icon next to repositories that have invalid settings,
these repositories are now ignored until the settings are corrected,
required fields are highlighted red when they're unset & required.
- Rename "directory" to "custom_directory" since an automatic path is
used when not set - created in the users scripts directory.
- Use toggles for custom-directory & remote URL instead of relying on
the value to be left an empty string for alternative behavior.
Bake items are generally identified by their (generated) identifier.
This allows changing the name and reordering sockets without breaking
baked data.
In the future we want to have some kind of Import Bake node that
ideally automatically creates its output sockets and names them correctly.
For that to work, the baked data has to contain the user-defined names
for each socket. Those names are not used yet.
* For materials with UDIM tiles support, get array and mapping in one call
* For viewers that can use render results, add a dedicated function
* Fix potential use of render results in stencil overlay and grease pencil
Pull Request: https://projects.blender.org/blender/blender/pulls/117563
`BKE_image_scale` -- which is only used for the python API -- was
getting the `ImBuf` without providing an `ImageUser`.
This is fine, but always gets the first tile (and the current frame for sequences).
To resolve this, add an optional "frame" & "tile_index" argument so these can be specified explicitly (similar to layer_index and pass_index already used for some other API functions).
Fixes#117539 : Scaling UDIM images via Image.scale() only scales one tile
Pull Request: https://projects.blender.org/blender/blender/pulls/117549
With this patch, materials are kept intact in simulation zones and bake nodes
without any additional user action.
This implements the design proposed in #108410 to support referencing
data-blocks (only materials for now) in the baked data. The task also describes
why this is not a trivial issue. A previous attempt was implemented in #109703
but it didn't work well-enough.
The solution is to have an explicit `name (+ library name) -> data-block`
mapping that is stored in the modifier for each bake node and simulation zone.
The `library name` is necessary for it to be unique within a .blend file. Note
that this refers to the name of the `Library` data-block and not a file path.
The baked data only contains the names of the used data-blocks. When the baked
data is loaded, the correct material data-block is looked up from the mapping.
### Automatic Mapping Generation
The most tricky aspect of this approach is to make it feel mostly automatic.
From the user point-of-view, it should just work. Therefore, we don't want the
user to have to create the mapping manually in the majority of cases. Creating
the mapping automatically is difficult because the data-blocks that should
become part of the mapping are only known during depsgraph evaluation. So we
somehow have to gather the missing data blocks during evaluation and then write
the new mappings back to the original data.
While writing back to original data is something we do in some cases already,
the situation here is different, because we are actually creating new relations
between data-blocks. This also means that we'll have to do user-counting. Since
user counts in data-blocks are *not* atomic, we can't do that from multiple
threads at the same time. Also, under some circumstances, it may be necessary to
trigger depsgraph evaluation again after the write-back because it actually
affects the result.
To solve this, a small new API is added in `DEG_depsgraph_writeback_sync.hh`. It
allows gathering tasks which write back to original data in a synchronous way
which may also require a reevaluation.
### Accessing the Mapping
A new `BakeDataBlockMap` is passed to geometry nodes evaluation by the modifier.
This map allows getting the `ID` pointer that should be used for a specific
data-block name that is stored in baked data. It's also used to gather all the
missing data mappings during evaluation.
### Weak ID References
The baked/cached geometries may have references to other data-blocks (currently
only materials, but in the future also e.g. instanced objects/collections).
However, the pointers of these data-blocks are not stable over time. That is
especially true when storing/loading the data from disk, but also just when
playing back the animation. Therefore, the used data-blocks have to referenced
in a different way at run-time.
This is solved by adding `std::unique_ptr<bake::BakeMaterialsList>` to the
run-time data of various geometry data-blocks. If the data-block is cached over
a longer period of time (such that material pointers can't be used directly), it
stores the material name (+ library name) used by each material slot. When the
geometry is used again, the material pointers are restored using these weak name
references and the `BakeDataBlockMap`.
### Manual Mapping Management
There is a new `Data-Blocks` panel in the bake settings in the node editor
sidebar that allows inspecting and modifying the data-blocks that are used when
baking. The user can change what data-block a specific name is mapped to.
Pull Request: https://projects.blender.org/blender/blender/pulls/117043
Use an optional string instead of a manually allocated char pointer.
Optional is used because sometimes `nullptr` was returned. It's
still inconsistent though, because often "" or ".." was returned
instead.
This was caused by global variable `sound_cfra` not being updated when
rendering sequencer data. This global variable could cause problems in
other cases though, so it is removed. Functions that are used to set
anomation buffers now accept frame as argument.
Pull Request: https://projects.blender.org/blender/blender/pulls/117345
Adds vertex groups and basic operator support to the `GreasePencil` data
block.
Vertex groups in the `GreasePencil` ID are used as the source of truth
for vertex groups names and ordering in the UI. Individual drawings also
have vertex group lists, but they should not be modified directly by
users or the API. The main purpose of storing vertex group names in in a
drawing's `CurveGeometry` is to make it self-contained, so that vertex
weights can be associated with names without requiring the
`GreasePencil` parent data.
Vertex group operators are implemented generically for some ID types.
Grease Pencil needs its own handling in these operators. After
manipulating `vertex_group_names` the `validate_drawing_vertex_groups`
utility function should be called to ensure that drawings only contain a
true subset of the `GreasePencil` data block.
Operators for assigning/removing/selecting/deselecting vertices are also
implemented here. To avoid putting grease pencil logic into the generic
`object_deform.cc` file a number of utility functions have been added in
`BKE_grease_pencil_vgroup.hh`.
Fixes#117337
Pull Request: https://projects.blender.org/blender/blender/pulls/117476
This significantly simplifies memory management, mostly by avoiding
the need to free the memory manually. It may also improve performance,
since std::string has an inline buffer that can prevent heap
allocations and it stores the size.
Pull Request: https://projects.blender.org/blender/blender/pulls/117695
Simplify `animviz_verify_motionpaths()` as the current code structure
got in the way of me reviewing an addition to it.
Some conditions and calculations are reordered so that they don't have
to be repeated. This allowed me to reduce nesting of the code, and make
it easier to understand when exactly a motion path is reused
cache-and-all, when it's reused but gets a new cache, and when it's
freshly allocated.
I also think this removes a theoretical memory leak, as there was a code
path that would allocate a new cache without freeing the old one. This
would require a somewhat invalid data structure to begin with, but the
code path now simply doesn't exist any more. I don't think this
problematic code path was ever hit in normal use, though.
No actual functional changes.
This pull request adds the ability for users to specify input samples
on a per brush basis. The existing field in the main `Paint` struct
forces all brushes of a particular tool type to use the same value.
A new field was added to the `Brush` struct to allow for this value
to be specified there instead, and a corresponding unified value in
`UnifiedPaintSettings` has been created to allow users to use the
same value across all brushes.
Addresses #108109
Pull Request: https://projects.blender.org/blender/blender/pulls/117080
Add separate functions that deal with the vertex domain and copy vertex
groups without using the attribute API which has a large overhead when
abstracting the access of many vertex groups.
In a 1m vertex mesh with 20 vertex groups, I observed an improvement
in the node's runtime from 399 ms to 64 ms.
Also resolves#117553. That was an error when adding weight data to a
mesh without any weight data would invalidate custom data layers. That
is solved more simply now by just doing nothing in that case.
There is extra one user of shared enum definition in case this is new one
so already exist user is enough. Also using of `new` operator to construct
enum definition make this impossible to catch such leask for trivial type.
`Vector` have 4-element inline buffer so this was trivial case for <=4 items.
Pull Request: https://projects.blender.org/blender/blender/pulls/117599
This pull request adds the ability for the `propagation_steps` value
for certain automasking settings to be applied globally instead of
using the per-brush attribute.
Previously, while the flag settings were stored at the brush and global
level, the `propagation_steps` value would always change the brush
attribute even when using the global menu.
Addresses #102377
Pull Request: https://projects.blender.org/blender/blender/pulls/117316
