fix: remove flat modifier, while maintaining TreeIndex precision

[Strepto]

Description

This resolves an iOS Metal performance issue introduced by the fix of #2363 . The performance issue is caused by an implementation detail in the WebGL spec which is incompatible with Metal rendering, and WebKit has to emulates this detail by reshuffling vertices. Which is slow.

A real fix for this issue is in the works, with the EXT_PROVOKING_VERTEX extension, currently in a draft stage: https://registry.khronos.org/webgl/extensions/EXT_provoking_vertex/ . The extension is being implemented in WebKit (See WebKit/WebKit#3701 ), but I guess we cannot expect this to be shipped soon.

As the original problem here is that "varyings" in WebGL use an algorithm that averages the three sides of the vertex, and also applies a "Perspective Correction". See "For varyings though WebGL uses this formula" on https://webglfundamentals.org/webgl/lessons/webgl-3d-perspective-correct-texturemapping.html

Example showing the issue. (random example proving the above algorithm seems correct)

float treeIndex = 3205807.0f;
float a = treeIndex;
float b = treeIndex;
var aW = 0.9f;
var bW = 0.9f;
var t = 0.3f;
// Formula from https://webglfundamentals.org/webgl/lessons/webgl-3d-perspective-correct-texturemapping.html 
float dividend =  (1 - t) * a / aW + t * b / bW;
float divisor = (1 - t) / aW + t / bW;
var result = dividend/divisor;

// Result: 3205806.5 (rounded towards nearest even: 3205806)
assert(treeIndex == round(result)) // throw! :(

We get an offset result, but only for some values of W (and t). This varies, causing the "noise" pattern, seen in some screenshots of the "pre-fix" when tree-indices are high.

In this PR i propose a "dirty" fix, separating the TreeIndex into two different numbers in the Vertex Shader, and merging these numbers in the Fragment Shader. This removes the rounding issue given it works as the example above, as the inaccuracy does not occur for values below 2_000_000 in any of my tests.

The current maximum supported treeIndex is 2^24 due to storing it in an RGB255 Color, so we do not yet need to handle higher values than approx 16_800_000, which the proposed code will handle nicely given the formula above.

---

This PR adds another medp float to each fragment, and additional multiplications to add these together. The separation of 100ds and SubHundreds is kinda arbitrary, but medp has rounding issues when we get near 1000, so 99 as max works OK.

I might be overly defensive on rounding.

I have tested this with nodeIds up to 10_500_000, and have not spotted any issues with the approach.

If you have any suggestion on OTHER approaches to pass these bytes through the shader I would be happy, as this feels a bit wrong... :D

Checklist:

Here is a checklist that should completed before merging this given feature.
Any shortcomings from the items below should be explained and detailed within the contents of this PR.

• I am proud of this feature.
  • 😅
• I have performed a self-review of my own code.
• I have manually tested this for different scenarios (different models, formats, devices, browsers).
• I have commented my code in hard-to-understand areas.
• I have made corresponding changes to the public documentation.
• I have added unit and visuals tests to prove that my feature works to the best of my ability.
• I have refactored the code for readability to the best of my ability.
• I have checked that my changes do not introduce regressions in the public documentation.
• I have outlined any known defects / lacking capabilities in the contents of this PR.
• I have listed any remaining work that should follow this PR in the description or jira/miro/etc.
• I have added TSDoc to any public facing changes.
• I have added "developer documentation" in any package README.md that is related / applicable to this PR.
• I have noted down and am currently tracking any technical debt introduced in this PR.
• I have thoroughly thought about the architecture of this implementation.
• I have asked peers to test this feature.

[codecov]

Codecov Report

Merging #2536 (22a5d4d) into master (511407d) will increase coverage by 0.02%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master    #2536      +/-   ##
==========================================
+ Coverage   70.60%   70.62%   +0.02%     
==========================================
  Files         225      225              
  Lines        9753     9753              
  Branches     1271     1271              
==========================================
+ Hits         6886     6888       +2     
+ Misses       2713     2711       -2     
  Partials      154      154              

Impacted Files	Coverage Δ
.../packages/cad-parsers/src/utilities/SectorScene.ts	98.78% <0.00%> (+2.43%)	⬆️

[Strepto]

@larsmoa Does this look like what you wanted?

[larsmoa]

Beautiful @Strepto - thank you!

[larsmoa]

Will be automatically merge when you update your branch, @Strepto