HalfegeMesh::nBoundaryVertices() does not exist

[rreusser]

Thanks for the great library! I'm just starting to work through it. I noticed along the way that the documentation page lists:

size_t HalfedgeMesh::nBoundaryVertices() Returns the number of vertices incident on the boundary.

The only reference I can find to this method though is in the docs.

Perhaps the method was unimplemented, renamed, or removed?

[rreusser]

As I go through things, I've noticed quite a few small nits. I can list them here if it's useful, but am glad to take suggestions on if/how to most easily submit small items like this. 😄 I can batch them in a single PR if that's easiest.

Actually here's a list:

• size_t HalfedgeMesh::nInterioHalfedges(): typo
• HalfedgeMesh::nCorners(): missing
• HalfedgeMesh::splitEdge(): Seems to be named splitEdgeTriangular
• HalfedgeMesh::trimStorage(): Unimplemented
• makeCompressed(): named compress()
• HalfedgeMesh::imaginaryHalfedges(): not implemented
• compress(): listed in the header file but unimplemented
• canonicalize(): listed in the header file but unimplemented

[nmwsharp]

Ah excellent, thanks so much. Listing these is very helpful to me, I'll get them fixed as soon as I have some time to code for this library, either by implementing or removing from the docs.

As you've discovered, geometry-central indeed has some dusty corners with unimplemented / incomplete features :sweat_smile:. We're prepping significantly clean it up and create a bunch of tutorials, probably for a v1.0 release some time in the early summer.

[nmwsharp]

Also any fixes you would like to contribute are very welcome! Feel free to batch them in to one big PR. It's okay to update the documentation markdown files even if you can't build them, I can confirm they render correctly before merging.

[rreusser]

Cool, yeah, didn't want to inundate you with nitpicks if you had a different roadmap, but I'm glad to contribute fixes/cleanup if it's useful. Timeline is probably a few days before I have time to work on it and have a useful unit of work.

Also, I might have written embind bindings for this 😬, which I'll note was exceptionally easy because the straightforward style of the code lends itself very well to it, which I really appreciate! https://gist.github.com/rreusser/a59e18b149d6b7189a920edc0c8b7091 (Iterators were an exception which I, unfortunately think are most easily accomplished with a function callback, e.g. mesh.forHalfedges(he => ...))

Further aside, I was torn between this and geometry-processing-js. Native js is an obvious big win if only to avoid having to manually manage memory. They're both great, but it seemed like this library maybe had slightly loftier aspirations at creating a very tight, extensible foundation. I also really appreciated the flat array data storage of this library for a number of reasons.

[nmwsharp]

Also, I might have written embind bindings for this...

Woah, that's so cool! I'm personally a js novice, but that setup for the bindings looks super reasonable.

In a perfect world we might somehow combine this library with geometry-central-js... perhaps one day :)

[rreusser]

Sorry to inundate you, but here's a live notebook with a WASM-compiled prototype: https://observablehq.com/d/d0df0c04ce5c94fc

In short, memory management is horrible, but it's really good at passing arrays of primitive values around efficiently, which makes it pretty viable for actual usage and hooking up to WebGL. I won't keep bugging you about JavaScript, but I'm generally pretty interested in pushing things toward easy distribution and interactivity on the web, so I'll probably just keep poking around for a bit and see if anything comes of it. 🤷

[nmwsharp]

This is awesome! Thanks so much for sharing, seeing it in notebook form is so sweet.

I will definitely find some time to play around with this. Maybe one day we could include "official" support for a JS-friendly api like this.