This adds a `VArray::from_std_func` next to the existing `VArray::from_func`. It
does almost the same but inserts some type erasure by using `std::function`
which avoids the need to instantiate the full virtual array. This has is a bit
slower at run-time, but in practice there are some cases where it doesn't
matter. Currently, this patch reduces binary size by ~35kb. Not too much, but
still good or such a simple change.
Pull Request: https://projects.blender.org/blender/blender/pulls/146011
When reporting a crash with unknown exception we just display
UNKNOWN EXCEPTION which is not as helpful as it could be. this
commit adds the actual exception code for all reports.
Also adds a msvc specific exception to the known list for easy
identification.
the exception record from #145762 goes from
ExceptionCode : UNKNOWN EXCEPTION
to
ExceptionCode : Microsoft C++ Exception (0xe06d7363)
These don't really work as scene linear with sRGB transfer function for e.g.
ACEScg, there are not enough bits. If you want wide gamut you need to use
float colors.
Pull Request: https://projects.blender.org/blender/blender/pulls/145763
Functions for convert between the color types and ostream support are
now outside the classes.
Many files were changed to fix cases where direct includes for headers
were missing.
Pull Request: https://projects.blender.org/blender/blender/pulls/145756
This PR adds code for setting the Quality of Service (QoS) level of the
process on Windows. This can, e.g., make sure that on hybrid systems
P-cores are utilized even when the app window is out of focus.
In the following cases, it is adjusted from the default behavior:
- In wm_jobs.cc the QoS level is raised while a priority job is running.
- The command line option `--qos [high|eco|default]` can be used to
change the QoS level of the process.
- By default, the QoS level is raised for the EEVEE performance tests,
as they check viewport rendering performance and would otherwise be
reliant on never going out of focus to not get a downgraded QoS level.
By default, they are created with an out of focus window at the time
of landing this PR. This PR makes sure that they actually measure the
animation replay performance attainable during real-world use.
Pull Request: https://projects.blender.org/blender/blender/pulls/144224
The pattern of transforming many position vectors at once is quite
common, both with separate source and result arrays, and when modifying
an array in place. In some cases at least we used a separate function
with a consistent name across files, but there were also many duplicate
parallel transform implementations.
This commit adds these utilities to the BLI_math_matrix.hh API and uses
them where many positions from contiguous arrays are transformed at
once. While there might be a more ideal location for these utilities,
it's consistent with 3936d7a93e, and certainly better
than duplicating them.
This also reduces binary size of my build by 15 KB.
Pull Request: https://projects.blender.org/blender/blender/pulls/145352
Previously, `VArrayImpl` had a `materialize` and `materialize_to_uninitialized`
function. Now both are merged into one with an additional `bool
dst_is_uninitialized` parameter. The same is done for the
`materialize_compressed` method as all as `GVArrayImpl`.
While this kind of merging is typically not ideal, it reduces the binary size by
~200kb while being basically free performance wise. The cost of this predictable
boolean check is expected to be negligible even if only very few indices are
materialized. Additionally, in most cases, this parameter does not even have to
be checked, because for trivial types it does not matter if the destination
array is already initialized or not when overwriting it.
It saves this much memory, because there are quite a few implementations being
generated with e.g. `VArray::from_func` and a lot of code was duplicated for
each instantiation.
This changes only the actual `(G)VArrayImpl`, but not the `VArray` and `GVArray`
API which is typically used to work with virtual arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/145144
When creating a directory recursively (via
`BLI_file_ensure_parent_dir_exists()` or `BLI_dir_create_recursive()`,
filter out errors that indicate that the directory already exists.
This is now also covered by a unit test.
I've also removed `BLI_assert(BLI_exists(dirname) == 0);` from
`dir_create_recursive()` (the workhorse for the above-mentioned
functions), for two reasons:
- The function is only used in an "ensure this directory exist"
context, so the directory existing should be fine, and
- the assertion doesn't guarantee that the subsequent call to
`mkdir()` actually succeeds. Race conditions between Blender and
other processes (potentially on other computers, when using
networked filesystems) will make such a precondition test
unreliable.
This is a followup of 00abaa571a.
Pull Request: https://projects.blender.org/blender/blender/pulls/145173
Replacing the "cyclic offsets" cache from cfb8696a73.
That was more information than was necessary in the end.
This is implemented by de-duplicating the existing "contains"
function that's implemented twice for boolean virtual arrays.
Pull Request: https://projects.blender.org/blender/blender/pulls/144761
The existing suppression from [0] wasn't working for release builds.
Explicitly suppress the warning instead of using a dummy check.
Ref !144898
[0]: 9ad46ebd2f
`asset_shelf::regiondata_duplicate()` first creates a shallow copy of
the `AssetShelf`, including its `AssetShelfSettings` member. So the
contained pointer point to the same memory.
While this is a rather unusual case for a copy assignment operator to
consider, I think this is fine since the API allows these shadow copies.
This is a bit of a consequence of mixing C and C++ style memory
management.
Pull Request: https://projects.blender.org/blender/blender/pulls/144613
Point Caches (used by particle system, cloth, boids etc.) are now
always compressed, uzing zstd coupled with lossless data filtering.
- This is both smaller cache files _and_ faster than the old
"Heavy" compression mode,
- And smaller data files and same or slightly faster speed than
using no compression at all,
- There was not much difference between compression levels once
data filtering got added, so option to pick them was removed.
- So there's no downside to just always using the compression,
which makes for a simpler UI.
- RNA change: removes PointCache.compression property.
More details and cache size / performance numbers in the PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/144356
Now that every socket type uses `SocketValueVariant` since #144355, the
parameter access code can be simplified a bit.
This also adds a new `GeoNodesMultiInput<T>` type that's used to access the list
of inputs value multi-input sockets.
Pull Request: https://projects.blender.org/blender/blender/pulls/144409
Depend only on `getcwd` and `chdir` rather than attempting to also
consider the `PWD` environment variable.
There's situations where these differ, and most easily seen when running
the Python tests. Calling `pathlib.Path.cwd()` will return something
like `/home/blender/git/blender-vexp/build_asserts/tests/python` while
PWD is `/home/blender/git/blender-vexp/build_asserts`. In this case,
calling `getcwd` will match what Python shows.
Additionally, this now matches what Windows and Mac do for these
affected APIs.
Pull Request: https://projects.blender.org/blender/blender/pulls/144235
Replaces the `FPS` macro with `scene->frames_per_second()`.
The macro has two major issues:
* It hides that it depends on a `Scene *` variable named `scene`.
* It makes debugging harder.
This is now replaced with a member function on the scene.
Pull Request: https://projects.blender.org/blender/blender/pulls/144127
Waveform, Parade and Vectorscopes were calculated by copying the
rendered image, transforming it into display space, and calculating
the the scope from that. On large resolutions, this
copy+transform+free of the image was taking up majority of the time.
Especially for default case when the display transform is a no-op.
Change the code so that display transform, if needed, is done directly
inside scope calculation, without needing a full-size temporary image.
Additionally, the vectorscope calculation was single threaded.
Multi-thread it by doing a parallel reduction, where each job
calculates their own scope image, and they are merged. Since job
payload is fairly large (512x512 bytes), make jobs pretty large
(256k pixels each).
Time (in ms) taken to calculate scope at 4K resolution (Ryzen 5950X,
Windows). Default color management settings:
- Waveform, PNG/SDR: 5.5 -> 5.2
- Waveform, EXR/HDR: 33.5 -> 10.3
- Vectorscope, PNG/SDR: 32.4 -> 4.5
- Vectorscope, EXR/HDR: 53.2 -> 9.8
Timings when additional color space management is needed (display
space set to Display P3, sequencer kept at sRGB):
- Waveform, PNG/SDR: 29.5 -> 10.9
- Waveform, EXR/HDR: 67.6 -> 10.9
- Vectorscope, PNG/SDR: 56.8 -> 12.0
- Vectorscope, EXR/HDR: 85.9 -> 13.4
This also fixes calculation of waveform / vectorscope on float (HDR)
images that have alpha channel; the scope was wrongly calculated on
premultiplied color values, which was not consistent with how it was
calculated on the byte images.
Pull Request: https://projects.blender.org/blender/blender/pulls/144059
This fixes an edge case in how the max acceptable edit distance is calculated
for deletions in fuzzy search, wherein the padding added to the max error count
could be negative when the query was longer than the matched term, producing a
max distance of zero.
This came up in chat a while back, where someone noted that, in the compositor,
searching for "bluir" wouldn't return the blur nodes; "blu" worked, "blui"
worked, but "bluir" returned no results, despite all three having equal edit
distances (1 insertion, 1 substitution, and 1 deletion, respectively). The edit
distance metrics themselves are calculated correctly; the issue was just with
how the distance threshold was set.
Pull Request: https://projects.blender.org/blender/blender/pulls/143741
Since [0], removing degenerate points at the beginning of the hull
would re-order points so the last were moved to the beginning.
While this isn't an error, having the resulting hull *sometimes*
re-ordering it's result based on internal error correction isn't ideal.
Document that the first point in the hull has the lowest Y value and
update tests to ensure this.
Also correct the doc-string regarding the hulls cross-product
and tests this is working as documented.
[0]: 87f9fd8fb3
Resolve an error in `BLI_convexhull_2d` where *almost* overlapping
points could result in the hull including *concave* points.
This tended to happen with larger polygons in the range of 100-500.
The regression is likely caused by [0] since this optimization
relies on the input not having any concave coordinates.
[0]: 888c4d0766
Currently, bundles can only store socket values of Geometry Nodes. However, it
can make sense to store other kinds of data too. Specifically, this patch adds
support for storing arbitrary internal data in a bundle. This is useful when
storing e.g. the physics world when implementing a proper physics solver for
Geometry Nodes (like in #143171).
One can still see that the data exists in Geometry Nodes in the tooltip, but one
can't extract it. Built-in nodes can still read that data.
Storing built-in data in bundles can also be done as an alternative to having a
new "internal data socket" as we talked in a workshop in the past:
https://code.blender.org/2024/11/geometry-nodes-workshop-october-2024/#internal-data-sockets
A bundle still has to be copyable. Internal data is expected to use implicit
sharing. That way copying it just requires increasing the user count of the
data.
Pull Request: https://projects.blender.org/blender/blender/pulls/143472
When transforming a geometry, we often apply the transposed inverse
to normals / custom normal data. However, that matrix can still contain
scale from the original matrix. That scale has to be removed so we can
avoid also scaling the normals.
I used the opportunity to remove the duplication between mesh and curves
processing of the custom normals, and to formalize an optimization to
skip the final normalization of each vector if the transform is such
that it isn't necessary. The new functions don't fit beautifully into
their public headers, but I don't know of a better place for them.
Pull Request: https://projects.blender.org/blender/blender/pulls/142896
Use `BLI_strncpy_utf8` & `BLI_snprintf_utf8` for fixed size buffers in
DNA and screen data structures such as panels, menus & operators.
This could be considered a fix as copying a UTF8 string into a smaller
buffer without proper truncation can create an invalid UTF8 sequence.
However identifying which of these users are likely to run into would
be time consuming and not especially useful.
