The method of accumulating values to create a hash for each chunk has
been improved for ~16% better distribution of the resulting hashes.
Improve performance of array de-duplication, see: #105046.
Accumulating hashes with a byte/boolean array didn't include enough
information for a useful hash, creating hashes with many collisions.
This is the root cause of a performance regression since 3.3 where
mesh data (used for storing edit-mesh undo steps) was changed to store
selection in a boolean array, creating a bottleneck de-duplicating
chunks of that array for edit-mesh undo's custom-data de-duplication.
Resolve by increasing hash accumulation for arrays with smaller elements,
so each chunk of memory (a candidate for de-duplication) isn't as likely
to have hash collisions.
`char` (single byte) arrays now accumulate 22 values instead of 7, it's
taking more values into account was necessary as these are effectively
bits in the case of boolean arrays, 2-byte values accumulate 32 bytes,
4-byte elements accumulate 44 bytes, larger structs accumulate
`sizeof(type) * 7` bytes (as before).
Also ensure the accumulation read-ahead never exceeds the chunk size -
technically a fix although this would only happen when passing a small
`chunk_count` to BLI_array_store_create (in the range of 1-16) so this
didn't happen in practice.
Improve performance of array de-duplication, see: #105046.
Use uint32_t since it's sufficient for hashing, using an int64_t was
especially inefficient when allocating an int64_t for every boolean
(when compacting an array of booleans).
Improve performance of array de-duplication, see: #105046.
This is a fix for the previous commit d7c023eb25.
Before, every time the lambda was called, a copy of the BitVector was
made. This was very inefficient.
Now this has been fixed by passing the BitVector by reference (&) in
the lambda function.
In very specific cases, during intersection testing, `intersect` can
add polygons already checked as duplicates in the buffer that
corresponds to the rest of polygons that can form groups of duplicates.
As the buffer cannot have repeated indices, re-adding, even
temporarily, these duplicates can cause a buffer overflow.
While this may have some impact on performance, it's difficult to
predict these cases and thus add a buffer pad.
So the solution is to check if they are already duplicated.
The count wasn't clamped above zero in some newly optimized code.
Instead of adding it there, move the clamping to the field network,
similar to some other nodes. That makes it so the rest of the code
doesn't have to deal with the clamping, and should be faster in the
single-value case.
When subsampling was introduced in VSE it was disabled during
editing. Only when rendering it was enabled. This lead to
cache being different between editing and rendering. Leading
to confusion.
This PR will enabled the subsampling when editing. This way
it is more consistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/105612
Some checks here are really critical and should assert, but that one is
more an indication that something is not going right, though data itself
should still be mostly valid, so better warn the user with a LOG
warning, than be silent in release builds, and crash in debug ones.
Invalid nodes are not added to the lazy-function graph. Therefore, their
outgoing links are also not added, which implies that the targets need
some default value.
The correction bbc6bb3468 was still wrong because there it was
disregarded that `vert_ctx_len` does not necessarily indicate merges in
the same polygon.
Therefore, it is not safe to rely on `vert_ctx_len` to count possible
new polygons.
NOTE: It might be worth preempting part of the
`weld_poly_split_recursive` logic to identify what the new polygons are
in advance. But this can be left for a future refactor.
Node tree updates can crash if the tree contains a node group that points at an "undefined" tree type.
This can happen if the tree is linked from a library and the path is lost,
or if a custom (python) tree is used and the script is not run.
The fix is to check if the node group type is valid ("registered") and return an empty list otherwise.
Pull Request: https://projects.blender.org/blender/blender/pulls/105564
Pick select is only meant to change a single element from a single
data-block. However, the operator worked on each object individually
rather than first finding the closest point, then processing the
selection. Change the operator to find the closest point across all
objects, then deselect if necessary, then select the closest point.
Pull Request: https://projects.blender.org/blender/blender/pulls/105495
After ed870f87b9, panels headers displayed inside panels had their
label duplicated when translations were enabled. This is because a
string comparison was made against the original message, instead of
the translated message.
Pull Request: https://projects.blender.org/blender/blender/pulls/105151
- "Lines" in the sense of number of lines
- "Number" can mean "amount, count" or "index, offset"
- "Second" can be an ordinal number or a unit
- "Root": add the brush curve to the "square root falloff" sense
- "Strip" can be a sequence or a type of hair rendering
- "Constant" in the sense of a value, for the Geometry Nodes add
submenu (#105447).
Additionally, extract:
- "Press a key" from the Keymap preferences.
- "MaskLayer", upon new mask layer creation
Ref #43295, #105447
This was caused by an incorrect assumption in the solver:
It tries to solve both collision and length constraints simultaneously,
using the projected movement of a point as a slide direction along the surface.
This only works if the distance of the previous curve point to the surface
is less than the allowed segment length. Otherwise the segment will
exceed the allowed length even with zero slide and NaN values are computed.
The case of larger surface distance can occur if the previous segment
solve was already stretching the current segment and then the point
moves further away. In this case we can simply clamp the segment length
without violating the contact constraint.
Pull Request #105499
3e5ce23c99 introduced a regression in case the freed Main was part of a
list, and was supposed to be removed from it, since calling
`BLI_remlink` does _not_ clear the `prev`/`next` pointers of the removed
link.
This commit also contains a few more tweaks to recent related b3f42d8e98
commit.
Pull Request #105485
While this behavior can be useful in some cases, it can also create
issues (as in one of own recent commits, 3e5ce23c99), since it
implicetly keeps the removed linknode 'linked' to the listbase.
At least warn about it in the documentation of `BLI_remlink`.
This commit introduces a new Main boolean flag that marks is as invalid.
Higher-level file reading code does checks on this flag to abort reading
process if needed.
This is an implementation of the #105083 design task.
Given the extense of the change, I do not think this should be
considered for 3.5 and previous LTS releases.
When render is triggered from python and the render result is displayed
it isn't being updated as it wasn't tagged as being invalid.
Pull Request #105480
If the texture image path in the MTL is a "quoted" absolute path, the importer will fail to find the
file. It was only attempting to un-quote the path for the relative case. Now we attempt to un-quote
in all cases.
Pull Request #105478
The issue was that when using the `HD_ALIGNED` handle type,
Blender would not automatically move the keyframe handles with the key.
Instead one handle would get stuck in place.
To remedy that manually move the keyframe handles in case the type is `HD_ALIGNED`
This makes it consistent with moving a key with G
Pull Request #105401
Consistently use edge draw flag instead of original index to determine if an
edge should be drawn or not.
In GPU subdivision the edge original index was used for both edge optimal
display and selection mapping to coarse edges, but they are not the same.
Now match the CPU subdivision logic and use a separate edge draw flag VBO.
For cage display, match Blender 3.3 behavior more in showing/hiding of edges
in wireframe mode. That is edges without a mapping to an original edge are
always hidden when there is no distinct cage, and drawn otherwise. This is
not ideal for e.g. the bevel modifier where it will always show some edges on
corners despite all edges being hidden by the user. But we currently have
no good information to decide if these should be hidden or not, so err on
the side of showing too much as it did before.
Fie #103706: bevel modifier edges not drawn correctly
Fix#103700: optimal display can't be turned of with GPU subdivision
Fix wrong edge display with GPU subdivision preceded by other modifiers
Pull Request #105384
Timer management code often loops over the list of timers, calling
independant callbacks that end up freeing other timers in the list. That
would result in potentail access-after-free errors, as reported in #105160.
The typical identified scenario is wmTimer calling wmJob code, which
calls some of the job's callbacks (`update` or `end` e.g.), which call
`WM_report`, which removes and add another timer.
To address this issue on a general level, the deletion of timers is now
deferred, with the public API `WM_event_remove_timer` only marking the
timer for deletion, and the private new function
`wm_window_delete_removed_timers` effectively removing and deleting all
marked timers.
This implements design task #105369.
Pull Request #105380
Window activation events on Windows-10 don't seem to be reliable as it's
possible for Alt-Tab to trigger WM_ACTIVATE on a window when switching
away from it. As detecting the keys which are held relies on a valid
active state - this meant Alt could become stuck when using Alt-Tab
to switch between windows.
Disable reading modifiers on activation for WIN32, activating the window
now clears modifiers on WIN32. This isn't ideal as held modifiers wont
be detected, re-introducing the error reported in #40059.
Previously, UBO bind locations were linearly incremented and
relied on the correct uniform location being queried. This fix
is a future requirement for EEVEE next, however, pulling forward
due to Issue #105280 highlighting a possible flaw with expected
uniform locations.
Authored by Apple: Michael Parkin-White
Ref #96261
Pull Request #105311
Intel GPUs exhibit a number of rendering artifacts.
The most substantial being incorrect resolve of reflections.
Splitting the reflections_resolve shader into two passes,
one for SSR and one for light probes ensures correct rendering
and optimal performance on this GPU.
Also resolves an artifact with ambient occlusion wherein
the pow(a, b) function causes excessive precision loss.
Using an alternative method for power calculation on these
platforms resolves the issues.
Authored by Apple: Michael Parkin-White
Ref T96261
Pull Request #105240
Metal backed requires HOST_READ texture usage flag
for irradiance grid. This was correctly in place for the
basic grid, but not for grid_prev.
Authored by Apple: Michael Parkin-White
Ref #96261
Pull Request #105312
