nmwsharp
Mismatch between uncompressed SurfaceMesh::nCorners() and CornerData::size()
Hi :) I encountered a small issue trying to use geometry-central with polyscope.
Currently SurfaceMesh::nCorners() returns nInteriorHalfedgesCount whereas the capacity check for CornerData uses nHalfedgesCapacity. On a compressed mesh with boundary, the two don't match; bigger CornerData buffers than necessary are allocated and CornerData::size() is larger than SurfaceMesh::nCorners() .
For compressed meshes with boundary this creates issues when trying to combine geometry-central with polyscope and trying to add a corner-based parameterization from geometry-central as a property to the polyscope-mesh (polyscope essentially expects a buffer of size nInteriorHalfedgesCount).
I would expect that intended behaviour here is that exterior halfedges do not contribute to "corners" and CornerData capacity should actually be equal to nInteriorHalfedgesCount for a compressed mesh?
I see now that you are supposed to use permutations for interfacing with polyscope, and that the 1-to-1 mapping of corners to halfedges is probably just the least cumbersome way to implement corner-based properties for modifiable polygonal meshes, despite the memory overhead.
I guess this can be closed, unless someone sees actual benefit in making CornerData::size() fit SurfaceMesh::nCorners() tightly.
Thanks for filing this! Yes you've got it right. For Polyscope interfacing, the permutations should make it all "just work", and if not its a bug.
Actually initially the Corner-related things in geometry-central were all just syntactic sugar for Halfedge. I think they have since diverged a little, but you'll still find the implementation of corners very closely tracks halfedges.
The change you propose sounds like a good change, but I'm reluctant to make it simply for fear of breaking things that are currently well-tested :) For that reason I will go ahead and close for now, but you or anyone else are welcome to re-open if it seems important.
