SharpGLTF: a .NET Standard glTF 2.0 reader, writer and toolkit

Three packages for three different jobs

SharpGLTF is described as a 100% .NET Standard library designed to support the Khronos Group glTF 2.0 file format. The word standard is the important part for adoption: it means the library can be consumed from .NET Framework, .NET Core and .NET 5 and later without a rewrite, which matters for studios and tools where the runtime version is decided elsewhere.

The library is divided into three main packages, and the division is the first thing to understand.

SharpGLTF.Core is the one with read and write file support, and low level access to the glTF models. SharpGLTF.Runtime provides helper classes to simplify glTF model rendering. SharpGLTF.Toolkit offers convenience utilities to help create, manipulate and evaluate glTF models.

That is a sensible split, and it also tells you how to depend on the library. If you only need to read a file and hand the data to your own engine, Core is enough and the dependency stays small. If you want the rendering helpers, you take Runtime. If you are authoring assets in code, you take Toolkit, and you should think about whether you want that in your production build or only in your tools, because Toolkit is a tool-shaped dependency.

Two optional extension libraries sit alongside them, SharpGLTF.Ext.Agi and SharpGLTF.Ext.3DTiles, the latter for the 3D Tiles format. Optional means optional, which is the point: a core library that does not force a 3D Tiles implementation on everybody is easier to take.

Loading a glTF and writing a GLB is two lines

The quickstart in the readme is the whole demonstration of the core use case:

var model = SharpGLTF.Schema2.ModelRoot.Load("model.gltf");
model.SaveGLB("model.glb");

Load a glTF file, save it as a GLB. The namespace is worth pausing on, because `Schema2` is the glTF 2.0 schema, and naming the namespace after the schema version is a design decision with consequences: it leaves room for a different schema generation to live alongside without breaking the type names, and it tells you that this library's model types are versioned by schema rather than by convenience.

The second thing the snippet shows is the format distinction. glTF is the JSON form, and GLB is the binary container that holds the same data with the buffers inside it. A library that can read one and write the other is more useful than one that only does one, because most pipelines end up wanting the binary form for delivery and the JSON form for inspection and merging, and the conversion in between is not always trivial when buffers have to be re-packed.

More examples are in the examples directory and in the test project, and the readme also points at two Khronos reference implementations for comparison, the glTF-CSharp-Loader and UnityGLTF, which are useful if you want to see what an official sample loader looks like next to this one.

The examples folder is the real documentation

The repository layout says a lot about how the project is meant to be used, because the examples are not a token sample each.

There is `Example1` with a matching `Example1.glb`, which is the baseline round trip. There is `InfiniteSkinnedTentacle`, with a `.glb` beside it, which is a skinned mesh example, so the animation and skinning side of the format is exercised with real content rather than a placeholder. There is `PointCloudGalaxy`, again with a `.glb`, which is a point cloud sample, so a geometry type that is not a triangle mesh is covered too.

Then there are the engine integrations. `MonoGameIntegrationDemo`, `MonoGameScene` and `SharpGLTF.Runtime.MonoGame` show the library driving MonoGame, and `SharpGLTF.Plotly` shows it used with Plotly, which is an unusual pairing and suggests the Toolkit package is useful well beyond game engines.

Each example directory has its own `Directory.Build.props`, which is the standard .NET way of giving a subdirectory its own build settings, and there is an `examples/README.MD` alongside them.

The practical value of this collection is that it is a set of working answers to questions you would otherwise have to ask. Which engine do I target, how do I get a skinned mesh into a scene, how do I represent a point cloud, and how do I wire the Runtime helpers into a renderer are all answered by code you can read rather than by documentation you have to interpret.

Modern .NET build plumbing

The root of the repository has the build files of a .NET project that is being kept current, and they are worth a look because they tell you what the toolchain expects.

There is `SharpGLTF.slnx`, which is the new XML solution format rather than the old `.sln`, so the project has moved to the current solution model. `Directory.Packages.props` enables central package management, where every NuGet dependency version is declared in one file and the individual projects reference them without versions. `NuGet.Config` sits beside it for package source configuration, and `SharpGLTF.Build.sh` is the build script.

Code style is handled with `SharpGLTF.ruleset` and `stylecop.json`, which is the standard pairing of an analyzer rule set with StyleCop configuration, and there is an `.editorconfig` for the formatting conventions. The `build` directory holds the icon and related assets, and the `tests` directory holds the test project that the readme points to for more examples.

None of this is glamorous, and all of it matters, because a glTF library is a dependency that other people's builds depend on. A library that pins its dependencies centrally and builds with a current SDK is far less likely to cause a resolution conflict in someone else's solution than one that hard codes versions across a dozen project files.

What the README does not tell you

This is a short readme, and its silences are informative. There is no statement of which .NET versions are supported in practice, even though the project is described as 100% .NET Standard. There is no performance claim, no benchmark, and no statement about the size or speed of parsing a large scene, so anyone evaluating it for a pipeline with big assets has no basis for a judgement beyond reading the code.

There is also no mention of glTF 1.0. The type names live under a `Schema2` namespace, which is consistent with a library that targets the second generation of the format, and the readme refers only to glTF 2.0. If you have legacy glTF 1.0 assets, the documentation here does not tell you whether they are handled, converted or rejected.

Similarly, the readme does not describe the Toolkit utilities in any detail, and the Toolkit is the package that promises the most, since it is the one that creates, manipulates and evaluates models. Its own README in `src/SharpGLTF.Toolkit` is where that documentation lives, and the same is true of Core and Runtime. The pattern is consistent, and it is a reasonable one, but it means the repository root readme is an index rather than a manual.

For a library aimed at engineers, that is a normal trade, and the NuGet packages, the examples and the per-package readmes together cover it. The tool to use for a specific question is the examples folder, not the readme.

Licence, releases and where the project lives

SharpGLTF is MIT licensed, with the licence file at the root of the repository. For a library intended to be embedded in tools, editors and games, a permissive licence with no obligations beyond attribution is the practical choice, and it is what makes the library easy to adopt in a commercial product without a legal review of copyleft obligations.

The release history is steady. Version 1.0.5 was tagged on 2025-07-19, 1.0.6 on 2025-12-30 and 1.0.7 on 2026-09-12, and the last push was on 2026-09-12 as well, the same day as the tag. The default branch is `master`, the repository is not archived, and the version has been at 1.0.x for a while, which for a library means the public surface is meant to be stable.

Packages are published to NuGet, and the readme badges point at the prerelease feeds for SharpGLTF.Core, which means the maintainer ships prerelease builds to NuGet as well as tagged releases. There is a Discord server for questions.

Taken together, the picture is of a focused, well maintained library that stays close to the format rather than trying to be a rendering engine, with the engine integrations handled by the Runtime package and demonstrated in the examples.

Editorial conclusion

SharpGLTF suits a .NET team that needs to load, transform or author glTF 2.0 assets in C#, especially one that wants to avoid the heavier engine SDKs and work with the file format directly. It is a poor fit if you need a rendering engine, since the Runtime package only offers helper classes and the actual renderer is yours to supply, and it is a poor fit if you depend on glTF 1.0, which the documentation does not mention. Before you adopt it, read the README of each of the three packages, because the division between Core, Runtime and Toolkit is what determines which dependency you actually take, and check the examples folder to see which engine integration you would be modelling yours on.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vpenades/SharpGLTF on GitHub