My output mesh has no triangles!

If you're using a PSLG, you've probably failed to specify a proper set of bounding segments, or forgotten to use the -c switch. Or you may have placed a hole badly, thereby eating all your triangles. To test these possibilities, try again with the -c and -O switches. Alternatively, all your input vertices may be collinear, in which case you can hardly expect to triangulate them.

Triangle doesn't terminate, or just crashes.

Bad things can happen when triangles get so small that the distance between their vertices isn't much larger than the precision of your machine's arithmetic. If you've compiled Triangle for single-precision arithmetic, you might do better by recompiling it for double-precision. Then again, you might just have to settle for more lenient constraints on the minimum angle and the maximum area than you had planned.

You can minimize precision problems by ensuring that the origin lies inside your vertex set, or even inside the densest part of your mesh. If you're triangulating an object whose x coordinates all fall between 6247133 and 6247134, you're not leaving much floating-point precision for Triangle to work with.

Precision problems can occur covertly if the input PSLG contains two segments that meet (or intersect) at an extremely angle, or if such an angle is introduced by the -c switch. If you don't realize that a tiny angle is being formed, you might never discover why Triangle is crashing. To check for this possibility, use the -S switch (with an appropriate limit on the number of Steiner points, found by trial-and-error) to stop Triangle early, and view the output .poly file with Show Me. Look carefully for regions where dense clusters of vertices are forming and for small angles between segments. Zoom in closely, as such segments might look like a single segment from a distance.

If some of the input values are too large, Triangle may suffer a floating exception due to overflow when attempting to perform an orientation or incircle test. (Read the section on exact arithmetic.) Again, I recommend compiling Triangle for double (rather than single) precision arithmetic.

Unexpected problems can arise if you use quality meshing (-q, -a, or -u) with an input that is not segment-bounded - that is, if your input is a vertex set, or you're using the -c switch. If the convex hull of your input vertices has collinear vertices on its boundary, an input vertex that you think lies on the convex hull might actually lie just inside the convex hull. If so, an extremely thin triangle is formed by the vertex and the convex hull edge beside it. When Triangle tries to refine the mesh to enforce angle and area constraints, extremely tiny triangles may be formed, or Triangle may fail because of insufficient floating-point precision.

The numbering of the output vertices doesn't match the input vertices.

You may have had duplicate input vertices, or you may have eaten some of your input vertices with a hole, or by placing them outside the area enclosed by segments. In any case, you can solve the problem by not using the -j switch.

Triangle executes without incident, but when I look at the resulting mesh, it has overlapping triangles or other geometric inconsistencies.

If you select the -X switch and thereby turn off exact arithmetic, Triangle occasionally makes mistakes due to floating-point roundoff error. Although these errors are rare, don't use the -X switch. If you still have problems, please report the bug.

Furthermore, if you have segments that intersect other than at their endpoints, try not to let the intersections fall extremely close to PSLG vertices or each other.

If you have problems refining a triangulation not produced by Triangle: Are you sure the triangulation is geometrically valid? Is it formatted correctly for Triangle? Are the triangles all listed so the first three vertices are their corners in counterclockwise order? Are all of the triangles constrained Delaunay? Triangle's Delaunay refinement algorithm assumes that it starts with a CDT.