architecture for mesh class

Started by
0 comments, last by Andy Somogyi 6 years, 7 months ago

Hey guys, 
 

I’m designing a new mesh data structure for dynamic mixed-dimension meshes. One of the key things that it will support is stellar operations for mesh modification such as regular-edge-collapse, singular-edge-collapse, edge-split, triangle-split, vertex-join, etc…

I don’t really know how many of these mesh operations I’ll support, but I expect the number to change over time. 

My question, from an architectural standpoint, is where do you suppose it would be best to implement these operations? 

I have the mesh structure encapsulated in a class, MxMesh, and the mesh class provides methods to add new primitives. 

I’m somehow reluctant to add all these mesh modification operations as methods on the mesh object, as then the mesh object basically becomes the dumping ground for all functionality. I’m thinking it would somehow be better, i.e. separate concerns better if I place the modify operations as static methods in a different class. 

Basically, I’m looking at how to best organize three sets of functionality: 

1) the actual mesh data storage — this obviously belongs in the mesh class
2) add new primitives (triangles, vertices) — currently methods of the mesh class
3) modify operations (there could be a lot of these) — would it be best to add these to the mesh class, or pull them out separately? 

Note, I can be a bit schizophrenic when it comes to design, as I’ve worked a lot with Lisp, Scheme, Smalltalk, C++, Objective-C, so I have little functional programming voices constantly bickering in my head with little object-oriented voices :)

thanks

This topic is closed to new replies.

Advertisement