# pjdixit

Member

7

108 Neutral

• Rank
Newbie
1. ## Sorting vertices of a polygon in CCW or CW direction

After googling a little bit more I found it. Here is the link in case someone else needs it : http://www.geometrictools.com/Documentation/ClipMesh.pdf. I will go through it and will get back if it solves the problem. Thank you!!
2. ## Sorting vertices of a polygon in CCW or CW direction

Hi..thanks you everyone for getting back. Can you please send me a link to Eberle's paper you mentioned?
3. ## Sorting vertices of a polygon in CCW or CW direction

I really need some urgent help with this problem. I have a set of edges and vertices defining a polygon (not necessarily convex). The vertices and edges are in random order and I want to sort/order the vertices of this polygon in clockwise (or anti-clock wise) direction. please see this page for more detailed description: http://www.dixittech.com/blog/2012/10/28/sorting-vertices-of-a-polygon-in-ccw-or-cw-direction/ Any idea how this can be achieved?
4. ## Perspective to Orthographic and vice-versa

If I know field of view angle and current view volume co-ordinates defined by left_perspective, right_perspective, top_perspective, bottom_perspective, zNear, zFar. Then is it possible to some how find equivalent view volume in orthographic mode, that is left_ortho, right_ortho, top_ortho, bottom_ortho, zNear, zFar? Is it possible to reverse it (to get perspective view volume if I know orthographic view volume and FOV angle?)
5. ## GLUtesselator : Issues with zero-area triangles and T-intersections

I guess i spoke too early. Even with correct normals because of zero-area triangles there is flickering of edges and there are artifacts with stencil shadows. I suppose it is because of limited precision of depth buffer.
6. ## GLUtesselator : Issues with zero-area triangles and T-intersections

How did I miss that! That should work... I guess it wasn't very obvious to me as per vertex normals were re-calculated for each triangle based on the geometry and connectivity information for smooth shading in a separate dll. I guess I just need to figure out a way to pass normal information to the dll and to block re-calculation of normal for zero-area triangles. Thanks a lot!
7. ## GLUtesselator : Issues with zero-area triangles and T-intersections

GLUtesselator : Issues with zero-area triangles and T-intersections [font=inherit][color=#373737][font=inherit]I came across this issue when I was trying to triangulate Text entities using GLUtesselator. However, it can occur during triangulation of any polygon using GLUtesselator. The problem is that sometimes GLUtesselator generates zero-area triangles. Most of the times you can ignore them but there are cases where they can’t be ignored. I am trying to find a solution so that final triangulation of a given polygon do not have any zero-area triangles or T-intersections. As far as I know, GLUtesselator is one of the most robust and stable tesselator available so I would like to stick to it and won’t mind doing some post-processing to fix the triangulation rather than writing a new tesselator myself.[/font][/font] [color=#373737] [font=inherit]I will try to demonstrate the problem with tessellation of character ‘H’. Input vertices to the GLUtesselator are:[/font] [font=inherit][font=inherit]This is how it was triangulated using GLUtesselator. I set the winding to GLU_TESS_WINDING_ODD and GLU_TESS_TOLERANCE was set to default 0.[/font][/font] [font=inherit][/font] [font=inherit][/font] [font=inherit]After preliminary inspection of the triangulation, it seemed as if there were T-intersections at vertex 5 and 10 which raised a red flag as the geometry was further processed by half-edge data structure and T-intersections were not allowed.[/font] [font=inherit][/font] [font=inherit]However, generating the list of triangles showed that tessellation actually generated zero-area triangles and not T-intersections. Here is the list of generated triangles:[/font] [font=inherit][/font] [font=inherit]Legend : T = True , F = False[/font] [font=inherit]The problem is that I can’t use zero-area triangles either as I can’t calculate normal or equation of plane correctly for zero-area triangles. Normals and equation of planes can be very critical for implementing smoothing and shadow generation algorithms so they need to have a valid value.[/font] [font=inherit]So, I am stuck here with a very bad situation: If I have zero-area triangles then I can’t calculate normal and equation of plane correctly which is a must. It is trivial to remove zero-area triangles but if I remove them then I am stuck with T-intersections and I can’t live with them either.[/font] [font=inherit]So I would like to make sure that in cases where GLUtesselator generates zero-area triangles, my application will re-triangulate a sub-portion of the polygon such that there are no zero-area triangles or T-intersections. For our example case, triangulation should look some thing like this:[/font] [font=inherit][/font] [font=inherit]I think its a very fundamental problem and a solution to it will benefit lot of developers working in a similar area. I am sure I am not the first one to stumble upon it. Any suggestions how it can be done? Any alternate approach is very welcome as well.[/font]