In my program I have created a Geometry from the vertices of an intersection between a plane and a mesh. I use this Geometry to create a LineSegments object and it works perfectly. I would like to use the vertices in a couple of other ways as well, but the array of vertices in the Geometry is not in the correct order (the order that LineSegments draws them). I am unable to find where the information is stored that allows LineSegments to draw lines between the vertices in the correct order. The link below shows the problem:
https://gamedev.stackexchange.com/questions/99353/vertex-ordering-with-threejss-exporter
There is only one answer that suggests that you check the faces for more information, but from what I can see there is no information about the faces in my Geometry, it only contains the vertices that I put in there.
Any help would be much appreciated!
In a watertight and topologically correct mesh, every edge is shared by exactly two faces. When you cut by a plane, the two faces generate two edges that meet at a vertex, where the common edge pierces the plane.
So if you have a model such that you can reliably pair the edges of the faces (or if the edges are listed uniquely), you can obtain a list of section edges where the vertices are shared by two edges, and describe a closed polygon (unless the surface itself is open).
You can reconstruct this polygon by going from edge to edge, through the common vertices.
For instance, consider the cube below and assume that its faces are labeled left, right, front, back, top, bottom.
The section is made of five edges that can be labeled lt-rt, rt-rf, rf-bf, bf-lb, lb-lt.
Related
I'm curious how one would deduce 3D coordinates in simple isometric images.
The only approach I could come up with is to do depth-first searches to find the vertices of each face and then use complex branching logic to figure out the vertex position from all the possibilities there are for how faces can be partially hidden. What would be a better approach to go about this?
This is just for hobby, so I'm fine with simplifying the problem further (say by requiring the scene to be composed of only unit voxels or by giving the solution only as coordinates of the midpoints of individual voxels instead of giving the coordinates and their face indices in counter-clockwise order).
I'd assume the input to be given as a matrix of the five different colors I use in the picture. As output I'd expect a list of 3D coordinates, possibly accompanied by a list of coordinate indices for the faces.
I assume that you are able to detect all edges and their direction (among six possilbe). Also if they are complete or occluded. And detect the vertices, so that you get a 2D graph.
Assign the coordinates (0, 0, 0) to some point, such as the lowest vertex. Then following every complete edge from the already known points, you will obtain the coordinates of the endpoints by considering the edge direction (and possibly length) and you will know which coordinate to increment/decrement.
In the end, you will get all coordinates of the endpoints of the complete edges, tell the complete faces, and be able to tell the occluded faces.
I am working with several convex polygons that overlap each other and I need to combine them back together to form one single polygon that may be convex or concave.
The problem is always as follows:
1) The polygons that I need to merge together are always convex.
2) The vertices of each polygon are defined in clockwise order.
3) The polygons are never in any specific order.
4) The final polygon can only be simple convex or concave polygon, i.e. no self-intersection, no duplicate vertices or holes in the shape.
Here is an example of the kind of polygons that I am working with.
![overlapping convex polygons]"image removed")
My current approach is to start from the first polygon and vertex by vertex I loop through all vertices of all of the polygons to find overlap. If there is no overlap, I store the vertex for the final outline and continue.
Upon finding overlapping vertices, I determine which polygon to continue to by measuring the angles of the possible paths and by choosing the one that leads towards the outside of the shape.
This method works until I encounter polygons that do not have vertices overlapping each other, but instead one polygon's vertex is overlapping another polygon's side, as is the case with the rectangle in the image.
I am currently planning on solving these situations by running line intersect checks for all shapes that I have not yet processed, but I am convinced that this cannot be the easiest or the best method in terms of performance.
Does someone know how I should approach this problem in a more efficient manner and/or universal manner?
I solved this issue and I'm posting the answer here in case someone else runs into this issue as well.
My first step was to implement a pre-processing loop based on trincot's suggestions.
I calculated the minimum and maximum x and y bounds for each individual shape.
I used these values to determine all overlapping shapes and I stored a simple array for each shape that I could later use to only look at shapes that can overlap each other.
Then, for the actual loop that determines the outline of the final polygon:
I start from the first shape and simply compare its vertices to those of the nearby shapes. If there is at least one vertex that isn't shared by another vertex, it must be on the outer edge and the loop starts from there. If there are only overlapping vertices, then I add the first shape to a table for all checked shapes and repeat this process with another shape until I find a vertex that is on the outer edge.
Once the starting vertex is found, the main loop will check the vertices of the starting shape one by one and measure how far from the given vertex is from every nearby shapes' edges. If the distance is zero, then the vertex either overlaps with another shape's vertex or the vertex lies on the side of another shape.
Upon finding the aforementioned type of vertex, I add the previous shape's number to the table of checked shapes so that it isn't checked again. Then, I check if there are other shapes that share this particular vertex. If there are, then I determine the outermost shape and continue from there, starting back from step 2.
Once all shapes have been checked, I check that all non-overlapping vertices from the starting shape were indeed added to the outline. If they weren't, I add them at the end.
There may be computationally faster methods, but I found this one to be simple to write, that it meets all of my requirements and it is fast enough for my needs.
Given a vertex, you could speed up the search of an "overlapping" vertex or edge as follows:
Finding vertices
Assuming that the coordinates are exact, in the sense that if two vertices overlap, they have exactly the same x and y coordinates, without any "error" of imprecision, then it would be good to first create a hash by x-coordinate, and then for each x-entry you would have a hash by y-coordinate. The value of that inner hash would be a list of polygons that have that vertex.
That structure can be built in O(n) time, and will allow you to find a matching vertex in constant time.
Only if that gives no match, you would go to the next algorithm:
Finding edges
In a pre-processing step (only once), create a segment tree for these polygons where a "segment" corresponds to a min/max x-coordinate range for a particular polygon.
Given a vertex, use the segment tree to find the polygons that are in the right x-coordinate range, i.e. where the x-coordinate of the vertex is within the min/max range of x-coordinates of the polygon.
Iterate those polygons, and eliminate those that do not have an y-coordinate range that has the y-coordinate of the vertex.
If no polygons remain, the vertex does not participate in any edge of another polygon.
You cannot get more than one polygon here, since that would mean another polygon shares the vertex, which is a case already covered by the hash-based algorithm.
If you get just one polygon, then continue your search by going through the edges of that polygon to find a match -- which is what you already planned on doing (line intersect check), but now you would only need to do it for one polygon.
You could speed that line intersect check up a little bit by first filtering the edges to those that have the right x-range. For convex polygons you would end up with at most two edges. At most one of those two will have the right y-range. If you get such an edge, check whether the vertex is really on that edge.
I'm doing 3D Delaunay, with the incremental method. I've tested it in 2D with an initial triangle for inserting the vertices and it works great, but if I use a triangle for 3D, some vertices do not fall into any circumscribed sphere therefore they don't get inserted.
I've tried with a tetrahedron but if the first node falls into the four of the faces, all vertices create new edges towards this new vertex, and deletes all of the initial triangles.
Whichever shape you take, you will always have to deal with side effects.
The best shape is no shape.
This is what we are doing in the CGAL library
http://www.cgal.org
Look at the manual, chapters "2D triangulations" and "3D triangulations".
See also or the journal paper https://hal.inria.fr/inria-00167199/
You can read my answer for this question (Bowyer-Watson algorithm: how to fill "holes" left by removing triangles with super triangle vertices). If the supertriangle is too small sometimes you end with circumcircle outside of the supertriangle. You can try a point-in-polygon test to avoid it.
I am trying to implement a mesh simplification algorithm by doing a series of edge collapses. Currently, I am going through each triangle and then collapsing the shortest edge and the algorithm is stable(doesn't go out of bounds). But beyond a point, it starts to create broken(holes) artifacts. What is the correct way to determine whether an edge is collapsible or not so that it doesn't lead to non-manifold artifacts(or mesh)?
NOTE: I use a half-edge data structure. Also, I do not want to use any external libraries like OpenMesh or CGAL. I have my reasons for not using them.
There are two main conditions for an edge collapse:
Connectivity
On each side of the collapsed edge, only one pair of edges must be merged. This can be checked by counting the joint neighbour vertices of the two merging vertices (there must be exactly two).
Consider the following example where the red edge is being collapsed:
The triangle between the orange and cyan edge is not manifold anymore.
Geometry
Triangles must not flip during the edge collapse. This can be checked by calculating the angle between the triangle normal before the flip and after the flip for triangles that are kept.
Here is an example where the normal of the green triangle is flipped during the collapse:
I'm using PyGTS to construct domain specific 3D geometry. It doesn't have binding to triangulation functions of GTS, so I'm using poly2try instead. I triangulate coplanar polygon with 6 vertices, then filter it's edges on number of faces that they belong to, that way I obtain original outline of polygon, but with edges already attached to faces.
Next step is to "extrude" these edges along Z axis. For PyGTS boolean operations to work, all edges needs to be reused and the object must be closed (no edge belonging to just 1 face). So I want to iterate over my outline edges and build up sides of extrusion, reusing original polygon edge, 3 more, and saving one of those for reuse in next iteration. For this to work, those outline edges needs to be sorted so that: e1.v2 = e2.v1 and e2.v2 = e3.v1 and so on.
How do I sort these outline edges? Original sorting is lost when the base polygon is triangulated.