The current logic goes as follows:
[1] get each faces 3d area
[2] get each faces uv area
[3] also keep track of the current total area (both 3d and uv)
[4] divide the uv area by the 3d area and store as a ratio
[5] push totals and this ratio to the GPU, and multiply by
(total_uv_area / total_3d_area)
Issue arises when face areas are really large combined with small UV
areas (report has a mesh ~1.5 km), then floating point point imprecission
may lead to ratios of 0.0f (which then messes up the overlay display).
Just flipping the logic to a multiplication in step [4] would solve the
issue for large scale meshes, but could have similar issues for very
small scale meshes.
Using doubles might solve this as well (havent tried this though, unsure
pushing these to the GPU would be an issue).
Using the uv_parametrizer might also solve this (afaict this also uses
doubles internally) but also havent checked this.
So the idea now is as follows:
[1] get each faces 3d area
[2] get each faces uv area
[3] also keep track of the current total area (both 3d and uv)
[4] get a fraction of each faces 3d area in relation the the total 3d
area (making this "independent" of mesh dimensions)
[5] get a fraction of each faces uv area in relation the the total uv
area
[6] divide those two to get the stretch directly on the CPU and only
push this to the GPU
This way we avoid running into floating point precission issues (these
very small values in the former ratios).
Doing it this way will also remove the need to update totals and push
these constants to the GPU in a couple of places (getting rid of quite a
bit of code).