High poly meshes perform poorly with planer decimate #69860

New Issue

Ahmad Bilal · 2019-09-13T23:42:08+02:00

Ahmad Bilal commented

2019-09-13 23:42:08 +02:00

System Information
Operating system: Windows 10
Graphics card: AMD Asus Vega RX64

Blender Version
Broken: blender-2.81-92736a7b7592-windows64 (plus previous few builds - atleast)
Worked: 2.8

My PC is decent, and I have had no problem decimating millions of vertices (albeit some few seconds of lag) usually. Right now, I'm trying to decimate a simple model with about 45k vertices only. The decimate modifier is working fine on default settings i.e., on 'Collapse' setting .. but as soon as I switch to 'Planer' .. Blender becomes unresponsive for several minutes at least (and also indefinitely in some cases).

I noticed that in my task manager, the Blender is only using 29% of CPU.. and regarding RAM .. on one side it shows 61% usage, while the actual usage is only 289MB in the value column (see screenshot). Could this be a memory related overflow/underflow? This definitely does look like a bug to me.

**System Information** Operating system: Windows 10 Graphics card: AMD Asus Vega RX64 **Blender Version** Broken: blender-2.81-92736a7b7592-windows64 (plus previous few builds - atleast) Worked: 2.8 My PC is decent, and I have had no problem decimating millions of vertices (albeit some few seconds of lag) usually. Right now, I'm trying to decimate a simple model with about 45k vertices only. The decimate modifier is working fine on default settings i.e., on 'Collapse' setting .. but as soon as I switch to 'Planer' .. Blender becomes unresponsive for several minutes at least (and also indefinitely in some cases). I noticed that in my task manager, the Blender is only using 29% of CPU.. and regarding RAM .. on one side it shows 61% usage, while the actual usage is only 289MB in the value column (see screenshot). Could this be a memory related overflow/underflow? This definitely does look like a bug to me. ![bugSep14-1.png](https://archive.blender.org/developer/F7746591/bugSep14-1.png) ![bugSep14-2.png](https://archive.blender.org/developer/F7746590/bugSep14-2.png)

Ahmad Bilal commented

2019-09-13 23:42:08 +02:00

Added subscriber: @SomeAB

Brecht Van Lommel commented

2019-09-18 19:32:37 +02:00

Added subscriber: @brecht

Brecht Van Lommel commented

2019-09-18 19:32:37 +02:00

We require a .blend file to reproduce the issue.

Ahmad Bilal commented

2019-09-22 07:30:15 +02:00

I just noticed the same problem in a more recent version as well while working on my latest project:

Broken: version: 2.81 (sub 11), branch: master, commit date: 2019-09-13 15:37, hash: 92736a7b75

I'm attaching a sample blend file as requested (different file from earlier, same issue) Planar_Bug.blend

It has one object of about 1million faces. Trying to switch to 'Planer' Decimate inside the decimate modifier seems to take forever. After 20-30 minutes, the viewport is still frozen. Average CPU usage around 30% and RAM usage around 1GB.

I just noticed the same problem in a more recent version as well while working on my latest project: Broken: version: 2.81 (sub 11), branch: master, commit date: 2019-09-13 15:37, hash: `92736a7b75` I'm attaching a sample blend file as requested (different file from earlier, same issue) [Planar_Bug.blend](https://archive.blender.org/developer/F7767674/Planar_Bug.blend) It has one object of about 1million faces. Trying to switch to 'Planer' Decimate inside the decimate modifier seems to take forever. After 20-30 minutes, the viewport is still frozen. Average CPU usage around 30% and RAM usage around 1GB.

Ahmad Bilal commented

2019-09-27 15:41:05 +02:00

@brecht Can you reproduce this on your side?

Germano Cavalcante commented

2019-09-30 15:13:35 +02:00

Added subscriber: @mano-wii

Campbell Barton was assigned by Germano Cavalcante

2019-09-30 15:13:35 +02:00

Germano Cavalcante commented

2019-09-30 15:13:35 +02:00

I can confirm the bug, I don't know if it's the result of an endless loop or if the modifier really takes too long to calculate.
To reproduce the problem:

Open file attached in comment;
Add Decimate Modifier;
Select the Planar option.

I can confirm the bug, I don't know if it's the result of an endless loop or if the modifier really takes too long to calculate. To reproduce the problem: - Open file attached in comment; - Add Decimate Modifier; - Select the Planar option.

Ahmad Bilal commented

2019-10-08 00:21:05 +02:00

It might be so, that this bug has been resolved somehow. I recently used the Oct6 build: blender-2.81-54a9649e2636-windows64 .. and there seems to be no significant issue in switching to planar right now. Though it is still the type of decimate which takes the largest time to switch to among the three .. comparitively speaking. I wonder if it is due to its nature, and this is an expected behavior?

Germano Cavalcante commented

2019-10-08 14:17:42 +02:00

It still takes forever on the file you sent.
Lowered priority as it is so specific.

It still takes forever on the file you sent. Lowered priority as it is so specific.

Campbell Barton was unassigned by Dalai Felinto

2019-12-23 13:50:53 +01:00

Dalai Felinto commented

2019-12-23 13:50:53 +01:00

Added subscriber: @ideasman42

Germano Cavalcante commented

2020-01-27 15:13:40 +01:00

This does not appear to be a bug that will be worked on the upcoming 6 months.
And as defined on the tracker-curfew page, issues that won't be worked on for the the upcoming 6 months must be marked as Known Issue and documented.

(I will leave the documentation of this problem for a later stage).

This does not appear to be a bug that will be worked on the upcoming 6 months. And as defined on the [tracker-curfew page](https://code.blender.org/2019/12/tracker-curfew/), issues that won't be worked on for the the upcoming 6 months must be marked as `Known Issue` and documented. (I will leave the documentation of this problem for a later stage).

Campbell Barton changed title from ~~Blender non-responsive on using Planer decimate~~ to High poly meshes perform poorly wit planer decimate

2020-09-04 08:07:07 +02:00

Campbell Barton commented

2020-09-04 08:30:50 +02:00

In general planar decimate isn't at all optimized for high-poly/organic meshes.

Currently planar decimate runs in two passes, first it joins faces, then it simplifies edges.
This means high poly meshes end up with many n-gons with many sides as planar decimate runs.
Each face-merge causes normals to be re-calculated, which will be slow with faces that have many sides.

Some changes could be made to improve performance.

Accumulate normals when merging face pairs instead of re-calculating (weighting by area for example).
Simplify edges after joining face pairs so faces don't end up having so many sides, allowing the decimate operation to speed up as the mesh becomes simpler.

Note that the models in the example are better suited to edge-collapsing decimation. Planar decimate is intended to merge flat surfaces (often exported from CAD applications), even if performance is improved it wont give great results on organic meshes.

In general planar decimate isn't at all optimized for high-poly/organic meshes. - Currently planar decimate runs in two passes, first it joins faces, then it simplifies edges. - This means high poly meshes end up with many n-gons with many sides as planar decimate runs. - Each face-merge causes normals to be re-calculated, which will be slow with faces that have many sides. Some changes could be made to improve performance. - Accumulate normals when merging face pairs instead of re-calculating (weighting by area for example). - Simplify edges after joining face pairs so faces don't end up having so many sides, allowing the decimate operation to speed up as the mesh becomes simpler. Note that the models in the example are better suited to edge-collapsing decimation. Planar decimate is intended to merge flat surfaces (often exported from CAD applications), even if performance is improved it wont give great results on organic meshes.

Campbell Barton changed title from ~~High poly meshes perform poorly wit planer decimate~~ to High poly meshes perform poorly with planer decimate

2020-09-04 09:55:33 +02:00

Jacob Merrill commented

2020-09-30 04:38:52 +02:00

Added subscriber: @JacobMerrill-1

Jacob Merrill commented

2020-09-30 04:38:52 +02:00

for workflow for going from high poly to low poly meshes it's nice to be able to decimate the already baked model and use planar with UV checked - then bake over the normals from the high poly to the low poly.

maybe some other modifier could replace this workflow and do it in 1 shot?

for workflow for going from high poly to low poly meshes it's nice to be able to decimate the already baked model and use planar with UV checked - then bake over the normals from the high poly to the low poly. maybe some other modifier could replace this workflow and do it in 1 shot?

Jacob Merrill commented

2020-09-30 04:40:30 +02:00

using about 16 gigs of ram of my 32 so that is not the bottleneck

I am decimating a model with 8,000,000 triangles right now and It's been about 45 minutes

![image.png](https://archive.blender.org/developer/F8938518/image.png) using about 16 gigs of ram of my 32 so that is not the bottleneck I am decimating a model with 8,000,000 triangles right now and It's been about 45 minutes

Campbell Barton commented

2020-09-30 05:53:51 +02:00

@JacobMerrill-1 is this with planar decimate? (as noted, this doesn't perform well).

Jacob Merrill commented

2020-09-30 18:21:01 +02:00

yeah it took about 8 hours to complete but it did!

also uses quite a bit of cache,

maybe if brute force is required this could be threaded some day?

(if it is threadable that would cut it down to like 2 hours I bet since I have 8 threads?)

or maybe the GPU / compute could be leveraged to do this faster?

I found this -> https://github.com/vilemduha/optiloops/blob/master/init.py
which works very well but is also quite slow but leaves really nice topology

yeah it took about 8 hours to complete but it did! also uses quite a bit of cache, maybe if brute force is required this could be threaded some day? (if it is threadable that would cut it down to like 2 hours I bet since I have 8 threads?) or maybe the GPU / compute could be leveraged to do this faster? I found this -> https://github.com/vilemduha/optiloops/blob/master/__init__.py which works very well but is also quite slow but leaves really nice topology

Nicolas Lelong commented

2021-03-02 15:23:32 +01:00

Added subscriber: @rotoglup

Nicolas Lelong commented

2021-03-02 15:23:32 +01:00

FWIW, I also stumbled upon this limitation : it took 16 minutes to decimate my mesh.

As I loved the result, I clicked "Apply" on the modifier, and it seems that it recomputes the result for the application (another 16 minutes)...

FWIW, I also stumbled upon this limitation : it took 16 minutes to decimate my mesh. As I loved the result, I clicked "Apply" on the modifier, and it seems that it recomputes the result for the application (another 16 minutes)...

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

High poly meshes perform poorly with planer decimate #69860