Is there any way to tell, from within a gl es vertex shader (that is drawing triangles) which of the three vertices is being processed?
Using gl_VertexID doesn't work for me, because it gives the index of the vertex in the list of vertices, but I use indices to specify a different order to draw the vertices, and so the value I want cannot be determined from gl_VertexID alone.
You can add a vertex attribute to represent the indices 0, 1, 2, but as #matic-oblak noted you may have to replicate some vertices that are shared between triangles. If the mesh is "three-colorable" (in the graph theory sense) then you can assign indices without any replication.
A tetrahedron is not 3-colorable, whereas a cube is 2-colorable, and we can triangulate the faces of a cube and get a 3-colorable mesh. Ordinary vertices have degree 6 in a triangular mesh and are "locally" 3-colorable.
Therefore you can 3-color a mesh as much as possible -- where it fails you will have to replicate vertices. Unfortunately 3-coloring is an NP-complete problem , but with a some simple heuristics I think you can do a fairly reasonable job.
As I commented above, what I was looking for is deliberately not available for pipeline efficiency reasons. See the comment by Alfonse Reinheart at the following page:
https://www.opengl.org/discussion_boards/showthread.php/181822-gl_VertexId-gl_InstanceID-gl_PrimitiveID-but-where-is-gl_IndexID
The other answer, posted by wcochran is interesting, and could be a way to pass less information to the rendering pipeline, although as s/he points out, it comes at the cost of some substantial preprocessing.
Related
I am looking for an algorithm to find all (or maximum no of) contiguous faces of a continuous mesh. The faces should be ordered in an array in such a way that each face is preceded by a face linked to it on the mesh. The ultimate goal is to have a single such array. Is it possible even in theory? If not what's the best way to maximize the count of faces in the array?
In this (rather naive) implementation the selection point traverses clockwise covering end vertex of the available edge of the last face covered. But this quickly gets into a dead-end. I also tried both the ends of the edge, or all the available vertices of the face, but sooner or later each one reaches a face with no connections to un-selected faces.
Edit:
It's a triangulated mesh, i.e. each face has exactly three vertices. And the requirement is to have a set of minimum no of arrays (ideally one) covering all the connected faces of the mesh.
This is a hard problem (the Hamiltonian path problem in a planar graph (specifically, the dual of the input graph)), but you may have get good results with a local search method. There's a simple one due to Angluin and Valiant (https://doi.org/10.1016/0022-0000(79)90045-X) and a more complicated effort by Frieze (https://doi.org/10.1002/rsa.20542). These algorithms are proved in theory to work on random graphs only, but graphs without adversarial construction are often amenable too.
I am trying to learn using CGAL. I have questions about which data structures and triangulation schemes to use for my problem.
Problem description:
I have a small number ( < 1000) of particles moving on a sphere. I need to make a triangular Delaunay mesh out of this point cloud. At every time step, I need to:
Remesh the point cloud, only if required, so that the Delaunay criterion still holds. Store the mesh connectivity independently of the point coordinates.
Keeping the topology fixed, do some optimization using an iterative solver to calculate new particle positions. The number of solver iterations can be 100 or more with the same connectivity. At each iteration, the calculations require area of each triangle and some calculations on vertices connected by an edge (i.e. each vertex interacts with first ring of nearest neighbors).
Questions:
How can I change the coordinates of the points associated with mesh (triangulation data structure, surface mesh, polyhedra etc.) vertices without invalidating the iterators or circulators of the triangulation?
How to check when remeshing is required?
Which data structure gives fastest access to all edges and faces in a single pass over the full mesh? Every edge is shared between two triangles. The calculations on the edges are the most expensive. Hence, I want to calculate for each edge only once. Iterating once over all faces and separately over all edges may be less efficient.
Please let me know if any more information is required.
Giving part answers to your questions :
3/ You can use openmesh library to mesh your points. It allows one to reach the first ring of neighbours very fast as explained here, and also all edges and faces. I can't be sure if it is the data structure that gives the fastest access to these informations. To give you a hint of what speed to expect, In my work I use openmesh : running 30 'for' loops, each loop going over the first ring neighbours of the 500 000 vertices of my mesh and computing some arithmetics (typically center of gravity), takes in total less than 100ms.
1/ With openmesh, at any time you can reset a point position without changing its connectivity (it won't delete already defined edges and faces).
2/ To check if remeshing is needed, you have to check wether Delaunay condition is still satisfied at every point of your mesh. If it is not, remesh the whole or swap suitable edges.
Hope this helps!
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'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'm trying to create an inner glow effect for a triangle fan primitive using GLSL ES 2.0 - though only the outer edges are to be subject to the effect at hand. I guess there are many ways to do this, but haven't found any description so far.
There is the technique described in Make the edges of a textured polygon glow in OpenGL ES 2.0, however, this doesn't work for me as I'm working purely with primitive at this stage.
My initial thought was to somehow calculate the distance to the nearest edge in the fragment shader, and then set the color according to wether or not the distance falls within the bounds of some threshold value or not. (Of course, the color and alpha is to be a function of the distance from the nearest edge - the exact gradient profile is not important at this point.)
This approach poses two problems:
1) How do I calculate the distance from a fragment to the nearest edge?
2) How do I exclude common edges in this process, i.e. edges that are common to two (or more) triangles?
Is this a sensible approach, and if so: how do I resolve my two issues? Suggestions for alternative approaches are also greatly appreciated. (For instance, I've been reading that texture data need not be an image, and that it may be utilized for custom purposes. Could a non-image texture be part of the solution?) :)
To answer your two questions, I don't think there is any glsl magic that will do this for you. By the time you get to the fragment shader, there is no longer any information available about edges, especially trying to segregate true edges from internal edges.
What I recommend is to add more vertices to your fan, and use a new custom attribute to define the 'glow level'. See image for example, I would put a row of vertices around the edge, define these (and the center of the fan) to have maximum glow, and then define the edges to have zero glow, and then you can get an interpolated glow value between the edge and the new vertices.