Triangle.NET: Shewchuk's mesh generator in C#

What Triangle.NET generates and for whom

Triangle.NET generates 2D constrained Delaunay triangulations and high-quality meshes of point sets or planar straight line graphs. The code is based on Jonathan Richard Shewchuk's Triangle project.

The domain is computational geometry, and the audience is a .NET developer who has a set of points or a planar graph and needs a triangulation of it. The reason to reach for this rather than a general geometry library is the quality control. Shewchuk's generator is known for producing meshes that satisfy angle constraints, and the feature list here is specific about which of his capabilities have been carried across: constrained Delaunay triangulation of planar straight line graphs, incremental, sweepline and divide and conquer Delaunay triangulation algorithms, high-quality triangular meshes with minimum and maximum angle constraints, mesh refinement, mesh smoothing using centroidal Voronoi tessellation, and node renumbering with Cuthill-McKee.

That last one is a small feature that says a lot. Cuthill-McKee renumbering exists to reduce the bandwidth of a matrix derived from the mesh, which matters when the mesh feeds a finite element solve. It is not something a plotting library would include.

The file formats are also Shewchuk's, the `.node`, `.poly` and `.ele` files. Reading and writing them means the output of this library can go straight into the rest of the Triangle ecosystem, which is a genuine practical advantage over a library with its own format.

The repository is small in structure, with a `src/` directory, a README and a `.github/` directory, and the default branch is `master`. The last push to the tree was on 2026-06-10, and there are no GitHub releases.

The three triangulation algorithms and what each is for

Shewchuk's original code offers more than one way to build a Delaunay triangulation, and Triangle.NET carries that choice through rather than picking one for you.

The incremental algorithm adds points one at a time, maintaining the triangulation as it goes. The sweepline algorithm processes points in sorted order. The divide and conquer algorithm splits the point set and merges the results. Each is listed as a supported feature, which means the choice is exposed rather than hard coded.

The distinction matters because the algorithms do not have the same behaviour on every input. A degenerate or near degenerate point set, where several points are nearly collinear or nearly cocircular, is exactly the case where the naive implementation picks the wrong circumcircle and produces a non Delaunay triangle. Shewchuk's contribution was to handle those cases correctly, and the whole reason to use his code rather than a general purpose library is that the hard cases are the ones being handled.

The constrained part is the other half of the value. A plain Delaunay triangulation of a point set ignores your intent. A constrained Delaunay triangulation respects segments you specify, so that a river must appear in the mesh, or a fault line must not be crossed by an element. For anyone generating a mesh of a physical domain, that is not a nicety, it is the requirement.

The quality features build on top of that base. Minimum and maximum angle constraints remove the slivers that make a mesh numerically useless in a solver. Refinement adds points until the constraints are met. Centroidal Voronoi tessellation smoothing moves the vertices towards the centroid of their Voronoi cell, which evens out the element sizes without changing the topology.

Where to look: the wiki and the examples project

There is no installation command to copy, and there is a reason for that beyond the usual ones.

The README's first pointer is to the wiki, which is where the getting started material lives. The second is the Triangle.Examples project inside `src/Triangle.Examples`, described as an extensive list of examples, with an overview page in the wiki. The project description lists `src/` as the only substantial top level entry, so the examples live with the code rather than in a separate directory.

Because there is no package to install, the practical route is to take the source and reference it from your own project. For a .NET engineer that means adding the project or its files to a solution. The exact target frameworks and project file layout are not described in the README, so the project files themselves are the authority on that, and the examples project is the quickest way to see how the API is meant to be called.

The examples matter more than usual here, because the API surface is the part the README says least about. The feature list tells you the library can do things; the examples show you the shape of the calls, the order in which you construct a mesh, and which inputs are required. The wiki's Examples overview is linked from the README precisely so that a new user can see working code before touching the API.

The README also points to three papers for anyone who wants the algorithms themselves, all of Shewchuk's and Erten and Üngör's on triangulations with locally optimal Steiner points. Reading the Delaunay refinement paper is the standard way to understand why the angle constraints behave the way they do, and it explains the parameter choices that the API exposes.

The licence problem, stated by the author himself

The licence section of the README is the most important paragraph in the project, and it deserves to be read before the feature list.

The original C code published by Jonathan Shewchuk comes with a proprietary licence, which the README says is unfortunately not very clear about how a derived work like Triangle.NET should be handled. Triangle.NET was published on Codeplex under the MIT licence in 2012, at triangle.codeplex.com, which is no longer available. The author's recommendation is not to use this code in a commercial context.

The restriction is scoped, and the scoping is what makes the project usable at all. It applies only to the Triangle project and specifically to those files containing a copyright header pointing to Jonathan Richard Shewchuk. The code in the other projects, Triangle.Rendering and Triangle.Viewer among them, is released under the MIT licence.

The consequence follows directly. Because of the unclear licensing situation, there will also be no NuGet package release. The README refers readers to the License Confusion discussion in the discussions section for further discussion of exactly this.

So there is no way to install Triangle.NET from a package feed, and the reason is legal rather than technical. You take the source. The commercial question is a real one, and this is a matter for whoever owns the code in your organisation rather than something the README decides, but the author's own stated position is that commercial use is not recommended, and that is a signal worth taking at face value rather than reading past.

The repository's own licence field is recorded as unknown, which is consistent with a project whose licensing varies file by file.

Why the port exists, and where the boundaries are

The value proposition of a port like this is straightforward: the algorithm is proven and the original implementation is C, so a .NET developer either links native code, wraps it in a P/Invoke layer of their own, or uses a managed port that somebody else has already maintained.

The cost is the licence ambiguity just described, and there is a second cost that the README does not dwell on. The repository's activity is modest. The last push was on 2026-06-10, there are no GitHub releases, and the project has been on this branch for a long time. Any bug fix or platform update in Shewchuk's original C code reaches Triangle.NET only if someone ports it, and a .NET port of a numerical library also has to track .NET runtime changes that the original C does not.

There is a limit to what the port covers as well. The README's feature list is a list of Shewchuk's capabilities, and there is no mention of anything beyond them, so this is a mesh generator and not a general geometry kernel. There is no mention of 3D, of meshing volumes, of surface meshing, or of a file format reader for the many other mesh formats in circulation. The `.node`, `.poly` and `.ele` files are the interchange story, and if your pipeline speaks STL or OBJ, the conversion is on you.

The alternative approach, and it is a real one, is to run the original C program. Shewchuk's Triangle is a standalone executable that reads and writes exactly these formats, and a .NET application can invoke it and parse the output, or embed it through a native interop layer. The difference in approach is direct: the port gives you an in-process API and a managed object model, at the price of the licence question and of being behind the original in bug fixes. Calling the original gives you the clearest licensing position and the most current algorithm, at the price of a process boundary and file based interchange. For a .NET codebase where the mesh is generated once and consumed many times, the port is usually the better trade, and the licence is the thing to settle first.

Editorial conclusion

Adopt Triangle.NET if you are working in C# and need Shewchuk quality meshes without linking native code, and you are prepared to vendor the source rather than install a package. Do not adopt it for a commercial product without a licence review, because the author recommends against that and there is no NuGet package to take the decision off you. Before you start, read the `src/Triangle` directory for the files carrying Shewchuk's copyright header, because only those files inherit the restrictive terms, and read the License Confusion discussion linked from the README to see the current state of that debate.

Frequently asked questions

Official sources

1. Issues
2. README
3. wo80/Triangle.NET on GitHub