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.
Related
I got an outline (list of points) for a plane I want to generate. The plane is quite big and I need evenly distributed vertices inside the outline. Each vertex has a color value from red to green to visualize some data in the plane. I need to visualize the data as precise as possible in real time.
My idea was to simply create a grid and adjust all the vertices outside of the outline. This turned out to be quite complex.
This is a quick example what I want to achieve.
Is there any algorithm that solves this problem?
Is there another way to generate a mesh from an outline with evenly distributed vertices?
It sounds like you want to do something like this:
1) First generate a triangulate your polygon to create a mesh. There are plenty of options: https://en.wikipedia.org/wiki/Polygon_triangulation
2) Then while any of the edges in the mesh are too long (meaning that the points at either end might be too far apart), add the midpoint of the longest edge to the mesh, dividing the adjacent triangles into 2.
The results is a mesh with every point within a limited distance of other points in every direction. The resulting mesh will not necessarily be optimal, in that it may have more points than are strictly required, but it will probably satisfy your needs.
If you need to reduce the number of points and thin triangles, you can apply Delaunay Triangulation flipping around each candidate edge first: https://en.wikipedia.org/wiki/Delaunay_triangulation#Visual_Delaunay_definition:_Flipping
Although not totally clear from the question, the marching cubes algorithm, adapted to two dimensions, comes to mind. A detailed descriptione of the two-dimensional version can be found here.
Delaunay meshing can create evenly distributed vertices inside a shape. The image below shows a combined grid- and Delaunay-mesh. You may have a look here.
I am trying to write a Rigid body simulator, and during simulation, I am not only interested in finding whether two objects collide or not, but also the point as well as normal of collision. I have found lots of resources which actually says whether two OBB are colliding or not using separating axis theorem. Also I am interested in 3D representation of OBB. Now, if I know the axis with minimum overlap region for two colliding OBB, is there any way to find the point of collision and normal of collision? Also, there are two major cases of collision, first, point-face and second edge-edge.
I tried to google this problem, but almost every solution is only detecting collision with true or false.
Kindly somebody help!
Look at the scene in the direction of the motion (in other terms, apply a change of coordinates such that this direction becomes vertical, and drop the altitude). You get a 2D figure.
Considering the faces of the two boxes that face each other, you will see two hexagons each split in three parallelograms.
Then
Detect the intersections between the edges in 2D. From the section ratios along the edges, you can determine the actual z distances.
For all vertices, determine the face they fall on in the other box; and from the 3D equations, the piercing point of the viewing line into the face plane, hence the distance. (Repeat this for the vertices of A and B.)
Comparing the distances will tell you which collision happens first and give you the coordinates of the first meeting point (in the transformed system, the back to absolute coordinates).
The point-in-face problem is easy to implement as the facesare convex polygons.
Does anyone know an algorithm which checks for congruence between two sets of polygons? To be more specific, see the figure below.
I'm looking for a way to check whether a given set of colored triangles is congruent to another set, i.e. whether a given set (e.g. the blue triangles) via a number of translations, rotations or reflections can be superimposed on another set (e.g. the red triangles). In the example above, all 3 sets of triangles (blue, red and green) are congruent.
The actual triangle I'm working on is larger than this and has more sets.
I've googled and found this paper, but it concerns 3-D polygons and isn't directly (in my view) implementable.
Any constructive ideas or links would be welcome.
Edit
Just to clarify, each set of triangles must be treated as a whole connected figure, i.e. each triangle in the set is fixed in it's position relative to the other triangles in the set.
Also, I only need an algorithm which could determine whether one set of triangles is congruent to another set, but with a much larger triangle than the one above and with many more sets. Imagine a triangle with side length N and a total of N^2 smaller triangles, divided into N differently colored sets of N triangles.
A combination of rotations and reflections can be represented by a rotation and at most one reflection, so you can ignore reflections if you run a rotation-only algorithm twice, once with the original figure and once with a reflected figure.
The centre of gravity of the triangles (or, easier, the centre of gravity of a figure which has mass only at the vertices of the triangles) is not affected by rotation, so I would start by computing the centre of gravity of each figure. Now represent the figure by a list giving the direction and distance of each point in the figure from its centre of gravity.
If the set of distances are different the figures cannot be rotations of each other, and I guess most non-congruencies will be spotted at this stage. For total cost N^2 you can consider rotating a vertex in one figure to each possible vertex of the other figure and then applying this calculated rotation to all of the other vertices and seeing if they match up. Possibly some version of https://en.wikipedia.org/wiki/Lexicographically_minimal_string_rotation could be used to speed this up. It may help to represent directions by the angle between the directions to vertices after sorting them into order.
I have an application that creates an approximation to sphere by subdividing an icosahedron. The Cartesian vertex coordinates are converted to spherical coordinates so that all vertices sit on the surface of a unit sphere.
What I need to do next is find the nearest vertex to an arbitrary point on the surface of the sphere. I have come up with two simple algorithms...
Brute force search - will be OK for a small number of vertices, but will be excessive for finer subdivisions.
Sorted / Indexed search - sort the vertices into some form of order by azimuth and inclination and then create a rough index to speed up a brute force search by limiting its scope.
I was wondering if there was a more subtle, and hopefully higher performing algorithm that I can use instead of one of the two above.
Update 1: I have just recalled that for another part of the application the vertices store information about their neighbours. My new algorithm is
Pick an arbitrary start vertex. Find which of its neighbours has a smaller distance to the point to locate. Use this neighbour as the new start vertex. Repeat until none of the vertex's neighbours has a smaller distance to the point. This vertex is the closest to the point.
Scanning through the responses, I think I may be off base, but what you're after is simple. I think.
Since you're dealing with just points that sit on the sphere, you can just drop a line from the vertex to the center of the sphere, drop another line from the arbitrary point to the center and solve for the angle created between them. Smaller is better. The easiest and cheapest way I think would be the dot product. The angle basically falls out of it. Here's a link about it: http://www.kynd.info/library/mathandphysics/dotProduct_01/
For testing them, I would suggest picking a vertex, testing it, then testing its neighbors. It SHOULD always be in the direction of the smallest neighbor (angle should always decrease as you get closer to the vertex you're after)
Anyhow, I hope that's what you're after.
Oh, and I came across this page while looking for your subdivision algorithm. Hard to find; if you could post a link to it I think it would help out a lot more than just myself.
One of possible solutions is to build BSP tree for vertices: http://en.wikipedia.org/wiki/Binary_space_partitioning
If the icosahedron has one vertex at the north pole and the opposite vertex at the south pole then there are 2 groups each of 5 vertices which are in planes parallel to the equator. With a little geometry I figure that these planes are at N/S 57.3056° (decimals, not dd.mmss). This divides your icosahedron into 4 latitude zones;
anything north (south) of 28.6528° is closest to the vertex at the nearer pole;
anything between the equator and north (south) 28.6528° is closer to one of the 5 vertices in that zone.
I'm working this as a navigator would, arcs measured in degrees and denoted north and south; if you prefer a more mathematical convention you can translate this all to your version of spherical coordinates quite easily.
I suspect, though I haven't coded it, that checking the distance to 5 vertices and selecting the nearest will be quicker than more sophisticated approaches based on partitioning the surface of the sphere into the projections of the faces of the icosahedron, or projecting the points on the sphere back onto the icosahedron and working the problem in that coordinate system.
For example, the approach you suggest in your update 1 will require the computation of the distance to 6 vertices (the first, arbitrarily chosen one and its 5 neighbours) at least.
It doesn't matter (if you only want to know which vertex is nearest) whether you calculate distances in Cartesian or spherical coordinates. However, calculation in Cartesian coordinates avoids a lot of calls to trigonometric functions.
If, on the other hand, you haven't arranged your icosahedron with vertices at the poles of your sphere, well, you should have !
I have a 3D polygon mesh and a corresponding 2D polygon mesh (actually from a UV map) which I'm using to map the geometry onto a 2D plane. Given a point on the plane, how can I efficiently find the polygon on which it's resting in order to map that 2D point back into 3D?
The best approach I can think of is to store the polygons in a 2D interval tree, and use that to get candidate polygons. Is there a simpler approach?
To clarify, this is not for a shader. I'm actually taking a 2D physical simulation and rendering it wrapped around a 3D mesh. For drawing each object, I need to figure out what point in 3D corresponds to its real 2D position.*
One approach I've seen for triangle meshes goes as follows: choose a triangle, and imagine that each of the sides defines a half space. For a given edge, the half space boundary is the line containing the edge, and the half space does not contain the triangle. Choose an edge whose corresponding half space contains your target point. Then select the triangle on the other side of edge, and repeat the process.
Using this method, you will eventually end up at the triangle that contains your target point.
This method is arguable simpler than implementing a 2D interval tree, although the search is less efficient (if n is the number of triangles, it is O(√n) rather than O(log n). Also, it should work for a polygon mesh, as long as the polygons are convex.
So, if I were trying to just get the thing implemented, I'd probably start with a global search of all triangles - compute the barycentric coordinates of that 2d point for each triangle, find the triangle where the barycentric coordinates are all positive, and then use those to map to 3d (multiply the stu position by the 3d points). I'd do this first, and only if it's not fast enough would I try something more complex.
If it's possible to iterate by triangle rather than by 2d points, then the barycentric method would probably be fast enough. But it seems like you've got a bunch of 2d points at arbitrary positions that need to be mapped, and the points change position from frame to frame?
If you've got this kind of situation, you could probably get a big speedup by implementing a local update per frame. Each 2d point would remember which triangle it was within. Set that as the current triangle. Test if the new position is within the current triangle. If not, then you want to walk the mesh to the adjacent triangle which is closest to the target 2d point. Each edge-adjacent triangle is composed of the two common points on the edge, plus another point. Find which edge-adjacent triangle's other point is closest to the target, and set that as current. Then iterate - seems like it should find it pretty quickly? You could also cache a max size for each triangle, so if the point has moved a lot you can just iterate to the next neighbor without doing the barycentric computation (the max size would need to be the distance such that if you are farther than that distance from any triangle point there is no chance you're inside the triangle. This is the length of the largest edge).
But as you mention in your comments, you can run into problems with meshes that have concavities, holes, or separate connected components, where you may fall into a local minimum. There are a couple of ways to deal with this. I think the simplest is to keep a list of all visited triangles (maybe as a flag on the triangle, vector< bool > or set< triangle index >) and refuse to revisit a triangle. If you find that you've visited all the neighbors of your current triangle, then fall back to a global search. Such failures are likely to be uncommon, so it shouldn't hurt your performance too much.
This kind of per-frame updating can be very fast, and might even be a decent approach for computing the initial containing triangles - just choose a random triangle and walk from there (changes from checking all n triangles to only those that are in roughly a straight line to the target). If it's not fast enough, what you could do is keep a k-d tree (or something similar) of the 2d mesh points as well as a single touching triangle index for each mesh point. To seed the iteration, find the closest point to the target 2d point in the k-d tree, set the adjacent triangle to be current, and then iterate.