Closed marip8 closed 2 years ago
Only question would be, broadly, why noether_filtering instead of noether_tpp?
There is already a lot of functionality for mesh and cloud processing (filtering and otherwise) in noether_filtering
so I thought it made sense to go there. Maybe it's worthwhile to rename that package something else later like noether_geometry_processing
and make it the home for code that generally processes inputs to the tool path planners.
and why not use the MeshModifier interface?
Currently MeshModifier
is a construct of the tool path planning pipeline and defined in noether_tpp
, so I didn't use it here. It seems easy enough to compose a MeshModifier
using these functions. I thought about adding a simple implementation that does this extraction, but it didn't seem very valuable because a user would have to pass in a mesh and the set of points on construction. See my working implementation here
This PR adds an interface and utility functions for extracting a submesh from a mesh. It also provides an implementation that uses an extruded polygon to extract a submesh