Page MenuHome

Decimate Modifier; Bad geometry when following subsurf with planar decimation on a mesh with holes
Closed, ResolvedPublic

Description

System Information
OS - Windows 10 64 bit; CPU - Third-gen i7; GPU - ATI HD 7xxx; RAM - 24 gigs

Blender Version
Broken: Blender hash 211b539
Worked: Unknown

Short description of error
You get bad results when adding a subsurf modifier and following it up with planar decimation on a mesh with holes (faces start overlapping the holes and each other).

Exact steps for others to reproduce the error
Open the .blend file and turn the decimate modifier on and off

.blend

Event Timeline

Adam Friesen (ace_dragon) set Type to Bug.
Adam Friesen (ace_dragon) created this task.
Adam Friesen (ace_dragon) raised the priority of this task from to Needs Triage by Developer.

OS - Windows 7 Pro 64-bit
Display: Nvidia GeForce GTX760

Blender Version
Broken: 29bb10e

A bit of extra information.

I get the same bad results on my system if I use the 'Planar' setting in the decimate modifier.

If I set decimate to either 'Collapse' or 'Un-subdivide' then I get good (expected) results from the modifier.

Campbell Barton (campbellbarton) triaged this task as Confirmed, Medium priority.

You can also avoïd that by using Delimit options of the modifier.
You can create seams like that.

Or you can have a material or UVs that make sense as demarcation.

Looked into this. The cause of the error is edge-chains (edges following a path) are collapsed without checking:

  • If this flips the face direction (trivial check to add).
  • If collapsing the edge causes a face to self intersect (more complicated).

This could be handled by creating a large polygon with holes (ignoring central edge chains), then using the hole connection code (thats used for booleans - BM_face_split_edgenet_connect_islands). While this should work its quite a heavy solution for an operation which in many cases isn't even necessary.

Another solution could be to triangulate the ngon, then use the edges of the tessellated triangles to map a shorter path.

But think it would be simpler to treat this as an ear-clipping problem, where collapsing each vertex on an edge chain checks that the face which occupies triangle if formed, has no vertices inside that triangle.
While the overlap checks add some overhead, this can be optimized as is done with BLI_polyfill2d (using a KD-Tree), 2d projections can be cached too.

There is one gotcha with ear clipping - that is a vertex which prevents clipping, may its self be clipped later on during this process.
Once a vertex is clipped, the faces that used it, and previously weren't able to collapse at least one vertex - will need to re-tested (keeping track of which vertices prevented others from clipping could work too... but probably too much book-keeping to handle such a corner-case).