Idea in one line: give features that read the live depth buffer exact values, but only on frames where someone is actually reading.
Background: for speed, the interactive renderer writes an approximate per-pixel depth (off by up to one batch's depth span). That is fine when nothing consumes it. But mesh compositing reads this depth every frame, so meshes sit against slightly wrong depth today.
Why not just always be exact: we measured it. Forcing the exact depth path on every live frame costs about 3x on the rasterize stage (0.94 ms to 2.80 ms per frame, 3M splats at 920x668 on an RTX 4090). Not acceptable as a default.
Proposal: track per frame whether a depth consumer is active (mesh compositing, depth view, a hovering pick preview) and enable the exact path only on those frames. No consumer means today's fast path, bit for bit.
Note: align point placement is already exact and unaffected; it renders its own one-off depth capture per click, which costs nothing per frame.
Idea in one line: give features that read the live depth buffer exact values, but only on frames where someone is actually reading.
Background: for speed, the interactive renderer writes an approximate per-pixel depth (off by up to one batch's depth span). That is fine when nothing consumes it. But mesh compositing reads this depth every frame, so meshes sit against slightly wrong depth today.
Why not just always be exact: we measured it. Forcing the exact depth path on every live frame costs about 3x on the rasterize stage (0.94 ms to 2.80 ms per frame, 3M splats at 920x668 on an RTX 4090). Not acceptable as a default.
Proposal: track per frame whether a depth consumer is active (mesh compositing, depth view, a hovering pick preview) and enable the exact path only on those frames. No consumer means today's fast path, bit for bit.
Note: align point placement is already exact and unaffected; it renders its own one-off depth capture per click, which costs nothing per frame.