Add a function that copies selected values to groups of values in the
result array. Add a runtime-typed version and a version for affecting
all attributes. Also make the "gather_group_to_group" follow the
same pattern.
Currently we have options to transfer the paint mask, face sets, and
color attributes to the new mesh created by voxel remesh. This doesn't
make use of the generic attribute design, where it would be clearer to
transfer all attributes with the same methods. That's reflected in the
code as well-- we do duplicate work for the mask and vertex colors, for
example.
This commit replaces the transfer options with a single checkbox for
all attributes. All attribute types on all domains are transferred with
basically the same method as the "Sample Nearest" node from geometry
nodes-- they take the value from the nearest source element of the same
domain. Face corners are handled differently than before. Instead of
retrieving the mixed value of all the corners from the nearest source
vertex, the value from the nearest corner of the nearest face.
---
Some timing information, showing that when interpolating the same
data, the attribute propagation is significantly faster than before.
Edge and corner attributes would add some cost (edges more than
corners), but might not always be present.
Before
```
voxel_remesh_exec: 3834.63 ms
BKE_shrinkwrap_remesh_target_project: 1141.17 ms
BKE_mesh_remesh_reproject_paint_mask: 689.35 ms
BKE_remesh_reproject_sculpt_face_sets: 257.14 ms
BKE_remesh_reproject_vertex_paint: 54.64 ms
BKE_mesh_smooth_flag_set: 0.15 ms
```
After
```
voxel_remesh_exec: 3339.32 ms
BKE_shrinkwrap_remesh_target_project: 1158.76 ms
mesh_remesh_reproject_attributes: 517.52 ms
```
Pull Request: https://projects.blender.org/blender/blender/pulls/115116
Especially on windows, direct output to `cout` via `<<` is very expensive.
Instead, use fmtlib to do all formatting into a no-alloc `fmt::memory_buffer`,
and output that with one call to `cout`.
timeit utilities are not used much by default, but during development or
profiling one often uncomments macros like `DEBUG_TIME` that then enable
`SCOPED_TIMER` or `SCOPED_TIMER_AVERAGED`.
Having one `SCOPED_TIMER_AVERAGED` inside sequencer `draw_channels`, with
empty timeline and all default channels; the overhead in % of `draw_channels`
duration of said scoped timer before and after this change:
- Windows: 29% -> 5%
- Mac: 5.0% -> 4.4%
Pull Request: https://projects.blender.org/blender/blender/pulls/115233
This path merges the Musgrave and Noise Texture nodes into a single
combined Noise Texture node. The reasoning is that both nodes
intrinsically do the same thing, which is the layering of Perlin noise
derivatives to produce fractal noise. So the patch de-duplicates code
and unifies the use of fractal noise for the end use.
Since the Noise node had a Distortion input and a Color output, while
the Musgrave node did not, those are now available to the Musgrave types
as new functionalities.
The Dimension input of the Musgrave node is analogous to the Roughness
input of the Noise node, so both inputs were unified to follow the same
behavior of the Roughness input, which is arguable more intuitive to
control. Similarly, the Detail input was slightly different across both
nodes, since the Noise node evaluated one extra layer of noise. This was
also unified to follow the behavior of the Noise node.
The patch, coincidentally fixes an unreported bug causing repeated
output for certain noise types and another floating precision bug
#112180.
The versioning code implemented with this patch ensures backward
compatibility for both the Musgrave and Noise Texture nodes. When
opening older Blender files in Blender 4.1 the output of both nodes are
guaranteed to always be exactly identical to that of Blender files
created before the nodes were merged in all cases.
Forward compatibility with Blender 4.0 is implemented by #114236.
Forward compatibility with Blender 3.6 LTS is implemented by #115015.
Pull Request: #111187
When using `SCOPED_TIMER` or `SCOPED_TIMER_AVERAGED`
the display would switch from ns to ms
once the value is over 0.1 ms with a precision of 1.
So when the timer value is hovering in the range of 0.1 - 0.2 ms it is
not giving any useful information.
Fix this by adding another digit to the precision of ms.
Pull Request: https://projects.blender.org/blender/blender/pulls/114724
The problem is in the way of identifying "fast" intersections through bounds.
In the existing code, before testing the intersections (to identify
holes) the polys are sorted according to the bounds
(in the order x1 < x2 || y1 < y2).
Then a for loop is used on the order returned by sort.
Each time the bound of a polygon intersects with another, it is joined
and the bound is added.
The problem with this solution is that some bounds may not intersect
with the first, but could intersect one that is joined to the first,
which, as it is cleared, makes the intersection undetected.
The solution is to remove this code with `qsort` and create a
"target_map" that identifies a source polygon and a dest polygon.
Pull Request: https://projects.blender.org/blender/blender/pulls/114600
Cleanup talked about in the previous semi-related PR, #114501
- saacos, saasin, sasqrt have been 100% identical to saacosf,
saasinf, sasqrtf since 2012.
- For all the above, there exist more intuitively named safe_acosf,
safe_asinf, safe_sqrtf that do the same thing, so switch all code to those.
Pull Request: https://projects.blender.org/blender/blender/pulls/114593
Function Module Inclusive Time Exclusive Time
--------------------------------------------------------------------------
mesh_render_data_update_normals blender 297.51 0.00
315 -> 297
acos() usage in all places related to normal calculations shows up in the
profiler. Given that "angle between faces" is only additional heuristic
weight in there (the effect of it at all is very subtle), approximate but
faster version of acos() might be just fine. Especially since some other
parts of Blender (e.g. mikktspace) use approximate acos in a conceptually
the same part.
- Adds safe_acos_approx() to BLI_math_base.hh. Implementation the same
as already exists in Cycles; max error 0.00258 degrees. Between 2x and 4x
faster in my tests.
- Changes all normals related calculations to use the function above instead
of saacos.
Computing normals on a Stanford Lucy (14m verts) mesh:
- Mac (arm64, M1 Max): 247ms -> 229ms
- Win (x64, Ryzen 5950X): 276ms -> 250ms
All places that are about "normal calculation" were changed, including e.g.
Corrective Smooth modifier. Applying that one to the same 14m vertices mesh,
Mac M1 Max: 9.96s -> 9.76s
Tiny changes in several test output expectations w.r.t. normals are
observed, these were reviewed and updated expectations checked in svn.
Pull Request: https://projects.blender.org/blender/blender/pulls/114501
Windows allows people to pin an application to their taskbar, when a
user pins blender, the data we set in
`GHOST_WindowWin32::registerWindowAppUserModelProperties` is used
which includes the path to the `blender-launcher.exe`. Now once that
shortcut is created on the taskbar, this will never be updated, if
people remove blender and install it again to a different path
(happens often when using nightly builds) this leads to the
situation where the shortcut on the taskbar points to a no longer
existing blender installation. Now you may think, just un-pin and
re-pin that should clear that right up! It doesn't, it'll keep using
the outdated path till the end of time and there's no window API call
we can do to update this information. However this shortcut is stored
in the user profile in a sub-foder we can easily query, from there, we
can iterate over all files, look for the one that has our appid in it, and
when we find it, update the path to the blender launcher to the
current installation, bit of a hack, but Microsoft seemingly offers no
other way to deal with this problem.
Pull Request: https://projects.blender.org/blender/blender/pulls/113859
The last good commit was 8474716abb.
After this commits from main were pushed to blender-v4.0-release. These are
being reverted.
Commits a4880576dc from to b26f176d1a that happend afterwards were meant for
4.0, and their contents is preserved.
The issue was that a node was supposed to propagate an anonymous
attribute that is only created further to the right in the tree. This does not
during inferencing, where uses of fields can only come to the right of its
creation. Note, all fields coming out of the repeat input/output node are
new field sources during inferencing.
Now, only field sources that are passed from the outside into the repeat zone
can be propagated from the repeat output to the repeat input node.
Solving this also showed another issue where anonymous attributes are
not properly propagated through a repeat zone where there is no link between
the repeat input and output node. In such cases, data is still propagated between
those two nodes when the number of iterations is zero.
