Needed to implement GPv3 version of "Bake Object Transform to Grease
Pencil"
Doesn't implement the `Surface` option, as that is not used in the
previously mentioned operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/126255
Parallelize loops to calculate max falloff and transfer
falloff from vertices to faces. These aren't a bottleneck
but performance should be slightly improved anyway.
This operator sets the new default group node width (from e842966c5e) based on
the parent group node. This makes it easier to initialize the value. Without
this, one had to create and delete the group node potentially many times to find
a good default width.
Pull Request: https://projects.blender.org/blender/blender/pulls/126239
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
Hair objects did not take the curves into account that could go
outside the bounds set by the keys of the curves. These bounds
are used in the dynamic bvh, leading to clipped curves in the
viewport.
Pull Request: https://projects.blender.org/blender/blender/pulls/126157
71f2229b0 added a workaround for video files that contain entirely
incorrect stream duration, and corrects that by using container
duration instead. However it used math of `seconds=frames*rate` instead
`seconds=frames/rate`, effectively always ending up falling back to
container instead of stream duration.
Pull Request: https://projects.blender.org/blender/blender/pulls/126368
There is a reason for the bitwise operator but it's not explained:
The attribute_foreach function callback has side-effects that the
compiler does not know about (everything is const). Simply replacing
the bitwise operator will cause the second term to be skipped, which
breaks tests due to missing attributes.
Now the term is explicitly evaluated first, then combined with actual
boolean operator.
Pull Request: https://projects.blender.org/blender/blender/pulls/126366
OptiX has accepted Catmull-Rom curve data natively since OptiX 7.4, but due to the previous conversion to B-Spline code, the format that data is fed to OptiX wasn't optimal.
Each curve segment was put in the vertex buffer as four independent control points, even though continuous segments actually share control points between each other. This patch compacts that so shared control points only occur once in the vertex buffer.
This compact form uses less memory and also allows OptiX to easily identify segments that belong together into a curve (those where the step between indices is one).
Pull Request: https://projects.blender.org/blender/blender/pulls/125899
Previously when renaming an IDProperty the existing paths in the
animation/driver system isn't updated, this leads to missing animation
after renaming the property. Now `BKE_animdata_fix_paths_rename_all`
will be called so the animation system records the updated name.
Pull Request: https://projects.blender.org/blender/blender/pulls/125474
The value used for the the library path was being evaluated by CMake
instead of forwarding the value to the shell expression (as intended).
This meant any build-time binaries that depended on the environments
library-path would failed to run.
The issues was that the `get_item_transform_flags` iterated over the `curves`
list of the action, ignoring the new structure.
Fixed by using the `action_foreach_fcurve` and modifying that to work on legacy actions as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/126357
This only works with GCC and has only been tested on Linux. The main goal is to
automatically generate the code coverage reports on the buildbot and to publish
them. With some luck, this motivates people to increase test coverage in their
respective areas. Nevertheless, it should be easy to generate the reports
locally too (at least on supported software stacks).
Usage:
1. Create a **debug** build using **GCC** with **WITH_COMPILER_CODE_COVERAGE**
enabled.
2. Run tests. This automatically generates `.gcda` files in the build directory.
3. Run `make/ninja coverage-report` in the build directory.
If everything is successful, this will open a browser with the final report
which is stored in `build-dir/coverage/report/`. For a bit more control one can
also run `coverage.py` script directly. This allows passing in the
`--no-browser` option which may be benefitial when running it on the buildbot.
Running `make/ninja coverage-reset` deletes all `.gcda` files which resets the
line execution counts.
The final report has a main entry point (`index.html`) and a separate `.html`
file for every source code file that coverage data was available for. This also
contains some code that is not in Blender's git repository. We could filter
those out, but it also seems interesting (to me anyway), so I just kept it in.
Doing the analysis and writing the report takes ~1 min. The slow part is running
all tests in a debug build which takes ~12 min for me. Since the coverage data
is fairly large and the report also includes the entire source code, file
compression is used in two places:
* The intermediate analysis results for each file are stored in compressed zip
files. This data is still independent from the report html and could be used
to build other tools on top of. I could imagine storing the analysis data for
each day for example to gather greater insights into how coverage changes over
time in different parts of the code.
* The analysis data and source code is compressed and base64 encoded embedded
into the `.html` files. This makes them much smaller than embedding the data
without compression (5-10x).
Pull Request: https://projects.blender.org/blender/blender/pulls/126181
This extends the `GreasePencilDrawing` rna type using python.
The goal is to add an API that allows developers to transition to
the new grease pencil API a bit more smoothly.
Adds the following endpoints to the `GreasePencilDrawing`:
* `drawing.strokes`: Returns a list/slice of `GreasePencilStroke`s in the drawing.
Adds a python class `GreasePencilStroke`:
* `stroke.points`: Returns a list/slice of `GreasePencilStrokePoint`s.
* Getters/Setters of attributes for this stroke:
* `stroke.cyclic`
* `stroke.material_index`
* `stroke.select`
* `stroke.softness` (used to be `hardness`)
* `stroke.start_cap`
* `stroke.end_cap`
* `stroke.curve_type`: The type of curve: `POLY`,`BEZIER`,`CATMULL_ROM`,`NURBS`.
* `stroke.aspect_ratio`
* `stroke.fill_opacity`
* `stroke.fill_color`
* `stroke.time_start`
* High-level functions:
* `stroke.add_points(count)`: Adds `count` points at the end of the stroke.
* `stroke.remove_points(count)`: Removes `count` points from the end of the stroke. Note that this will not remove the stroke if the count is greater than the number of points in the stroke. A stroke has at least 1 point. Removing strokes can be done from the drawing.
Adds a python class `GreasePencilStrokePoint`:
* Getters/Setters of attributes for this point:
* `position`
* `radius`
* `opacity`
* `select`
* `vertex_color`
* `rotation`
* `delta_time`
Note that `GreasePencilStroke` and `GreasePencilStrokePoint` are not stored in the file and don't have an RNA API. This means that they are not compatible with e.g. `layout.prop`.
This API should not be used for performance critical code. It's likely
even slower than the python API from 4.2.
There will be migration documentation for addon developers here:
https://developer.blender.org/docs/release_notes/4.3/grease_pencil/#python-api-changes
Pull Request: https://projects.blender.org/blender/blender/pulls/125599
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
No functional changes expected.
This PR refactors the code by:
* passing things by reference if they cannot be a `nullptr`
* Managing indentation by returning early or continuing.
* Cleaning up comments
* Indicating ListBase element types in the declaration
This is in service of #126125 for which the `get_item_transform_flags`
needs to be passed a slot handle as well.
Pull Request: https://projects.blender.org/blender/blender/pulls/126291
There were a couple of regressions when using the environment render
pass.
- Not working when film transparency was enabled
- Deferred geometry didn't occlude the background
This PR splits the world background shader (eevee_surf_world) into two
shaders. One clears background and render passes and a second one that renders
the background and the environment render pass.
The second shader is moved after the deferred pipeline and an early
depth test is used to occlude the background and environment pass.
NOTE: render test reference images needs to be updated.
Pull Request: https://projects.blender.org/blender/blender/pulls/126274
On X11 windowing systems there's no `MessageBox` prompt like on
win32 that could show users that they have unsupported GPUs,
this leads to confusion to them as they typically don't open
blender from a command line so none of the messages could be
available. This patch utilizes `system->showMessageBox` to display
a GUI message box telling the user that the GPU is unsupported.
Pull Request: https://projects.blender.org/blender/blender/pulls/126220
The poll functions for theme & key-map preset operators used functions
documented not to be used on redraw draw and could make the interface
slow when extensions (for example) are stored on a network file-system.
While the file-system lookups are typically cached, it can still cause
occasional stuttering or hanging. In general scanning the file-system
on poll should be avoided.
Regression in [0] which displays the filename for the active
theme but still used the label internally.
This meant actions such as removing the theme would not always apply
to the name being displayed.
- Adding a new theme was not setting it active.
- Detecting if a theme was built-in used the run-time label as a lookup.
- Theme removal first require it to be re-selected.
[0]: 0bb6317035
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.
