This question already has answers here:
Calculating normals in a triangle mesh
(6 answers)
Closed 9 years ago.
I have legitimately done every research possible for this, and it all just says to simply calculate the surface normals of each adjacent face.
Calculating surface normals is easy, but how the heck do you find the adjacent faces for each vertex? What kind of storage do you use? Am I missing something? Why is it so easy for everyone.
Any guidance would be greatly appreciated.
but how the heck do you find the adjacent faces for each vertex?
Think it otherway round: Iterate over the faces and add to the normal of the vertex. Once you processed all faces, normalize the vertex normal to unit length. I described it in detail here
Calculating normals in a triangle mesh
If you really want to find the faces for a vertex, the naive approach is to perform (linear) search for the vertex in the list of faces. A better approach is to maintain an adjancy list.
Related
My question is similar to this question. I am using python-igraph library to create undirected graph. What I want to achieve is to untangle as much as possible such that minimum number of crossings of edges is achieved. Then I want convert this clean layout to a 2D plane where I can read the the coordinates of each vertex and no vertex is overlapping any other vertex.
For my current graph I have generated the layout based on the Fruchterman-Reingold force-directed algorithm (as shown in the image).
Can anyone give me some hints how can I achieve that? or this cannot be solved in polynomial time because to find the best placement of vertices with minimum of number of crossing is a NP-Hard problem.
I would like to find two vertices of two meshes (1 vertex per mesh) that define the closest distance between them. Or the two triangles would be fine I guess.
However I'm not sure how to search for this in CGAL's documentation, I'm sure that this is doable with some existing tool (probably based on a 3d distance field and/or AABBs). Could I please get a hint (keywords/link) on what to look for?
I've been pointed to the Optimal Distances CGAL package, but it's not exactly what I want, since it outputs the distance and the coordinates, so finding the vertex ID is an additional computational overhead.
I've already implemented a collision detection with CGAL to find the triangle-triangle intersection in a triangle-soup, using AABB-trees. I guess that I should be somehow close to this, although now a simple soup with all me object-triangles wouldn't do the job.
The solution found was this:
CGAL's Optimal Distances package can give an approximation of the closest distance between the convex hulls of two meshes, without explicitly computing the hulls. As a result one gets the shortest distance between these hulls, and the coordinates of the 2 points that lie on them and define this distance.
Then these coordinates can be used as a search-query in kd-trees that contains the original vertices of the meshes in order to find the closest vertices.
In case one mesh is non-convex, the hull that CGAL is using is very approximate, so convex decomposition might be necessary. In such a case one would have to check distances for each convex part and then take the shortest distance.
The above would result in something like this:
enter link description here
I am currently wondering if there is a common algorithm to check whether a set of plane polygones, not nescessarily triangles, contruct a watertight polyhedra. Each polygon has an oriantation (normal vector). A simple solution would just be to say yes or no. A more advanced version would be to point out the edges, where the polyhedron is "open". I am not really interesed on how to close to polyhedra.
I would like to point out, that my "holes" are not nescessarily small, e.g., one face of a cube might be missing. Thus, the "undersampling correction" algorithms dont seem to be the correct approach. Furthermore, I am talking of about 100 - 1000, not 1000000 polygons, so computation time should not really be a problem.
Any hints or tips?
kind regards,
curator
I believe you can use a simple topological test -- count the number of times each edge appears in the full list of polygons.
If the set of polygons define the surface of a closed volume, each edge should have count>=2, indicating that each edge is shared by (at least) two adjacent polygons. If the surface is manifold count==2 exactly.
Edges with count==1 indicate open regions of the surface.
The above answer does not cover many cases. A more correct (but not necessarily complete: I wouldn't know) algorithm is to ensure that every edge of every polygon (or of the mesh/polyhedron) has an even number of faces connected to it. Consider the following mesh:
The segment (line) between the closest vertex and the one below is attached to 3 faces (one one of the outer triangle and two of the inner triangle), which is greater than two faces. However this is clearly not closed.
This question already has answers here:
An algorithm for inflating/deflating (offsetting, buffering) polygons
(15 answers)
Closed 8 years ago.
This is a question that appears to be easy, but I'm having a hard time getting it to work properly.
I have a (nonconvex) polygon defined by a list of vertices. I would like to create another polygon, where every point is shifted outward by a certain amount. I tried scaling the points and then shifting back to the original origin, but that didn't have the effect I want.
I would like for each point to be "outside" of the original point. But "outside" appears to be very difficult to compute, given only a list of points. Is there an easy way to do this?
It seems that you want an offset of the polygon, that is, the set of all points that are outside the polygon and whose distance to the polygon is some given number. The offset is not a polygon, however,
Perhaps you could just scale all vertices with respect to the centroid of the polygon.
I think you're right that inside and outside are hard to define as a global property. But with each component line segment individually, there is a clear definition of left and right (at least, within the context of traversing the path).
So, I think if you traverse your segments counter-clockwise and add segments offset to the right of the current segment, this may be close to what you want. Or traverse clockwise and add segments offset to the left. It may create degenerate shapes at concavities.
I have a piece of abstract triangulation, made entirely out of equilateral triangles, that describes a curved 2d space. As such, some vertices have for example 7 equilateral triangles attached to them. Now I want to draw this as a terrain.
This has to be done in 3d, so I expect a lot of saddle nodes and some cone-like structures. I am currently trying to find a nice algorithm that does this for me, but as of yet I have come out empty handed. In principle you could 'just' solve a large set of quadratic equations that fixes all the distances, but this is unfeasible. I would be content with an algorithm that gives a best approximation.
Any advice?