helix-toolkit: a 3D scene graph for .NET that spans two rendering engines

What Helix Toolkit actually is

Helix Toolkit describes itself in one line as a collection of 3D components for .NET, and that framing matters more than it first appears. It is not a game engine with a scene format, a level editor or a physics solver. It is a set of libraries that give a C# developer a camera, a viewport, lights, materials, meshes, geometry builders and a scene graph, plus the model import path needed to get third party 3D files onto the screen. The MIT licensed repository on GitHub carries about 2,283 stars and 707 forks, which puts it in the same weight class as other long lived open source graphics work rather than in the experimental category. The language is C#, the graphics work targets DirectX 11 through SharpDX, and the default branch is `develop3`. The last recorded push on the repository is dated 2026-09-01, so the project is active rather than archived. If your application needs a 3D viewport embedded in a desktop UI, this is the library that already solved most of the plumbing for Windows and WPF.

The package layout, from maths up to scene graphs

The README documents the projects as a layered set rather than a single assembly, and the layering is the easiest way to understand what each package does. `HelixToolkit` holds the core components shared across the other projects. Under it sits `HelixToolkit.Maths`, described as a modified maths library carried over from the SharpDX project so that it lines up with `System.Numerics`. On top of that is `HelixToolkit.Geometry`, the geometry builder library that produces the common shapes. From there the tree forks in two directions, which is the part that most surprises newcomers. One branch is the DirectX 11 engine: `HelixToolkit.SharpDX` is the custom 3D engine and scene graph built on SharpDX, and it then feeds `HelixToolkit.SharpDX.Assimp` for 3D model import and export through SharpAssimp, plus `HelixToolkit.Wpf.SharpDX`, `HelixToolkit.WinUI.SharpDX` and `HelixToolkit.Avalonia.SharpDX` for XAML and MVVM scene graphs on each of those UI stacks. The other branch is the WPF 3D engine: `HelixToolkit.Wpf` adds functionality and models on top of the internal WPF 3D models in the Media3D namespace, and `HelixToolkit.Wpf.TDxInput` sits beside it. Geometry feeds both branches, maths feeds geometry, and that is why the same mesh definitions can be moved between the two engines without rewriting them.

Building the documentation on Windows, Linux and macOS

The project uses DocFX to generate API documentation from the C# XML comments, and the generated pages are deployed to GitHub Pages on every push to the main branch. Contributors who want to read those pages before they are published build them locally, and the README gives a one line script entry point per platform. On Windows the call goes through a `.cmd` wrapper:

cd Source
build-doc.cmd

On Linux and macOS the same two steps use a shell script:

cd Source
./build-doc.sh

Both scripts sit in the `Source` directory, which is why the `cd` is part of each one rather than an optional prefix. More detail on writing and building the documentation lives in the README under `Source/Documentation/README.md`, and the visual studio requirement for the project build is stated plainly as Visual Studio 2022. Expect the local build to take a while on a first run, since DocFX has to parse every project in the solution before it can emit pages.

Right handed coordinates, row major matrices and the left handed trap

The first numbered note in the README is the one that costs newcomers the most debugging time. Helix Toolkit uses a right handed Cartesian coordinate system by default, and this extends to the mesh builders as well as the camera and viewport. Matrices are row major by default. Both defaults differ from what several other 3D APIs assume, so porting code from elsewhere tends to produce geometry that renders inside out. If you want the left handed system, the camera exposes `Camera.CreateLeftHandedSystem`, and setting it to `true` is only half the change. With SharpDX you then have to correct the triangle winding order manually, or set `IsFrontCounterClockwise` in the raster state description. The toolkit does not fix this for you, and a scene that looks like it is missing its front faces is usually this mismatch rather than a bug in the renderer. The same note is the reason meshes built once can be reused across the WPF Media3D branch and the SharpDX branch: the coordinate convention is a property of the library, not of the individual model.

What a FeatureLevel 10 card will not do

The third numbered note lists the features that a FeatureLevel 10 graphics card does not currently support: FXAA, order independent transparent rendering, the particle system, and tessellation. Each of those is a feature people tend to reach for while they are still exploring what a scene can look like, so the list is worth reading before you design around it. FXAA is an edge smoothing pass, order independent transparency is what lets you render transparent geometry without sorting artefacts, the particle system covers effects, and tessellation is the higher level geometry path. If your target hardware sits at that feature level, you have to plan for post processing done another way, manual transparency sorting, hand built effects, and no hardware level tessellation. The second numbered note points at a separate performance wiki page covering WPF.SharpDX and UWP, which is where the tuning guidance lives rather than in the README. Together, these two notes are the practical limit of what the library offers on constrained hardware.

Where the project is heading, and which version to start on

The release history and the news section give a clear picture of direction. Version 3.1.2 shipped on NuGet in late November 2025, and its changelog is mostly quality work: automated documentation generation with DocFX and GitHub Pages deployment, an Avalonia typo fix, and a fix for multisample anti aliasing in order independent transparency. Version 3.0.0, released earlier that month, is a longer list of bug fixes and improvements, including a null reference fix in `CuttingPlaneGroup.CuttingPlanes` for WPF, a fix for rendering that did not update after removing an item from `Viewport3DX.Items`, a reimplementation of zoom to extents for the SharpDX versions, and fixes for rectangle selection and stale collection change notifications. Underneath that sits a line the README does not bury: HelixToolkit version 2 is in maintenance mode, meaning new releases there will only cover critical bugs, and the focus moves to version 3. The project also points at a separate next generation repository built on Vulkan with a modern 3D engine architecture, and says feature requests for that line are collected in its discussions. Nightly packages are published to a MyGet feed under `helixtoolkit-nightly`, stable packages come from NuGet, and questions have historically been taken to Gitter and Stack Overflow. A wiki covers topics the README cannot, including performance tuning and a page of external computer graphics references.

Editorial conclusion

Helix Toolkit is a working .NET 3D library with a package layout that reflects real decisions rather than a marketing page. The Maths and Geometry layers sit at the bottom, the SharpDX engine sits in the middle, and the WPF, WinUI and Avalonia scene graphs sit on top, with a separate WPF branch that keeps the older Media3D models alive. The two engine lines are worth keeping straight when you plan a project, because the feature notes and the performance topics differ between them. There is also a maintenance signal in the repository worth reading before you commit: version 2 is described as being in maintenance mode while development moves to version 3 and to a separate Vulkan based repository. If you are starting fresh, the v3 packages are the ones to look at first.

Frequently asked questions

Official sources

1. helix-toolkit/helix-toolkit on GitHub
2. License: MIT
3. Project website
4. README
5. Releases