What would be recommended ways to generate surface meshes of a particular kind of body given the following?
The geometric body is an extruded 3D "tube" segment. The tube segment has the following properties:
- At each value of X, the cross-section is always a simple polygon in the Y-Z plane
- The polygons are not guaranteed to be convex
- The polygons are not necessarily constant as X is traversed; they smoothly dilate and/or change shape, and the areas of the polygons smoothly vary
- The centroids of each X = const polygon, if connected together with simple line segments, would form a very smooth, well behaved "thread" with at most gentle curvature, no sharp bends, folds, or loops, etc.
- The surface section is capped by the planar cross-sectional polygons at X = X_start and X = X_end
Objective:
- Generate a triangulated surface mesh of the tube surface, respecting the fact that it is bounded at the start and end by flat, planar cross-sectional surfaces
- The mesh should be of the tube, not a convex hull of the tube
- If the tube surface mesh maintains the property that there is a flat simple polygonal cross-section formed by the vertices at X = X_start and X = X_end, then I have existing code which can mesh the end caps; the real problem I'm trying to solve is to get the 3D tube surface mesh generated. If the solution also can generate the end caps, that's fine too. However, the end cap surfaces need to be identifiable as such for output purposes.
- Once the mesh is generated, it needs to be written in a format like OFF, which I think I can handle based on code included with CGAL, examples, etc. The point here is that I don't need to be able further process the mesh (e.g. deformations, add/remove points) programmatically after it is generated.
Known inputs and properties:
- I have the polygonal cross-section tube surface vertices at an arbitrary number of X = const stations between X_start and X_end ; I can control the spacing in the X direction as necessary when I create/import the points
- The vertices lie exactly on the tube surface and are not corrupted by any noise, joggles, sampling, approximations, etc.
- I do not have any guarantees about the relative position of vertices forming each cross-sectional polygon, other than that the polygon vertices are oriented clockwise
- I can generate normals for the polygonal vertices in terms of their Y-Z components, but I don't have a priori information about their normal components in the X direction
- I can generate any number of vertices on the end caps if necessary
- Right now the vertices are 3-space floating-point coordinate values, but if it could somehow help, I could turn each cross-section into a formal CGAL 2D arrangement
- Estimated number of vertices would likely be less than 1000, definitely less than say 15K. Processing time is not a concern.
Ideals:
- Ideally, the surface mesh would just use the vertices I have, without subtracting or moving any of them, but this is not a hard constraint so long as they are "close"
- I need simple polygonal vertices at X_start and X_end so I can cap the surfaces as intended
Initially, CGAL's Poisson Surface Reconstruction method seemed promising, but in the end it seems like it leads to a processing pipeline that might smear the vertices I have; additionally, I don't have full 3D normal information for the points other than the end caps. Moreover, the method would seem to have issues with the sharp, distinct cross-section terminal face surfaces. Maybe I could get around the latter by putting in a bunch of benignly false vertices to extend and terminate the tube, then filter out parts of the triangulation I don't need, but there's no guarantee that the vertices at X_start and X_end would remain, and I would have to "fix-up" the triangulation crossing those planes, which seems non-trivial.
Another possibility might be to compute a full 3D volume mesh using CGAL's 3D mesh generator, but just write out the portion comprising the surface mesh. Is this reasonable? If I could retain the original input vertices, and this overall approach is reasonable, I could filter as I wrote out the triangulation to distinguish between the faces forming the end caps vs. the tube surface.
I also saw this SO question Representing a LiDAR surface using the 3D Delaunay Triangulation as basis? which seems to have some similarities (trying to just retain the input points, and some foreknowledge of the surface properties), but in the end I think my use case is too different.
