Mesh: Make vertex normal calculation deterministic #111718

Hans Goudey · 2023-08-31T00:55:23+02:00

Hans Goudey commented

2023-08-31 00:55:23 +02:00

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.

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.

Hans Goudey added 1 commit 2023-08-31 00:55:30 +02:00

05fedab237 Mesh: Refactor vertex normals for determinism

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).
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 normals without atomics. When the map is
already available, this can be faster too.

Internally, a new "fast" code path is available too. This avoids
weighting face normals by the corresponding corner angle when averaging
them to create face normals. This significantly reduces the necessary
computation and memory bandwidth for vertex normal calculation.

The "fast" option is included in this PR as a way to potentially reduce
the peformance impact of requiring the topology map.

TODO:
- [ ] Run performance tests in differenct smooth shading use cases
  - [ ] Large mesh build from scratch every frame
  - [ ] Armature deformation of large mesh without subdivision
- [ ] Test "fast" option and expose toggle in UI if it's worth it

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.

Hans Goudey referenced this pull request

2023-08-31 00:55:55 +02:00

WIP: Mesh: Refactor vertex normals for determinism #105920

Hans Goudey changed title from ~~Mesh: Refactor vertex normals for determinism~~ to Mesh: Make vertex normal calculation deterministic

2023-08-31 00:56:30 +02:00

Hans Goudey requested review from Brecht Van Lommel 2023-08-31 04:12:15 +02:00

Hans Goudey requested review from Campbell Barton 2023-08-31 04:12:15 +02:00

Hans Goudey requested review from Jacques Lucke 2023-08-31 04:12:16 +02:00

Hans Goudey commented

2023-08-31 04:17:21 +02:00

To reviewers, I'm very curious about your opinions here! It is it worth a slight performance regression for non-persistent mesh topology to have deterministic normals? Or should we focus more on the deformation use case where this is actually an improvement? Is it worth keeping the old atomic code around if we go with this? Is "requiring" the memory for the vertex to face topology map okay? How can we factor in code simplicity and consistency between CPU and GPU implementations or other longer term benefits? This PR is helpful to those long term goals IMO.

Also, I'd like to keep in mind that we shouldn't need to calculate vertex normals at all when the mesh is shaded flat. I'll be able to address that after #108014 lands.

To reviewers, I'm very curious about your opinions here! It is it worth a slight performance regression for non-persistent mesh topology to have deterministic normals? Or should we focus more on the deformation use case where this is actually an improvement? Is it worth keeping the old atomic code around if we go with this? Is "requiring" the memory for the vertex to face topology map okay? How can we factor in code simplicity and consistency between CPU and GPU implementations or other longer term benefits? This PR is helpful to those long term goals IMO. Also, I'd like to keep in mind that we shouldn't need to calculate vertex normals at all when the mesh is shaded flat. I'll be able to address that after #108014 lands.

Hans Goudey added the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Mesh: Make vertex normal calculation deterministic #111718