Closed zeux closed 1 month ago
Verified scaling of compute and memory; the results below are on a 1M triangle mesh being simplified down to 200K, with anywhere between 0 and 32 attributes inclusive. The jump from 0 to 1 is expected - when any attributes are present, we need to store and evaluate 2x quadrics currently due to unsynchronized metrics, which might improve in the future, but from there on the memory and extra time is basically constant per attribute.
With 16 attributes you need ~3x memory and ~2.3x time to simplify compared to having no attributes, and with all 32 used it's 4.9x memory and 3.3x time, so it's generally recommended to not specify every single attribute the mesh has; with this change, skipping attributes is a little easier as the internal cost of extra attributes with weight=0 is minimal. (in other words, the graph above is graphing cost/memory as a function of used attributes)
@zeux Also a welcome change 👏 And though the bump to the max attribute count is effectively mentioned only as an implementation detail, this also is a useful quality of life improvement 👍
If some input attributes have weight=0, we allocate and compute quadrics for those regardless of the fact that we do not need this attribute. This makes simplification more expensive when used with many attributes some of which are disabled via weight=0, requiring the caller to restructure the input data for optimal processing.
With this change, we remap attributes during rescaling and recompute attribute_count to make this easier. In the future we could also detect attributes that are constant across the entire mesh, as these also should not be necessary to take into account.
In addition to this, the maximum scalar attribute count during simplification is increased to 32 to allow for easier experimenting with many different attributes.
Contributes to #158.