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.
Related
How can I generate a circular grid, made of tiles with uniform area/whose vertices are uniformly distributed?
I'll need to apply the Laplacian operator to the grid at each frame of my program.
Applying the Laplacian was easy with a rectangular grid made of rectangular tiles whose locations were specified in cartesian coordinates, since for a tile at (i,j), I knew the positions of its neighboring tiles to be (i-1,j), (i,j-1), (i+1,j), and (i,j+1).
While I'd like to use polar coordinates, I'm not sure whether querying a tile's neighborhood would be as easy.
I'm working in OpenGl, and could either render triangles or points. Triangles seem more efficient (and have the nice effect of filling the area between their vertices), but seem more amenable to cartesian coordinates. Perhaps I could render points and then polar coordinates would work fine?
The other concern is the density of tiles. I want waves traveling on the surface of this mesh to have the same resolution whether they're at the center or not.
So the two main concerns are: generating the mesh in a way that allows for easy querying of a tiles' neighborhood, and in a way that preserves a uniform density distribution of tiles.
I think you're asking for something impossible.
However, this is a technique for remapping a regular square 2D grid into a circle shape with a relatively low amount of warping. It might suffice for your problem.
You might want to have a look at this paper, it has been written to sample spheres but you might be able to adapt it for a circle.
An option can be to use a polar grid with a constant angular step but varying radial steps, so that all cells have the same area, i.e. (R+dR)²-R²=Cst, giving dR as a function of R.
You may want to reduce the anisotropy (some cells becoming very elongated) by changing the number of cells every now and then (f.i. by doubling). This will introduce singularities in the mesh, i.e. cells with five vertices instead of four.
See the figures in https://mathematica.stackexchange.com/questions/78806/ndsolve-and-fem-support-for-non-conformal-meshes-of-a-disk-with-kernel-crash
Given a 3D object in Computer graphics, whose surface is represented as a 3D triangular mesh (mesh of 3D triangle objects), I need to find the maximum continual Convex patches on the surface of the given 3D object.
I am using OpenGl to render the graphics within a C++ program. What kind of methods or algorithms should I use to find the convex patches.
I have to apply different colors to the different convex patches on the object to signify the selection.
Say I have a sphere then the whole sphere is one maximal convex patch. Any portion of the sphere surface will be a convex patch, by maximal I mean the maximum continuous convex patch that can be found. Well in the rendering, depending on the viewing angles, the maximal convex patches visible to the viewer will have to colored.
Start from any triangle. Traverse it's edge's and check that the angle between the two triangles is less than 180deg. If it is add it to the current selection and continue expanding.
The check is actually really simple if you use vector geometry. Say A - B is the common edge with C on the selected side and D on the other. Then just check if dot(cross((A-B), (D-B)), cross((A-B), (C-B)) < 0.
Unfortunately OpenGL doesn't help with object algorithms. It only handles converting triangles to pixels.
I need to do it using OpenGL
Then you're out of luck. OpenGL only draws points, lines and triangles. OpenGL is not a 3D modelling library, OpenGL is not a scene graph, OpenGL is not a graphics engine.
It does not do all purpose geometry processing (it may be possible to use a combination of geometry/tesselation shaders, transform feedback and compute shaders to do it, but it would be very cumbersome to implement).
I'm trying to convert a polygonal 3D mesh into a series of topographic curves that represent the part of the mesh at a specific height for every interval. So far, I've come up with the idea to intersect a horizontal plane with the mesh and get the intersection curve(s). So for this mesh:
I'd intersect a plane repeatedly at a set interval of precision:
and etc.
While this is straightforward to do visually and in a CAD application, I'm completely lost doing this programmatically. How could I achieve calculating this in a programming environment/ what algorithms can I look into to achieve this?
I'm programming in an STL C++ environment (with Boost), loading .obj meshes with this simple loader, and need simple cartesian 2D points to define the output curve.
An option is to process all the faces in turn and for every face determine the horizontal planes that traverses them. For a given plane and face, check all four vertexes in turn and find the changes of sign (of Zvertex - Zplane). There will be exactly two such changes, defining an edge that belongs to a level curve. (Exceptionally you can find four changes of sign, which occurs when the facet isn't planar - join the points in pairs.)
Every time you find an intersection point, you tag it with the (unique) index of the plane and the (unique) index of the edge that was intersected; you also tag it with the index of the other edge that was intersected in that face.
By sorting on the plane index, you can group the intersections per plane.
For a given plane, using a hash table, you can follow the chain of intersections, from edge to edge.
This gives you the desired set of curves.
I am looking for an efficient algorithm for mesh (set of triangles) and cone (given by origin, direction and angle from that direction) intersection. More precisely I want to find intersection point which is closest to the cone's origin. For now all what I can think about is to intersect a mesh with several rays from the cone origin and get the closest point. (Of course some spatial structure will be constructed for mesh to reject unnecessary intersections)
Also I found the following algo with brief description:
"Cone to mesh intersection is computed on the GPU by drawing the cone geometry with the mesh and reading the minimum depth value marking the intersection point".
Unfortunately it's implementation isn't obvious for me.
So can anyone suggest something more efficient than I have or explain in more details how it can be done on GPU using OpenGL?
on GPU I would do it like this:
set view
to cones origin
directing outwards
covering the bigest circle slice
for infinite cone use max Z value of mesh vertexes in view coordinate system
clear buffers
draw mesh
but in fragment shader draw only pixels intersecting cone
|fragment.xyz-screen_middle|=tan(cone_ang/2)*fragment.z
read z-buffer
read fragments and from valid (filled) select the closest one to cones origin
[notes]
if your gfx engine can handle also output values from your fragment shader
then you can skip bullet 4 and do the min distance search inside bullet 3 instead of rendering ...
that will speed up the process considerably (need just single xyz vector)
I've been searching for vector graphics and flash for quite some time but I haven't really found what I was looking for. Can anyone tell me exactly what area of mathematics is required for building vector images in 3D space? Is this just vector math? I saw some C++ libraries for it but I wasn't sure if it was the sort of vectors meant to for smaller file size like flash images are. Thanks in advance.
If you're wanting to do something from scratch (there are plenty of open-source libraries out there if you don't), keep in mind that "vector graphics" (this is different than the idea of a 3D space vector) themselves are typically based on parametric curves like Bezier curves, which are essentially 3rd degree polynomials for each x, y, and/or z point parameterized from a value t that goes from 0 to 1. Now projecting the texture-map image you create with those curves (i.e., the so-called "vector graphics" image) onto triangle polygon via uv coordinates would involve some interpolation, which is fairly straight forward linear algebra, as you would utilize the barycentric coordinate of the 3D point on the surface of the triangle polygon in order to calculate the uv point you want to look-up from the texture.
So essentially the steps are:
Create the parametric-curve based image (i.e, the "vector graphic") and make a texture map out of it
That texture map will have uv coordinates
When you rasterize the 3D triangle polygon, you will get a barycentric coordinate on the surface of the triangle from the actual 3D points of the triangle polygon. Those points of the polygon should also have UV coordinates assigned to them.
Use the barycentric coordinates to calculate the uv coordinate on the texture map.
When you get that color from the texture map, then shade the triangle (i.e, calculate lighting, etc. if that's what you're doing, or just save that color of the pixel if there is no lighting).
Please note I haven't gotten into antialiasing, that's a completely different beast. Best thing if you don't know what you're doing there is to simply brute-force antialias through super-sampling (i.e., render a really big image and then average pixels to shrink it back to the desired size).
If you've taken multivariable calculus, the concepts behind parametric curves and surfaces should be familiar, and a basic understanding of linear algebra would be necessary in order to work with barycentric coordinates and linear interpolation from 3D vectors.