My belly says the naive formula is summing the triangle pyramid volumes to the origin with sign in orientation. It looks like that's what they derived. Which is a generalization of 2d polygon area calculated by summing triangle areas for each edge, I was taught this in a math camp where we calculated map polygon areas on gis data. I remember math knowledge being hard to get pre AI era but I didn't remember it being this hard.
No idea what the author means by "which are equivalent to rendering the mesh and then sampling the render".
My belly says the naive formula is summing the triangle pyramid volumes to the origin with sign in orientation.
Yeah, that would also work but it's a slightly slower formula, sum(det(v1,v2,v3))/6. This one is summing sort of prism+pyramid shapes made by projecting each triangle to the yz plane.
I'd say what author means is the standard solution - which is equivalent to his on triangles but is on pixels ... except there's nothing naive about it and by using GPU parallelism and depth hardware it is lower cost on dense meshes.
Yes, this makes more sense as you at least collapse the third dimensions, but I would assume this formula is still faster when implemented efficiently.
Voxelising, most likely. The naive way's to rasterise the mesh into a 3D grid and count the cells inside, which really is rendering and then sampling the result. It costs resolution cubed instead of triangle count, and the answer's only ever as good as the grid.
Comments
My belly says the naive formula is summing the triangle pyramid volumes to the origin with sign in orientation. It looks like that's what they derived. Which is a generalization of 2d polygon area calculated by summing triangle areas for each edge, I was taught this in a math camp where we calculated map polygon areas on gis data. I remember math knowledge being hard to get pre AI era but I didn't remember it being this hard.
No idea what the author means by "which are equivalent to rendering the mesh and then sampling the render".
Yeah, that would also work but it's a slightly slower formula, sum(det(v1,v2,v3))/6. This one is summing sort of prism+pyramid shapes made by projecting each triangle to the yz plane.
I'd say what author means is the standard solution - which is equivalent to his on triangles but is on pixels ... except there's nothing naive about it and by using GPU parallelism and depth hardware it is lower cost on dense meshes.
I really hope nobody computes the volume by rendering in 3D and counting pixels.
Rendering in 2D and summing per-pixel Z-spans. For a finely meshed shape and approx. result, it has by far the lowest cost.
Yes, this makes more sense as you at least collapse the third dimensions, but I would assume this formula is still faster when implemented efficiently.
Voxelising, most likely. The naive way's to rasterise the mesh into a 3D grid and count the cells inside, which really is rendering and then sampling the result. It costs resolution cubed instead of triangle count, and the answer's only ever as good as the grid.