Decimate modifier gives different result on every evaluation #100250

New Issue

Yegor · 2022-08-06T21:04:07+02:00

Yegor commented

2022-08-06 21:04:07 +02:00

System Information
Operating system: Linux-5.4.0-122-generic-x86_64-with-glibc2.31 64 Bits
Graphics card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.129.06

Blender Version
Broken: version: 3.2.2, branch: master, commit date: 2022-08-02 18:15, hash: bcfdb14560, 3.3 latest
Broken: 3.1.2
Worked: 3.1.0
Worked: 2.93.8

Caused by fb2cb0324a

Short description of error
A mesh with decimate modifier gets topology rebuilt on each frame of Cycles render. Notice that a new cones object on the right is not broken.
There's something wrong with the left object. I checked every property I could think of.
0001-0250.mp4
decimate_bug.blend

Exact steps for others to reproduce the error
Open the file. Render a sequence.

**System Information** Operating system: Linux-5.4.0-122-generic-x86_64-with-glibc2.31 64 Bits Graphics card: NVIDIA GeForce GTX 1080 Ti/PCIe/SSE2 NVIDIA Corporation 4.5.0 NVIDIA 470.129.06 **Blender Version** Broken: version: 3.2.2, branch: master, commit date: 2022-08-02 18:15, hash: `bcfdb14560`, 3.3 latest Broken: 3.1.2 Worked: 3.1.0 Worked: 2.93.8 Caused by fb2cb0324a **Short description of error** A mesh with decimate modifier gets topology rebuilt on each frame of Cycles render. Notice that a new cones object on the right is not broken. There's something wrong with the left object. I checked every property I could think of. [0001-0250.mp4](https://archive.blender.org/developer/F13341291/0001-0250.mp4) [decimate_bug.blend](https://archive.blender.org/developer/F13341295/decimate_bug.blend) **Exact steps for others to reproduce the error** Open the file. Render a sequence.

Yegor commented

2022-08-06 21:04:07 +02:00

Added subscriber: @YegorSmirnov

blender-admin commented

2022-08-06 21:04:07 +02:00

#101108 was marked as duplicate of this issue

Yegor commented

2022-08-06 21:35:22 +02:00

Found a clue. If you change the shadow terminator geometry offset value, the mesh will wiggle in the viewport as well. But setting to 0 doesn't fix the problem on render.

Found a clue. If you change the shadow terminator geometry offset value, the mesh will wiggle in the viewport as well. But setting to 0 doesn't fix the problem on render. ![image.png](https://archive.blender.org/developer/F13341359/image.png)

Philipp Oeser commented

2022-08-08 14:00:30 +02:00

Added subscriber: @lichtwerk

Philipp Oeser commented

2022-08-08 14:00:30 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Philipp Oeser commented

2022-08-08 14:00:30 +02:00

Can confirm, will check

Philipp Oeser changed title from ~~Decimate modifier rebuilds the mesh on each frame~~ to Cycles: Decimate modifier rebuilds the mesh on each frame

2022-08-08 14:01:05 +02:00

Brecht Van Lommel changed title from ~~Cycles: Decimate modifier rebuilds the mesh on each frame~~ to Decimate modifier gives different result on every evaluation

2022-08-08 14:29:25 +02:00

Brecht Van Lommel commented

2022-08-08 14:33:14 +02:00

Added subscribers: @HooglyBoogly, @brecht

Brecht Van Lommel commented

2022-08-08 14:33:14 +02:00

This is not a Cycles or rendering issue, anything to trigger the modifiers to be re-evaluated will change the result, like dragging the Factor slider in the modifier.

fb2cb0324a enabled multi-threaded vertex normal computation, which gives slightly different results each time due to different order or float addition, which gives different results due to limited precision. The decimation algorithm is sensitive to this.

This is not a Cycles or rendering issue, anything to trigger the modifiers to be re-evaluated will change the result, like dragging the Factor slider in the modifier. fb2cb0324a enabled multi-threaded vertex normal computation, which gives slightly different results each time due to different order or float addition, which gives different results due to limited precision. The decimation algorithm is sensitive to this.

Philipp Oeser commented

2022-08-08 18:08:11 +02:00

In #100250#1401522, @brecht wrote:
This is not a Cycles or rendering issue, anything to trigger the modifiers to be re-evaluated will change the result, like dragging the Factor slider in the modifier.

fb2cb0324a enabled multi-threaded vertex normal computation, which gives slightly different results each time due to different order or float addition, which gives different results due to limited precision. The decimation algorithm is sensitive to this.

OK, thx checking, just want to note that eevee does not suffer from this (and scratching my head why that is... that is why i was fooled into thinking this is a cycles issue)

> In #100250#1401522, @brecht wrote: > This is not a Cycles or rendering issue, anything to trigger the modifiers to be re-evaluated will change the result, like dragging the Factor slider in the modifier. > > fb2cb0324a enabled multi-threaded vertex normal computation, which gives slightly different results each time due to different order or float addition, which gives different results due to limited precision. The decimation algorithm is sensitive to this. OK, thx checking, just want to note that eevee does not suffer from this (and scratching my head why that is... that is why i was fooled into thinking this is a cycles issue)

Philipp Oeser commented

2022-08-08 18:11:49 +02:00

So is this something that will have no solution?
CC @HooglyBoogly

So is this something that will have no solution? CC @HooglyBoogly

Brecht Van Lommel commented

2022-08-08 18:47:43 +02:00

Eevee animation render uses "persistent data" automatically, so the mesh is not recreated. So it's not an issue in that case, though if you e.g. distribute that over a render farm it's going to be an issue again.

I think it can be solved. The easy workaround would be to disable multi-threading for computing vertex normals in the decimate modifier.

Ideally vertex normal computation would give consistent results, and perhaps also eliminate the atomic operations. It could store the weighted face normals in an array per-loop, and then threads could sum them per-vertex in some consistent order. This is probably not very efficient though.

Decimation could round away some bits of the vertex normal to remove slight precision differences, though I'm not sure if this will be entirely reliable.

Eevee animation render uses "persistent data" automatically, so the mesh is not recreated. So it's not an issue in that case, though if you e.g. distribute that over a render farm it's going to be an issue again. I think it can be solved. The easy workaround would be to disable multi-threading for computing vertex normals in the decimate modifier. Ideally vertex normal computation would give consistent results, and perhaps also eliminate the atomic operations. It could store the weighted face normals in an array per-loop, and then threads could sum them per-vertex in some consistent order. This is probably not very efficient though. Decimation could round away some bits of the vertex normal to remove slight precision differences, though I'm not sure if this will be entirely reliable.

Hans Goudey commented

2022-08-08 18:59:32 +02:00

Rounding away the lower bits in vertex normals for decimate sounds like a reasonable approach. I guess that would affect wherever normals are accessed in the decimate modifier.

For making computed normals more consistent, another approach would be caching vertex -> face corner and face corner -> face topology maps in the mesh.
That would be useful for lots of other operations too, and the memory requirement would just be like storing a second MLoop array.
Then the normal calculation would be a simple loop over those indices, without any atomics.
I'm not sure if that should be required for calculating normals though, the current method seems like it has a place too.

Rounding away the lower bits in vertex normals for decimate sounds like a reasonable approach. I guess that would affect wherever normals are accessed in the decimate modifier. For making computed normals more consistent, another approach would be caching vertex -> face corner and face corner -> face topology maps in the mesh. That would be useful for lots of other operations too, and the memory requirement would just be like storing a second MLoop array. Then the normal calculation would be a simple loop over those indices, without any atomics. I'm not sure if that should be required for calculating normals though, the current method seems like it has a place too.

Hans Goudey commented

2022-10-21 00:43:17 +02:00

Added subscribers: @Deehn, @JacquesLucke, @iss, @sbchild

lolno commented

2022-11-01 22:33:15 +01:00

Added subscriber: @yebutno

lolno commented

2022-11-01 22:33:15 +01:00

Ill just add that information in the opening post that claims 3.1 works is wrong. All 3.x versions have this bug, it is just that it is less severe in 3.1 and below. It works fine only if you go down to 2.93. I am attaching file with simple rock that is very sensitive to this quite frankly critical and workflow breaking bug. I simply use hotkeys to switch between object mode and sculpt mode and the rocks shape drastically changes. I don't understand how something this glaring goes unnoticed by users for so long.

rocks_test.blend

Ill just add that information in the opening post that claims 3.1 works is wrong. All 3.x versions have this bug, it is just that it is less severe in 3.1 and below. It works fine only if you go down to 2.93. I am attaching file with simple rock that is very sensitive to this quite frankly critical and workflow breaking bug. I simply use hotkeys to switch between object mode and sculpt mode and the rocks shape drastically changes. I don't understand how something this glaring goes unnoticed by users for so long. [rocks_test.blend](https://archive.blender.org/developer/F13835774/rocks_test.blend)

Yegor commented

2022-11-27 20:03:40 +01:00

Not sure if it's the same bug, but decimate modifier recalculates on every frame when you add a cloth modifier (even disabled).
2022-11-27 21-58-29_01.mp4

decimate_cloth_bug.blend

Not sure if it's the same bug, but decimate modifier recalculates on every frame when you add a cloth modifier (even disabled). [2022-11-27 21-58-29_01.mp4](https://archive.blender.org/developer/F13973667/2022-11-27_21-58-29_01.mp4) [decimate_cloth_bug.blend](https://archive.blender.org/developer/F13973674/decimate_cloth_bug.blend)

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Decimate modifier gives different result on every evaluation #100250