olson-sean-k
commented
5 years ago It would be useful to provide various data structures, so a non-manifold graph representation should probably not replace the half-edge representation.
The graph abstractions used to implement MeshGraph could be refactored into an internal network API. Rather than refer to the data in the storage layer as topology, the more generic term entity could be used. Even if no other mesh representations are present yet, this code could be refactored. This may coerce a more generic and flexible design and more cohesive nomenclature.
The mutation API is still a big question mark here, but I've been experimenting a bit and I'm convinced that that can become more generic as well (and even become applicable to MeshBuffers).
I'm not sure what naming convention to use for the top-level types exposed by Plexus if this were changed. MeshBuffer and MeshGraph are satisfying, but once more representations are provided that scheme doesn't work so well.
MeshGraphimplements a half-edge graph data structure. This structure is typically limited to compact and oriented manifold representations.Plexus uses the concept of rings (previously called interior paths) to help mitigate these limitations (among other uses) by not requiring that faces be present in a consistent graph. This provides some support for non-continuous surfaces, unbounded composite edges, and other features. Some non-manifold structures can be approximated, but traversals and constraints become a challenge.
Perhaps
MeshGraphcan migrate to a non-manifold representation like Blender's bmesh or the radial edge data structure. This complicates some scenarios, but is generally more flexible than half-edge representations and still offers fairly efficient adjacency queries. It should be possible to reuse graph abstractions (e.g., storage, views, etc.) to implement such a data structure.Alternatively, both representations can be provided by Plexus. This would obviously require some changes to the organization of modules and types.