For the boid Fight rule (and when determining friend/enemy health), we
need to check if other `ParticleTarget` psys is actually boids as well
(their health data is accessed -- which is only present on boid particle
systems), otherwise NULL data access crashes.
I know, EOL, but simple crash fixers should still get a chance to get in
I think.
Could also go into LTSes.
Pull Request: https://projects.blender.org/blender/blender/pulls/126494
API: merged IMB_scalefastImBuf, IMB_scaleImBuf, IMB_scaleImBuf_threaded
into one function IMB_scale with enum IMBScaleFilter {Nearest, Bilinear, Box}
and bool "threaded" param.
Performance:
- Box filtering (nee IMB_scaleImBuf) can be multi-threaded now.
- Nearest filtering (nee IMB_scalefastImBuf) can be multi-threaded now.
Also fix performance regression on float images caused by fix in #126234
- Bilinear filtering (nee IMB_scaleImBuf_threaded) is several times faster now.
Correctness:
- Nearest and Box filtering: no longer loses half of edge pixels when scaling
up.
- Box: fixed garbage results (and possible out of bounds reads) for non-4
channel float images.
- Bilinear: no longer shifts image when scaling up.
- Bilinear: properly filters when scaling down by 2x2.
Test coverage:
- Add gtest coverage for various IMB_scale modes.
- Add a IMB_performance_test performance test, ran manually.
More details, images and performance numbers in PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/126390
Show the autokeying indicator (record button) on the Timeline header in
red when enabled. With a white outline on dark theme, or with a black
outline on light theme. The red color is user changeable.
Pull Request: https://projects.blender.org/blender/blender/pulls/126344
When the preserve_all_data_layers argument was passed, the object
would be reevaluated, assuming the type of the original object data.
However, the evaluated object type can change compared to the
original, so to reevaluate the original mesh we need to check that
the original object was also a mesh object.
Pull Request: https://projects.blender.org/blender/blender/pulls/126407
Over the year, changes in how image packedfiles were handled broke the
fallback case of missing packed data in a few places, this commit fixes
proper cleanup of invalid packed files in the Image's list of
packedfiles.
In addition, also do not create inplicit sharing info when the read data
is `nullptr`.
Part of #118145.
In preparation for removing the duplicated position arrays from the
pbvh::Tree structure, change the API functions that access the arrays
to require object arguments. This will allow retrieving data from the
original mesh or the evaluated deform mesh as necessary.
The pbvh code isn't really the right place for this, but neither is the
sculpt or paint code in my opinion, since this concept is not specific
to sculpting or painting. For now keep the API in the same place. It
probably makes sense to move a bunch of these functions at some point.
Pull Request: https://projects.blender.org/blender/blender/pulls/126370
We often have the situation where it would be good if we could easily estimate
the memory usage of some value (e.g. a mesh, or volume). Examples of where we
ran into this in the past:
* Undo step size.
* Caching of volume grids.
* Caching of loaded geometries for import geometry nodes.
Generally, most caching systems would benefit from the ability to know how much
memory they currently use to make better decisions about which data to free and
when. The goal of this patch is to introduce a simple general API to count the
memory usage that is independent of any specific caching system. I'm doing this
to "fix" the chicken and egg problem that caches need to know the memory usage,
but we don't really need to count the memory usage without using it for caches.
Implementing caching and memory counting at the same time make both harder than
implementing them one after another.
The main difficulty with counting memory usage is that some memory may be shared
using implicit sharing. We want to avoid double counting such memory. How
exactly shared memory is treated depends a bit on the use case, so no specific
assumptions are made about that in the API. The gathered memory usage is not
expected to be exact. It's expected to be a decent approximation. It's neither a
lower nor an upper bound unless specified by some specific type. Cache systems
generally build on top of heuristics to decide when to free what anyway.
There are two sides to this API:
1. Get the amount of memory used by one or more values. This side is used by
caching systems and/or systems that want to present the used memory to the
user.
2. Tell the caller how much memory is used. This side is used by all kinds of
types that can report their memory usage such as meshes.
```cpp
/* Get how much memory is used by two meshes together. */
MemoryCounter memory;
mesh_a->count_memory(memory);
mesh_b->count_memory(memory);
int64_t bytes_used = memory.counted_bytes();
/* Tell the caller how much memory is used. */
void Mesh::count_memory(blender::MemoryCounter &memory) const
{
memory.add_shared(this->runtime->face_offsets_sharing_info,
this->face_offsets().size_in_bytes());
/* Forward memory counting to lower level types. This should be fairly common. */
CustomData_count_memory(this->vert_data, this->verts_num, memory);
}
void CustomData_count_memory(const CustomData &data,
const int totelem,
blender::MemoryCounter &memory)
{
for (const CustomDataLayer &layer : Span{data.layers, data.totlayer}) {
memory.add_shared(layer.sharing_info, [&](blender::MemoryCounter &shared_memory) {
/* Not quite correct for all types, but this is only a rough approximation anyway. */
const int64_t elem_size = CustomData_get_elem_size(&layer);
shared_memory.add(totelem * elem_size);
});
}
}
```
Pull Request: https://projects.blender.org/blender/blender/pulls/126295
Part of #118145.
Similar in concept to recent commits removing the usage of
this mesh pointer in favor of fetching the data as necessary.
Also see recent discussion in a recent fix for this area:
https://projects.blender.org/blender/blender/pulls/122850.
And also note the comment for `Tree::mesh_` was incorrect.
The mesh was the original mesh, not the evaluated mesh.
Part of #118145.
There is some complexity in this area because the normals need to be
updated on the original geometry only when there is no deformation
or multires modifier. The simplest way to encapsulate that usage of
the original geometry for now was adding a separate function that
contains the lookup with a comment justifying it.
Started happening with 422dd9404f that introduced multi-threaded
conversions of src->dst (usually RGBA->YUV) format before encoding
the frame with ffmpeg. But the issue itself is not related to
multi-threading, but rather with the fact that AVFrame objects
started to be backed by an AVBuffer object (as that is needed for
threaded swscale to work).
Turns out, if a frame is backed by AVBuffer object, said buffer
might become "non writable" because it got shared (non-1 refcount).
And that happens with some ffmpeg video codecs, particularly PNG one.
Make sure to make the AVFrame objects writable inside
generate_video_frame. This follows official ffmpeg example
(doc/examples/encode_video.c) that explains why that is needed:
"the codec may have kept a reference to the frame in its internal
structures, that makes the frame unwritable. av_frame_make_writable()
checks that and allocates a new buffer for the frame only if necessary"
Pull Request: https://projects.blender.org/blender/blender/pulls/126317
Retrieve the relevant data directly from the original object's mesh
(or the evaluated SubdivCCG in that case) rather than using the
BVH tree's geometry points which we'd like to remove.
Pull Request: https://projects.blender.org/blender/blender/pulls/126284
No functional changes expected.
The function `BKE_action_get_item_transform_flags` was only ever used in a single place.
As such it could be a static function within the given file.
This reduction in scope will help with future refactors.
This is in service of fixing #126125 since the function in its current form
does not support layered actions.
Pull Request: https://projects.blender.org/blender/blender/pulls/126287
This avoids an issue in clang-cl on Windows ARM64 where an invalid pointer would be (re)used.
See #124182 for more details, but basically without this, when the vector of tiles inside changeset is resized, a reference to an invalid pointer (ie, the location in the old vector) is kept somewhere, which makes the test fail.
Pull Request: https://projects.blender.org/blender/blender/pulls/126083
The problem was the automatic instance deduplication. There were two
instance references before baking, both of which were referenced by instances.
When loading the bake, they were deduplicated, so there was only one geometry,
but the instances still referenced two.
The fix is to not do deduplication when loading instances from a bake.
* Adds two helper methods, the first replacing direct access to the
PBVHVertRef i value, the second replacing the previously removed
SCULPT_active_vertex_co_get
* Removes most trivial usage of active_vert_ref(), the remaining cases
are a bit more complex and need separate PRs
Pull Request: https://projects.blender.org/blender/blender/pulls/126186
This adds the ability to customize the default width of a group node that's
created for a node group. This feature works towards the goal of unifying the
features available to built-in nodes and node groups. We often customize the
width of built-in nodes from them to looks slightly better (e.g. to avoid
cut-off labels).
Pull Request: https://projects.blender.org/blender/blender/pulls/126054
The preview is only supported with deform modifiers which are
only supported for Mesh sculpting, so just write that implementation.
Also remove SculptSession::vert_positions which is now unnecessary.
Part of #118145.
Remove some uses of the `SculptSession` array in favor of retrieving
positions as necessary. Because of implicit sharing, avoiding unnecessary
mutable references to data can avoid copies and increased memory usage.
There are still more places to change before sculpt mode recieves that
benefit though.
