The runtime backup/restore logic was slightly wrong: it is possible that
an object requires light linking runtime but does not need light linking
itself. This is typical configuration for the receivers/blockers.
Modified the logic so that the evaluated object light linking is allocated
if there was a runtime field needed.
This required to make it so light linking evaluation takes care of feeing
the light_linking if it is empty. The downside of this approach is a
redundant allocation from the object backup when removing light linking
collection from emitter. But this is not a typical evaluation flow, and
the more typical flows are cheap with this approach.
Pull Request: https://projects.blender.org/blender/blender/pulls/108261
Extract vendor, driver and device information from the physical device
properties.
Note that driver version is implementation dependent and might fail as
it is unclear which driver is being used. An open source driver could
store the driver version in a different way than a closed source driver.
But as it is not clear which driver version is being used it might
extract the incorrect version.
To solve this issue we check if the extracted version makes sense
depending on the version schema of the driver and if they don't match we
use another approach.
Pull Request: https://projects.blender.org/blender/blender/pulls/107872
The issue was that `is_rendering` was used as a proxy to check
whether the interface is locked. Locking the node editor during rendering
is not necessary, but it currently is necessary while baking, because
baking changes original data from a different thread.
The solution is to use the already existing mechanism to tell Blender
which regions should be locked when the interface is locked.
Resolve an issue where a high resolution texutre 16k x 8k
did not update in metal due to integer overflow of size parameter.
This patch contains several changes to address size correctness
across multiple use cases within the Metal backend.
Authored by Apple: Michael Parkin-White
Pull Request: https://projects.blender.org/blender/blender/pulls/108238
When the new name was clipped to make room for the number,
the string was clipped by the number size (including the null byte).
Store the length in `numlen` instead of the size (including null byte).
Unify the handling of masks for affected curves in a few of the sculpt
brushes. In the grow shrink brush, replace a more custom "influences
per thread" solution. In the puff brush, use a full array of weights,
and build the mask earlier. In the snake hook brush, use the selection
properly (I observed a 2-3x improvement with a small selection).
The mask was sliced, but the original mask was used from before the
slicing, causing an unsliced mask to be used with the new offsets.
This caused a crash in the hair styles demo file.
Windows file associations using ProgID, needed because of the launcher.
This fixes "pin to taskbar" and Recent Documents lists, allow per-
version jump lists and an "Open with" list with multiple versions.
Pull Request: https://projects.blender.org/blender/blender/pulls/107013
Goals of this refactor:
* Reduce memory consumption of `IndexMask`. The old `IndexMask` uses an
`int64_t` for each index which is more than necessary in pretty much all
practical cases currently. Using `int32_t` might still become limiting
in the future in case we use this to index e.g. byte buffers larger than
a few gigabytes. We also don't want to template `IndexMask`, because
that would cause a split in the "ecosystem", or everything would have to
be implemented twice or templated.
* Allow for more multi-threading. The old `IndexMask` contains a single
array. This is generally good but has the problem that it is hard to fill
from multiple-threads when the final size is not known from the beginning.
This is commonly the case when e.g. converting an array of bool to an
index mask. Currently, this kind of code only runs on a single thread.
* Allow for efficient set operations like join, intersect and difference.
It should be possible to multi-thread those operations.
* It should be possible to iterate over an `IndexMask` very efficiently.
The most important part of that is to avoid all memory access when iterating
over continuous ranges. For some core nodes (e.g. math nodes), we generate
optimized code for the cases of irregular index masks and simple index ranges.
To achieve these goals, a few compromises had to made:
* Slicing of the mask (at specific indices) and random element access is
`O(log #indices)` now, but with a low constant factor. It should be possible
to split a mask into n approximately equally sized parts in `O(n)` though,
making the time per split `O(1)`.
* Using range-based for loops does not work well when iterating over a nested
data structure like the new `IndexMask`. Therefor, `foreach_*` functions with
callbacks have to be used. To avoid extra code complexity at the call site,
the `foreach_*` methods support multi-threading out of the box.
The new data structure splits an `IndexMask` into an arbitrary number of ordered
`IndexMaskSegment`. Each segment can contain at most `2^14 = 16384` indices. The
indices within a segment are stored as `int16_t`. Each segment has an additional
`int64_t` offset which allows storing arbitrary `int64_t` indices. This approach
has the main benefits that segments can be processed/constructed individually on
multiple threads without a serial bottleneck. Also it reduces the memory
requirements significantly.
For more details see comments in `BLI_index_mask.hh`.
I did a few tests to verify that the data structure generally improves
performance and does not cause regressions:
* Our field evaluation benchmarks take about as much as before. This is to be
expected because we already made sure that e.g. add node evaluation is
vectorized. The important thing here is to check that changes to the way we
iterate over the indices still allows for auto-vectorization.
* Memory usage by a mask is about 1/4 of what it was before in the average case.
That's mainly caused by the switch from `int64_t` to `int16_t` for indices.
In the worst case, the memory requirements can be larger when there are many
indices that are very far away. However, when they are far away from each other,
that indicates that there aren't many indices in total. In common cases, memory
usage can be way lower than 1/4 of before, because sub-ranges use static memory.
* For some more specific numbers I benchmarked `IndexMask::from_bools` in
`index_mask_from_selection` on 10.000.000 elements at various probabilities for
`true` at every index:
```
Probability Old New
0 4.6 ms 0.8 ms
0.001 5.1 ms 1.3 ms
0.2 8.4 ms 1.8 ms
0.5 15.3 ms 3.0 ms
0.8 20.1 ms 3.0 ms
0.999 25.1 ms 1.7 ms
1 13.5 ms 1.1 ms
```
Pull Request: https://projects.blender.org/blender/blender/pulls/104629
It was still possible to create liboverrides of Scene IDs from the
Outliner.
Scenes are currently not officially supported, RNA API allows to create
them for experimental purposes, but UI should not.
The main issue was the fact that if a Scene is overridden, it's content
will be fully invalidated when updating the liboverride at the end of
the file reading process. Since the FileData keeps a pointer to the
active view layer, it needs to be udated then.
As a side consequence, the liblinking of global data also needs to
happen before liboverrides are updated.
Embedded IDs (master collection of scene, etc.) do not exist in the Main
data-base. However, their tags should follow these from their owners. So
e.g. if a scene is in Main, its master collection should not be tagged
as no-main.
NOTE: this is somewhat also related to our ID tags sanitizing TODO task
(#88555).
Found while invesigating #107913.
- Samplerate -> Sample rate: should be two words.
- "Falloff type the feather": typo.
- JPEG, OpenJPEG and JPEG 2000 are the official spellings of the
respective projects.
- "... boundary of image(including ...": missing space.
- "Points in . direction (cannot be changed ...)":
Plural, it is a collection of multiple points. Also do not use
contraction for "cannot".
- The Bevel modifier's "Only Vertices" option was replaced by a
Vertices mode in 2.90.
- "Metaball Types": affects one object, should be singular.
- "Metaball data-block to defined blobby surfaces": typo.
- "Wire Size": this option has nothing to do with wireframes, I suppose
it's an old terminology.
- "... (for negative speed.)": remove trailing period.
- "Smooth factor effect": the prop describes a factor for an effect,
not an effect for a factor.
- "... assigned to their vertices(ensures ...": missing space.
- "... used when faces have the ObColor mode enabled": ObColor is not
used anywhere else in the UI (since Blender 2.50).
- "Effect Children": typo -> Affect.
- "Distort Min/Max": copy-pasted from another pair of properties.
- "... dismiss menu on release.(in 1/100ths of sec)": replace period
with space.
- "resolution": field names should be capitalized.
Pull Request: https://projects.blender.org/blender/blender/pulls/108227
Combine the newer less efficient C++ implementations and the older
less convenient C functions. The maps now contain one large array of
indices, split into groups by a separate array of offset indices.
Though performance of creating the maps is relatively unchanged, the
new implementation uses 4 bytes less per source element than the C
maps, and 20 bytes less than the newer C++ functions (which also
had more overhead with larger N-gons). The usage syntax is simpler
than the C functions as well.
The reduced memory usage is helpful for when these maps are cached
in the near future. It will also allow sharing the offsets between
maps for different domains like vertex to corner and vertex to face.
A simple `GroupedSpan` class is introduced to make accessing the
topology maps much simpler. It combines offset indices and a separate
span, splitting it into chunks in an efficient way.
Pull Request: https://projects.blender.org/blender/blender/pulls/107861
When the operator was executed directly (instead of being invoked as
from the UI), `stop`, `do_update` & `progress` were passed to the job
uninitialized, but `pack_islands_startjob` assigns to them (leading to
crash).
Now write protect in `pack_islands_startjob`.
Also fix memleak (missing call to `pack_islands_freejob`).
Pull Request: https://projects.blender.org/blender/blender/pulls/108185
The file is specific for the builds created by the Blender Foundation
and strictly speaking should only be used by builds created on our
release environment.
This change introduces a CMake option which is disabled by default and
which will be enabled on our buildbot.
Ref #107295
Pull Request: https://projects.blender.org/blender/blender/pulls/108191
