Page MenuHome
Create Task
Maniphest T90662

Applying single decimate modifier re-calculated when applying?
Closed, ArchivedPublic
Actions

Description

System Information
Operating system: Windows 10
Graphics card: Geforce GTX 1070

Blender Version
Broken: 2.92.0, 2.93.0, 2.93.3 Release Candidate
Worked: ---

Short description of error
If you apply a decimate modifier to a model with 10mil triangles it takes quite a while to calculate the decimated model.
Then, upon application of the modifier it calculates yet again for a similar amount of time
However exporting to another file format with "apply modifiers" turned on is pretty fast compared.

I could see this difference due to an update of Blenders internal mesh data structure being more involved than writing triangles out to an STL file.
However it generally It appears strange that applying the decimate modifier even has to calculate much at all since the mesh seems to be calculated already.
Judging by the time it takes it seems like the modifier is calculated again upon application. Convert to Mesh behaves the same.

Exact steps for others to reproduce the error
First: Subdivide the cube10 times (~10milt triangles) and apply that modifier, add a decimate modifier, set to 0.1, wait..., apply modifier, wait again...
Second: Subdivide the cube10 times and apply that modifier, add a decimate modifier, set to 0.1, wait..., export STL, import STL. Should feel significantly faster than above.

Object -> Convert -> Mesh and Object -> Apply -> Visual Geometry to Mesh are also re-calculating the modifier.
Especially the latter seems like it explicitly should not.

Event Timeline

The5 (The5) created this task.Aug 13 2021, 10:40 PM
The5 (The5) renamed this task from Applying Decimate modifyer slower than exporting with "apply modifiers" turned on to Applying Decimate modifyer slower than exporting with "apply modifiers" turned on (modifiers being re-calculated when applying?).Aug 20 2021, 9:21 PM
Philipp Oeser (lichtwerk) closed this task as Archived.Sep 28 2021, 9:58 AM
Philipp Oeser (lichtwerk) added a subscriber: Philipp Oeser (lichtwerk).

Thx for the report!

Think the difference here is that applying a single modifier will indeed recalculate this modifier, whereas exporting with the Apply modifiers option can just write out the evaluated object/mesh.
The evaluated object/mesh is available already and does not have to be recomputed, note it contains the results of all modifiers though, it is like the "end-result".

Dont think there is a bug here, will close (but of course feel free to comment again if issues persist).

The5 (The5) added a comment.EditedSep 28 2021, 10:09 AM

I understand what you mean. Resolving a modifier stack iteratively may cause recalculations.

But the recalculation also occurs when applying it on a stack with only a single modifier, as well as using object -> convert -> mesh and object -> apply -> visual geometry to mesh.
Especially the latter one seems like it should explicitly avoid the recalculation and utilize the evaluated mesh, but it does not.

For testing, apply the subdivide modifier before adding the decimate on top, so you only have one modifier active.

I added this info to the initial bug description.

The5 (The5) updated the task description. (Show Details)Sep 28 2021, 10:11 AM
The5 (The5) renamed this task from Applying Decimate modifyer slower than exporting with "apply modifiers" turned on (modifiers being re-calculated when applying?) to Applying single decimate modifier re-calculated when applying?.Sep 28 2021, 10:16 AM
Philipp Oeser (lichtwerk) reopened this task as Needs Triage.Sep 28 2021, 10:49 AM
Philipp Oeser (lichtwerk) closed this task as Archived.Sep 28 2021, 12:33 PM

But the recalculation also occurs when applying it on a stack with only a single modifier, as well as using object -> convert -> mesh and object -> apply -> visual geometry to mesh.
Especially the latter one seems like it should explicitly avoid the recalculation and utilize the evaluated mesh, but it does not.

I think there could indeed be optimizations in the case of a mesh being converted to a mesh (the apply visual geometry to mesh is the same really, both are using the same "convert" code).
Since the "convert" code does a whole lot of things (it also copies the mesh to a temp mesh), the dependency graph is tagged for an update and thus recalculations take place.
However, this suggestion (as good as it is), is a request for modified/improved behavior and not a bug in current behavior.

Will have to close as this bug tracker is only for bugs and errors.
For user requests and feedback, please use other channels: https://wiki.blender.org/wiki/Communication/Contact#User_Feedback_and_Requests
For more information on why this isn't considered a bug, visit: https://wiki.blender.org/wiki/Reference/Not_a_bug

The5 (The5) added a comment.Sep 28 2021, 12:46 PM

I see what you mean from a developer perspective.
There is nothing inherently wrong with the code since it does what the original author intended it to do.

But looking at it from a high-level user perspective: Applying a single modifier re-calculates it.

I assume you would neither see this as expected, desired behavior when applying a modifier.
Form a user perspective, this is a bug.
We file such quirks in the behavior of our tooling as bugs to the tooling team.

To be fair, to fix this "bug" a new feature possibly has to be implemented (directly apply evaluated geometry / fast-path).
But I would not push this into the realm of feature suggestions just because it requires the implementation of one.

The5 (The5) added a comment.Mar 8 2022, 3:55 PM

For future visitors, I meanwhile made a feature suggestion:

https://blender.community/c/rightclickselect/46lg/