Thank you for the bug report! I'm currently on vacation but I'll take a look when I get a chance.

I did a little investigation. It seems that there is an if statement that has some odd behavior.

(
    (mesh_.face_count() <= target_faces) && (heap_.top().value_ >= min_error)
) ||
    (heap_.top().value_ > max_error)

If the heap value is 0, it will be below min_error and so the face target condition will be inoperative. I am trying to figure out why it was written this way.

@zlateski would you have any insight into this? Sorry to bother you!

@william-silversmith

The errors are always increasing, so this condition is something like

1. stop when you hit certain number of faces or reach certain error (whatever comes second) -> min_error can be set to 0 to always hit certain number of faces, or
2. Just stop when you hit certain error (max_error), regardless of the number of faces

Naming might be unfortunate, but it was consistent with other naming we had at the time with the watershed etc... (as far as I remember)

@william-silversmith

The rationale for adding min_error to the first condition was something like: We know the meshes will look good up to some error, so we can reduce even more than the target number of faces. Setting error to something close to 0 (or 0) and simplifying a cube with a lot of triangles should result in only 12 triangles and look more or less the same.

This is not a bug, it's a feature. Make sure you pass min_error from pyton to C++. The floating point computation error will always be there - but will be proportional to the absolute size of the object passed to the simplifier (e.g. difference between max and min values along an axis).

The c++ code has some factor of 25*std::numeric_limits::epsilon() used as a default, which was probably appropriate for some meshes at some point in time - and is definitely not to be always used.

This is really helpful info @zlateski! Really appreciate you taking the time. I'll expose min_error to the Python code.