Is Surface Simplification Using Quadric Error Metrics not actually what it is? about geometry3sharp HOT 7 CLOSED

https://mgarland.org/files/papers/quadric2.pdf

the first paper is rarely the best one. yes, any weighting affects the optimal point.

from geometry3sharp.

I read article you sent.
OK, I found "it is useful to weight quadrics by the area of the contributing triangle". It seems to work, but maybe we need to consider this weights in some other places when reducing? Because now I got different results on one mesh with different scales (when reduce to triangles count).
For example, look at the ear


and it's a bit strange, because areas of triangles should rise proportionally.

The results will be identical if I delete multiplying on "w" in Add method

from geometry3sharp.

because it is based on sequential edge collapses, the final result can be wildly different if even one edge is collapsed in a different order. The code is in floating point, so individual quadrics that evaluate to nearly identical error can easily switch order if you change the vertices even a tiny bit (eg by scaling). This is particularly an issue in planar regions, and also on near-regular meshes where all the initial one-rings are nearly identical.

Also, the OptimalPoint() function has a hardcoded epsilon to avoid singular matrices, in such cases basic midpoint interpolation is used. This actually happens quite often. As you scale down the shape, it will happen more often, and each time it does, it will have a downstream effect on the output mesh.

It's possible that SVD could be used to deal with these singular matrices and make the results more consistent. It is probably infrequent enough that it wouldn't be a huge computational cost.

If you want to minimize floating point effects, you probably should also scale to/from a unit box before running the algorithm. This actually does make a difference, as floats/doubles are 'denser' closer to 0.

from geometry3sharp.

Okay, thanks a lot!
By the way, is there any built-in way to minimize vertex numbers (I mean indices) after mesh reducing for more effective storing in memory?

from geometry3sharp.

the terminology for this in the library is 'compacting'. There are several DMesh3 copy-constructors that take a 'bCompact' flag that will produce a compacted copy. In addition there is DMesh3.CompactInPlace(), this will make the indices dense (ie no gaps) but doesn't free up all the extra memory.

from geometry3sharp.

Is there any source code for C#?

from geometry3sharp.

Leaving a comment so I can find this later.

from geometry3sharp.