This patch changes the priority for choosing the active output to
prioritize viewer nodes as opposed to composite nodes. This is done to
better work with the workflow of using the Connect To Viewer operator
and better match the expected behavior from users.
Tapping the OS key to switch windows could cause the OS key to stick.
On window deactivation the OS key was considered held, activating the
window later read the XKB modifier state before the keyboard_enter &
keyboard_modifier callbacks had run.
When they ran later, the mis-match between XKB and GHOST was not taken
into account, causing the OS key to stick.
The grain size depends on the algorithm, it doesn't make sense to use
the same value for multiple areas just because they relate to `Mesh`.
The comment mentions OpenMP which isn't used anymore.
Also remove an unused forward declaration.
- Avoid a separate memmove call for each `..`.
- Avoid ambiguous path stepping, where separator literals
needed to be checked to avoid fence post errors.
- Correct & update the doc-string.
The CPU compositor sanitizes the colors after HSV/HSL conversion by
clamping negative values to zero. The realtime compositor did no such
sanitization. This patch fixes that by introducing similar sanitization.
This is implemented by removing the attribute and adding it again with
a different name. In the expected case though, implicit sharing is used
to avoid copying the array.
For now this doesn't rename UV sublayers or replace active/default color
attribute names. It's not clear where that should happen, but for now
things are clearer if those stay at a higher level.
Avoid many small allocations and just allocate all the structs in one
array, which is 4 times faster. In a test with an armature modifier and
custom normals, corner normal calculation went from 2.7 to 2.3 ms.
The various stacks are just filled and then emptied. We also expect
them to be fairly small. A vector can handle these cases fairly well.
Also store indices rather than pointers. I didn't notice any performance
changes from these changes.
Instead of storing a 24 byte struct for every face corner we must do
calculations for, just gather the face corner index in the first single
threaded loop. And don't fill them in chunks and use the task pool API.
Instead just fill vectors and use standard "parallel_for" threading.
The check that avoided threading for tiny meshes becomes redundant this
way too, which simplifies the code more. Overall this removes over
100 lines of code.
On a Ryzen 7950x, face corner ("split"/"loop") normal calculation in a
small armature modifier setup with custom normals went from 4.1 ms to
2.8 ms. Calculation for a 12 million face mesh generated with curve to
mesh with end caps went from 776 ms to 568 ms.
Similar commits:
- 9e9ebcdd72
- 9338ab1d62
interior cuts"
This reverts commit 129f79debe.
That commit changed the behavior of how booleans handled vertex weights
as well and made the CubeMaskFirst test modifier test fail.
Not entirely clear to me what the desired behavior would be (current
situation is "wrong" in certain situations as well I think), but until
this is further discussed with the #modeling-module , I think reverting
is the better choice.
In most of the operators the code that loops through the FCurve segments and draws the status header were pretty much identical.
To combat that, create abstract helper functions that can be used.
They are not useful in all cases, e.g. the blend to default operator needs a bit of special code.
Pull Request: https://projects.blender.org/blender/blender/pulls/107170
Using the Knife tool, making cuts that split an edge exactly interpolate
fine for vertex customdata (weights or attributes on the vertex domain)
due to `BM_edge_split` taking care of data layers from the edge and
vertex domain (also mdisps -- which unfortunately dont seem to work
well, but that is for another patch...).
However, making cuts _inside_ a face though dont interpolate at all
(giving default values on new vertices).
With this patch, also interpolate vertex customdata in
`BM_face_split_edgenet`.
Pull Request: https://projects.blender.org/blender/blender/pulls/107367
This patch implements the Corner Pin node for the realtime compositor.
This is different from the existing compositor in that single value
inputs produce single value outputs, instead of assuming the size of the
render.
Pull Request: https://projects.blender.org/blender/blender/pulls/107363
Use a grain size for the final tree creation/balancing/lookup that
depends on the average size of each tree. When the trees are larger,
fewer trees are processed on each thread and vice versa. I didn't notice
a difference when there are hundreds of thousands of groups, but
when there are few (i.e. around the number of cores), I noticed a 6x
performance improvement, from over 1 second to around 0.2 s.
Note that generally the performance is better with many small groups,
because the creation and balancing of trees is single threaded.
If the Group ID input isn't a single value, it's likely to be a span,
so making sure that's true should generally be free, at least in
most cases. This brought a test with 1 million points from 37
to 34 ms, roughtly an 8% improvement.
Needed for the simulation zone addition to the add menu search.
Link-drag search isn't supported yet, but a similar change should be
possible there.
Now the search item exposed through the public nodes namespace returns
several items directly, and the "after add function" is just handled as
a sub-case of that for convenience.
Check if the man-page is missing or older than files that generate it
before re-running the generator.
Previously the install target would re-run the man-page generator
every time, even when no other changes to the build were detected.
Use consistent variable names: for example "vert" instead of "mv" and
"edge" instead of "me", etc. Also use helper functions like "edge other
vert" to make the code easier to read.
Some fields reference attributes directly. When the referenced attribute
has the requested type and domain, the captured/stored attribute can
share its array, avoiding the cost of duplication and reducing memory
usage, at least temporarily until either attribute is modified.
This only works when the attribute doesn't need validation and when
the selection input isn't used, since those potentially need to change
values in the arrays.
I saw this save 200MB and 11 ms of copying for a simple grid with
16 million points (creating the grid takes about 60ms).
Pull Request: https://projects.blender.org/blender/blender/pulls/107357
The intersection distance offset in Cycles could have returned
a denormal floating point value for the input values of 0 (and
for the denormal input value).
This could lead to a situation when ray is unable to be advanced
when it hits an edge between two triangles: the intersection will
keep bouncing between two adjacent triangles. This is because the
ray->tmin is compared inclusively, and 0 >= <denormal zero>.
The solution is to return the smallest possible normalized floating
point value from the intersection_t_offset if the input is zero
or a denormal value (which is covered by the same t == 0 check).
This fix is hard to measure on the user level. The old code did
not cause any infinite traversal loop because of the way how the
integration is organized (some kernels offset ray.P, others check
for the number of bounces). It is possible that this fixes some
corner cases of noise: i.e. if some shadow rays falsefully were
considered occluded due to reached maximum number of bounces.
The actual problematic case was discovered during working on a
prototype which had an in-lined intersection loop with the ray
tmin offset.
Pull Request: https://projects.blender.org/blender/blender/pulls/107364
This patch adds address sanitizer support to memory pools.
when ASAN is enabled the following happens:
* 32 byte red zones are inserted between pool elements.
* The BLI_mempool struct itself is marked as a red zone.
* Access to the pool goes through a thread mutex (except when compiling makesdna).
This is very useful for finding bugs in code that uses BMesh.
Pull Request: #104668
This triggered an assert during evaluation, because the group inputs
were first requested and later the set unused, which is not allowed.
The issue was likely introduced in 258678916f.
