Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider a non-manifold graph representation. #30

Open
olson-sean-k opened this issue Jul 16, 2019 · 1 comment
Open

Consider a non-manifold graph representation. #30

olson-sean-k opened this issue Jul 16, 2019 · 1 comment

Comments

@olson-sean-k
Copy link
Owner

olson-sean-k commented Jul 16, 2019

MeshGraph implements 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 MeshGraph can 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.

@olson-sean-k
Copy link
Owner Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant