Is uneven decimation normal on some models ?

[v3n0m42]

Hi, I integrated your optimizer for generating collision meshes by using meshopt_simplify followed by meshopt_optimizeVertexFetch. Unfortunately, on some meshes, the decimated result has some parts aggressively simplified, and some other parts have redundants triangles conserved; vertices have no attributes other than their position.
Does it come from the topology of the mesh ? My settings ?
The most noticeable come from an airport terminal, as you can see here; some parts are really reduced while others seem to be ignored.
The target error were 0.001, then 0.1 and the vertices conserved were respectively 64.5% and 63%.

Models as used (only positions for vertex attribute), exported as .OBJ:
Original Decimated

[zeux]

For generating collision meshes probably meshopt_simplifySloppy is a better fit - it will not stop due to topological constraints (it also doesn't preserve attribute seams, but it sounds like you only need position data anyhow). I'll take a look at the meshes, in general I'd expect the simplifier to be stuck so early only if the meshes use flat normals and normals are included into the input data.

[zeux]

I believe this is similar to #112 and simplifySloppy should indeed be used as a replacement. It doesn't have a way to control the error right now which is something that can be added, but otherwise it's a better fit; it's expected that the non-sloppy simplifier will get stuck as it won't be able to collapse around certain topology.