Currently, atomic additions in vertex normal calculation introduce
non-determinism that can influence the result of other operations,
sometimes causing non-reproduceable renders (in cases like #100250
and #101726). This is because the order used during threading when
accumulating face normals changes.
This commit fixes that non-determinism, using a vertex to face topology
map to calculate vertex normals without atomics. When the map is already
available, this can be faster too.
In the longer term future, this method of vertex normal calculation
means it will be easier to do partial recalculations when only part
of a mesh changes. That might be essential for cases like transforming
small selections in a non-BMesh edit mode.
As an experiment I tried a "fast" code path that avoids weighting face
normals by the corresponding corner angle when averaging them to
create vertex normals. This significantly reduces the necessary
computation and memory bandwidth for vertex normal calculation.
The results are shown below too, but it's not part of this PR.
I measured the FPS with two smooth shaded 16 million face grids:
| | Before | After | After (fast) |
| -------------------------------- | ------ | ----- | ------------ |
| Created from scratch every frame | 0.96 | 0.91 | 0.92 |
| Deformed by geometry nodes | 0.99 | 1.32 | 1.40 |
Though many other things besides normals are being tested here,
it's clear that the performance difference isn't that large either way,
though there is an observable regression with meshes created from
scratch, and there is a noticeable improvement when the topology
stays the same and is persistent.
Pull Request: https://projects.blender.org/blender/blender/pulls/111718
Discussed in #114646.
This commit transforms the "alt_navigation" option of the transform
operators into a new modal key item. "PASSTHROUGH_NAVIGATE"
In addition to cleaning up a lot of the code, it allows you to
customize the key chosen to navigate while transforming.
Only converted value types in the structures.
The pointer values are left unchanged as it requires more careful look
to avoid possible alignment mismatch.
Function arguments are left unchanged as well.
Only float[3] is converted as the float[4] will likely need to be
converted to some C++ rotation class. And float[4][4] often did not
compile when change is only done in the header.
Pull Request: https://projects.blender.org/blender/blender/pulls/114636
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
Extract:
- "Attribute", when creating a new attribute with
`GEOMETRY_OT_attribute_add()`: make the default name in the operator
a null string, and set it to "Attribute" translated inside an invoke
method instead.
- Also for new attributes, from `BKE_id_attribute_calc_unique_name()`,
for instance to create a default vertex color layer when going into
Vertex Paint mode: use `DATA_()` instead of `IFACE_()`, since it
represents user data.
Disambiguate:
- "Weight" can be the thickness of font glyphs.
- "Mark as Asset" and "Clear Asset" are operator names already
extracted using the Operator context. They were recently added to a
manual translation in the UI, but the existing one can be reused.
- "Second" as a time unit in the context of frame snapping.
Some messages reported by Satoshi Yamasaki in #43295.
Pull Request: https://projects.blender.org/blender/blender/pulls/114159
Remove `Material > Shadow Mode` and use `Object > Shadow Ray Visibility`
and `Material > Transparent Shadows` instead.
The versioning system auto-updates objects/materials in EEVEE
scenes so their behavior is as close as possible to the previous one.
Update Cycles to use the native `use_transparent_shadow` property.
Note:
Material changes don't set any `recalc` flag on the objects that use
them, so the EEVEE Next shadow maps don't update when changing
settings/nodes.
Fixing this issue is required for 4.1, but it's out of the scope of this PR.
Pull Request: https://projects.blender.org/blender/blender/pulls/113980
Root of the issue was that a1d7ec7139 (from !110109, new comptibility
handling) missed to update code of `handle_subversion_warning`, file
version numbers should be checked here now, not the minversion ones.
On top of that, this report has been changed to a `RPT_WARNING` instead
of a `RPT_ERROR`, and reports 'print level' for file reading was set to
`WARNING` level way too late to have any effect in existing code...
This commit removes knowledge about face sets from the PBVH,
and changes iteration over faces to not depend on the PBVH face
iterator abstraction. Though this adds slightly more boilerplate to
iteration over faces, it makes the whole process more data oriented
and allows use of index-based utilities like `gather` and `scatter`
in the mesh case, and simpler iteration over BMesh faces for
dynamic topology.
Setting face sets is now specialized per PBVH type in a few places
in a similar way. The general goal is to reduce branching and function
calls at the lowest level of hot loops, and to make code more aware
of the data structures it uses, both for performance and clarity.
Since the remaining uses of the face iterator are removed,
the iterator itself is removed too.
Related commits:
- 97f2b01ea9
- 756dea7ca1
- a6a2af5fdd
Pull Request: https://projects.blender.org/blender/blender/pulls/114417
The issue crash was caused by non-safe cast from a bare C array
float[4][4] to float4x4*. Such cast is not safe because it might
break alignment.
Modified the code so that the transform matrices are passed by
value.
Technically it could mean higher memory usage, but odds that the
actual geometry which is a part of boolean operation consumes much
more memory. Additionally, avoiding indirection could potentially
lead to better performance.
Pull Request: https://projects.blender.org/blender/blender/pulls/114421
Adds a new scene tool setting `use_grease_pencil_multi_frame_editing`.
The `foreach_*_drawing` functions are moved to the `ed::greasepencil` namespace in the editor, since they are now context sensitive and depend on the toolsetting. They are now named `retrieve_editable_drawings` and `retrieve_visible_drawings` and return
an array of drawings instead of calling a callback function.
Pull Request: https://projects.blender.org/blender/blender/pulls/114283
Issue was reported with a 3.6 file crashing 3.3LTS, but the underlying
problem still exists in current codebase, and could also potentially be
caused by other edge-cases.
Pull Request: https://projects.blender.org/blender/blender/pulls/114397
Blender 4.0 added new socket types that get written into legacy node
group interfaces by forward compatibility code. Such unsupported socket
types have to be handled by the socket declaration system and ignored
during execution.
Ported blender-v3.6-release fix#114056
Pull Request: https://projects.blender.org/blender/blender/pulls/114401
Changes to edit mode mesh overlays, use hue shift instead of color
fading/darkening for selection mode visual differentiation, and some
theme changes to improve the display of mesh edges and faces with good
selection visibility.
- Removed "edge" toggle from edit mode overlays panel.
- No longer halves the edge and face alpha depending on selection mode.
Half the face alpha in wire-frame mode. For better visibility on most
themes.
Ref !111431
Create the face set layer in the BMesh when the face set brush is first
used. This requires iterating through all faces to set the default value
of 1 because the default of 0 (SCULPT_FACE_SET_NONE) has different
behavior defined elsewhere.
Pair-reviewed in person with Sergey
These two values are already stored in the mesh, and they have no
relation to the PBVH's goal as an acceleration structure. Similar to
a6a2af5fdd, remove the values from the PBVH and
just access them from the mesh as necessary.
Pair-reviewed in person with Sergey
The user-level goal is to make it so boundaries are preserved in a
much better manner.
At this point of the project boundaries are considered edges which
are marked as seam or sharp. It is possible to expand this logic to
more cases like boundary between face sets. For now the main focus
in the algorithm itself.
The rough idea is the following:
- Splitting an edge is "lossless" for boundary, so there is no need in
any special handling of edges there.
- When collapsing an edge prefer to collapse edges which are not
boundary but adjacent to it. The vertex which is adjacent to boundary
does is preserved and is not moved during the edge collapse algorithm.
- Then collapse boundary edges.
There are a bit of tricky parts, especially with the flaps. They are
explained in the code and ASCII diagrams are provided for better clarity.
Co-authored-by: Hans Goudey <hans@blender.org>
Pull Request: https://projects.blender.org/blender/blender/pulls/113836
The issue was that the undo system detected that node trees have been changed
even though they have not. This is because the memory dump of the node tree
changed after unrelated changes. The root issue was that
`bNodeTreeInterface::write` also wrote the struct, and the pointer of the
`bNodeTreeInterface` itself. While this pointer is generally stable, it is not
during file-write, because when IDs are written, a shallow copy is created
first (see `BLO_write_init_id_buffer_from_id`). The temporary buffer for this
shallow copy is allocated on the heap, so its pointer may change over time.
The fix is to simply not write the `bNodeTreeInterface` separately, since it's
already embedded in `bNodeTree`.
Pull Request: https://projects.blender.org/blender/blender/pulls/114322
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.
Creating a new window then a new scene would crash on undo
because the undo step loaded would not contain the new windows scene.
Regression introduced since 3.6.
This issue happend when a geometry nodes modifier wouldn't output grease
pencil geometry. In this case, we write an emtpy grease pencil
data-block to the evaluated `geometry_set`. But we don't update the
`eval_frame` that indicates on what frame the grease pencil data-block
was evaluated on.
The fix makes sure we update the `eval_frame` even if the output is
empty.
Additionally, there was a missing return in the
`get_evaluated_grease_pencil_drawing_deformation` function that lead
to an empty `deformation.positions` span.
The fix makes sure we return the correct deformation with the correct
positions.
