Oh I should say for clarity: when the sphere is small, centered in the view (view-space XY close to 0) and does not intersect the near plane, my approach and Nanite's full fledged computation with projection should yield the same selection criteria (once you correct for camera field of view, pixel error conversion and the like). They are only different when the sphere is significantly off-center such that perspective distortion is applied, cuts the near plane (in which case my code would generally assume "camera is inside" and yield somewhat different results), or is pretty close to the viewpoint (in which case my code would be a bit more pessimistic about the error vs the correct computation that Nanite is doing). This is why I say "similar in principle" above: the logic is more or less the same, but I choose to approximate the camera projection mechanics.

If you want to replicate the entire Nanite computation I think it would be sufficient to implement the figure 3.15 from the paper you linked, solving it as a 2D trigonometry problem. You'd probably need to handle the near clipping case separately.

Also this is solving a slightly different problem, but actually Nanite code looks like a simplified subset of https://jcgt.org/published/0002/02/05/ to me, down to variable names (B/H/T), so maybe that's where they got the derivation from.

Thanks for all the thoughts!

I think that yeah, so long as:

1. Error is monotonic
2. Group LOD bounds contain all child LOD bounds

Then finding the closest point (P) on the LOD sphere, projecting a sphere with center = P and radius = error, and then checking if the projected size is < 1 pixel works for determining the LOD. Before reading your post I was confused why that would be valid, but I understand now that if a parent bounding sphere contains all child bounding spheres, then the distance to the parent bounding sphere is always less than distance to the child, and it ends up working out once you project the error.

The tricky part like you said is if you're inside the LOD bounding sphere (distance to closest point < 0). For leaf clusters you have to accept them - that close, there is nothing simpler that won't have visible error. For non-leaf clusters, it's trickier. I think you probably want to reject the cluster by returning infinity like you said.

I'm going to play around with this when I get a chance, but I feel like I have a better idea of what's going on now, and what the MBT paper was trying to say. Thanks for the insights!

Also this is solving a slightly different problem, but actually Nanite code looks like a simplified subset of https://jcgt.org/published/0002/02/05/ to me, down to variable names (B/H/T), so maybe that's where they got the derivation from.

I'm also using this already (with the formula from your blog) for occlusion culling bounds, so I can just reuse it and add a check for clipping :) https://github.com/bevyengine/bevy/blob/d016e52843ad62f8e635f34ad02994bdeb2b2559/crates/bevy_pbr/src/meshlet/cull_clusters.wgsl#L161-L190

Can you speak more about this paragraph you wrote?

I should say I am hesitant to comment too much on this because my description is based on my reading of Nanite's code, and it's certainly imprecise in a few places. For example, using the projected sphere size based on my blog isn't correct - the "simplified subset" I was referring to just concerns the boundary vertices they use for the projection math, but the way you get from them to the projected bounds (in my blog) is by projecting them, which is correct for that task, but this task is different, and what they do in this case is they only use these boundary points to compute the solid angle of the sphere, and then use the distance-to-sphere-boundary-along-view-axis (aka view-space Z minus radius, or maybe plus, I forget where their Z axis points) to get the view-space equivalent of this in the worst case. This is not quite the same, especially for spheres that are close to camera, and could be part of the problem here.

I don't love their method in general, it's complex to derive and I think it's still an approximation due to some shortcuts, but I guess what I am saying is the best reference for that specific method is probably their source, not my description :)

I'm not convinced rejecting the meshlet and using a finer LOD makes sense. It also seems like a strange method to me to begin with, and the paper does not explain it well or link to something else that does.

Rejecting the meshlet isn't quite correct, but it's close. The more correct way is (I think) the math I updated in the latest code, which clamps the distance to znear. It's still using radial distances but I think just using view space Z makes this sufficiently precise in practice. If I get some time in the next few days I could try that out in the branch you linked - I'm surprised it didn't work for you but I don't think we mean the same things by the same terms, for example I wasn't quite suggesting projecting the sphere with the radius equal to the error using the projected bounds math.

Aside of that, maybe some intuition for what any of this code should be doing would help; I don't agree that this is a strange method and while the paper certainly doesn't do a good job at covering any of this, I don't think it matters. Let me try to describe this differently.

Imagine you had a perfect value for the error that meant the Hausdorff distance between original and simplified mesh. QEM does not give you that, attributes complicate the picture, etc., so all of this (Nanite implementation included) is an approximation and there's fudge factors involved, but let's suppose we had that perfect value.

That value is a scalar. This means that somewhere there are two points on the two surfaces with this value as a distance, but you don't know where this segment is.

When you have a merged bounding sphere, you know that any points of the original or simplified mesh are inside that sphere, so you know that this worst case segment is somewhere within it and it has the length you know, but the endpoints are unknown.

What you want, then, is to see if this segment with the worst case length can be projected on the screen with a >1px projected segment length. Without knowing where this segment is, you have to assume the worst.

If the camera position is inside that sphere, the worst case for a segment length is error / znear (here and elsewhere I omit the projection into screen space, because it's just a scale on top, and focus on the projection math). This is because every vertex position is divided by the view-space Z; to maximize the projected length, you need to minimize each Z of the endpoint but have them be >= znear because the segment gets clipped (and gets shorter) otherwise. This is exactly what my updated code will compute :) (again with a caveat that for perfect projection math you want to get the distance-to-sphere-surface-along-view-vector, not the radial distance).

The only case where this is completely impossible is the case where the sphere is cut by the near plane such that the cut can never contain a segment of this length. In this case I believe Nanite's code will compute a more granular error bound, whereas simply dividing error by znear in this case overestimates it. This case should be very rare, because it means that the center of the meshlet is behind znear plane, so you're likely looking at the mesh surface from inside (or looking from outside but camera is inside some extremely concave region).

If the distance to sphere surface along view vector (aka view space Z) is d which is larger than znear, then to get the worst case projected segment length you need to assume the sphere is oriented such that the segment is parallel to the camera plane (again, consistent Z) and both segment endpoints touch the sphere boundary. Unless the segment length is comparable in side to the sphere radius/diameter, this will mean this segment's Z is close to the distance to sphere surface. Maybe there's a neat way to approximate this a little better still (e.g. error / (distance - error * 0.5f) might be closer and fairly conservative), Nanite doesn't try to nor should it because as I mentioned above in practice QEM errors are Very Approximate.

Anyway... that's it, that's what that math should be doing. Unreal uses the math I tried to describe to compute the world space size of this worst case segment that'd map to a pixel, unless I'm missing something crucial I like the formulation that directly computes [an approximation of] the worst case projected size of the error segment contained within the sphere, but it's roughly the same.

But also taking a very brief look at the code, isn't project_view_space_sphere_to_screen_space_aabb returning 0..1 results? I haven't looked at that code closely to check that it matches my blog, but my blog returns the 0..1 results, and I think elsewhere in Bevy's code the results are multiplied by dimensions. So in your code you don't actually have "pixels".

I wrote out a bunch of stuff, deleted it, wrote more, and deleted that too. I'll leave it here as I don't want to take up too much of your time, but I'm starting to get the shape of this I think. Something about the the closest point on the bounding sphere, and then treating the simplification error as a line along the viewing angle within the sphere. I'm going to have to draw some diagrams and think this over more, but I feel closer to understanding at least. Thanks for taking the time to help me.

But also taking a very brief look at the code, isn't project_view_space_sphere_to_screen_space_aabb returning 0..1 results? I haven't looked at that code closely to check that it matches my blog, but my blog returns the 0..1 results, and I think elsewhere in Bevy's code the results are multiplied by dimensions. So in your code you don't actually have "pixels".

Well that would explain it, I totally forgot to multiply by the view size... For some reason I thought it was part of the function already😅. That does make my results look fine (not necessarily good or grounded in logic, but hard to see any position-based deformity due to LODs now).

For this direction (camera plane => screen space) it should be cot, because you're simulating the perspective projection matrix transform (which has cot(fovy/2) in the [1][1] element).

If you are doing the inverse math, like going from pixels to units in view space, then you'd multiply by tan (and multiply by Z instead of dividing).

camera_proj is the same as P11 in https://zeux.io/2023/01/12/approximate-projected-bounds/.

Nvm, cot(x) is the same as 1 / tan(x) 😅.