Simplify: Relationship between 'error' and 'ratio'?

Describe the bug Since #655 there’s a “simplify” command, however, it seems to not respect the “ratio” parameter at all (neither with nor without also specifying the error parameter).

To Reproduce Steps to reproduce the behavior:

1. Download https://github.com/KhronosGroup/glTF-Sample-Models/raw/master/2.0/DragonAttenuation/glTF-Binary/DragonAttenuation.glb
2. Run gltf-transform simplify --ratio 0.1 DragonAttenuation.glb DragonAttenuation.simplified.glb
3. Repeat with varying values of --ratio
4. Will always end up at the same file size and vertex count

Expected behavior According to help simplify changing ratio should reduce the vertex count. Changing error does something, but then changing ratio also does nothing.

Versions:

• Version: v2.4.5
• Environment: Node.js CLI

Additional context

Besides the issue at hand, it’s interesting how the dragon’s backdrop is/is not optimized - looks like coplanar vertices don’t get merged at all? (this is with a very high “error” value)

[donmccurdy]

Thanks @hybridherbst and @zeux! Hopefully https://github.com/donmccurdy/glTF-Transform/pull/725 improves the documentation here, comments welcome. 😃

[zeux]

So if I understand that correctly, if my goal is “1000 vertices”, then I must set the allowed error very high so that I actually end up at that vertex count.

Yeah, that’s right, although there’s also cases where topological restrictions prevent the simplification to desired target no matter what the error is. This might be improved in the future, and that’s why in glTF-Transform, welding should be done in concert with simplification.

Conversely, when my goal is “reduce this to some error, I don’t care about vertex count”, then I should set ratio to 0 and just let the error metric be the stop condition.

Yeah, that’s exactly right. Setting target to 0 is a great way to simplify towards the acceptable error.

It seems it’s rarely useful then to “mix” ratio and error in practice – I may neither get the desired error nor the desired vertex count when both are set to meaningful values. I believe it makes sense that way, just needs better documentation.

It can be useful to prevent catastrophic degradation in quality - in a sense, this allows the target to be a “soft” parameter. For example, when generating an LOD chain, you might want each successive LOD level to be 50% of the previous one, but you also might be okay with a smaller reduction if attempting to reduce to 50% would penalize the quality too much.