Wrong computation of error bounds in nanite.cpp

[Axel-Reactor]

Hey Arseny,

I was playing around with clustered LODs and by visual inspection the result never looked like it was reducing triangles enough with distance while using a formula similar to what you have in nanite.cpp.

meshoptimizer/demo/nanite.cpp

Line 31 in d40efb0

return bounds.error / (d > camera_znear ? d : camera_znear) * (camera_proj * 0.5f);

I believe this is incorrect: Area in screen space reduces by distance^2, not distance, so it really should be dividing by d * d. This visually looks much closer to what I would expect too.

[zeux]

Area in screen space reduces by distance^2

Sure, but this isn't meant to be computing area or scaling with it - all quantities involved here are linear (e.g. error is approximating distance between the simplified mesh and the original mesh, so the computation here approximates the distance in pixel-related units). In traditional QEM, the error produced by quadrics scales as a square but that is not the case for any of the meshopt functions.

[Axel-Reactor]

I mean visually it just looks wrong this way. The tri density in screen space should be approximately the same at any distance, no? It gets way higher than that with just error / d very quickly.

[zeux]

I would not necessarily expect the triangle density to be the same/similar at every distance: if the camera is close to the mesh and the source mesh isn't tessellated too aggressively, you'd expect to have source triangles but as the camera gets further away, eventually triangles will get smaller (presumably approaching the size of individual pixels), as the details need to be preserved. In well tessellated but more planar areas of the source mesh you will get larger triangles pretty quickly, whereas in areas with complex geometry the triangles will tend towards pixel sized to preserve silhouettes, as well as lighting if normals are factored in.

In other words, I'd guess it depends on the mesh but triangle density isn't really explicitly controlled here, as the goal is to select a DAG cut where the error is imperceptible (which doesn't always imply uniform triangle density).

I haven't tried to use d * d, the above is just the expectations based on how the math is supposed to work here. I'd guess that using d * d results in visible loss of quality (as in, switching between original geometry & simplified geometry will be much more apparent), but I can't test this easily for the next few weeks.

[Axel-Reactor]

They are way way smaller than a pixel though, it gets really alias-y and flickery. Because of the 1/x curve at some distance essentially nothing changes anymore, you can't even reach the terminal clusters unless the object is absolutely tiny on screen. I don't have it running right now, I can provide some screenshots later, that will illustrate it better.