Slughorn, MIT-licensed GPU-agnostic Slug font/glyph rendering library for OpenGL/OSG/Vulkan and all GPU-driven graphics APIs - AlphaPixel Software Development

Skip to content

Slughorn, MIT-licensed GPU-agnostic Slug font/glyph rendering library for OpenGL/OSG/Vulkan and all GPU-driven graphics APIs

By Chris HansonPosted on June 29, 2026

Slughorn: Applying Slug-Style GPU Curve Rendering Beyond Text

On March 17th 2026, Eric Lengyel made his Slug technique completely patent-unencumbered ( https://terathon.com/blog/decade-slug.html ) .

As long-time graphics programmers and open source contributors, especially around OpenSceneGraph, VulkanSceneGraph, and related visualization work, we were not going to let that sit untouched for long. On March 19th we started with a few proof-of-concept demos and began digging into the Slug algorithm in detail. Our goal was to take the core idea behind Slug’s high-quality GPU glyph rendering and see how far we could push it outside its original text-rendering use case. Over the last two and a half months, what started as a side research experiment has turned into something we are now ready to put in front of other developers. Hold onto your hats.

We are calling the project Slughorn. The name is a little literal. The goal is to provide a single open-source library for shoe-horning Slug-style data into other visualization contexts: OpenGL, Vulkan, DirectX, scene graphs, HUD systems, 3D UI tools, and whatever else people are already using.

The project

Slughorn is MIT-licensed open source. It can be used commercially without royalties or up-front license fees.

It is written in C++20, builds with CMake, and has no required third-party dependencies. We have tested it on Windows and Linux. It should also be practical on macOS and on embedded or mobile platforms that expose modern GPU APIs, though those targets still need more real-world testing.

The GitHub repository is here:

https://github.com/AlphaPixel/SlugHorn/

The project site is here:

https://slughorn.io/

The site links to the GitHub repository, the user guide, and Python and C++ examples.

There is also a work-in-progress WhatsNext document that lists the directions we are considering next:

https://slughorn.io/WhatsNext.pdf

Current import backends

Slughorn currently supports several input sources:

FreeType

NanoSVG, including paths and gradients

Skia paths

Cairo paths

Blend2D paths

Some of these are more complete than others. That is expected at this stage.

The FreeType backend is the most mature. It can process COLRv0 and COLRv1 emoji content, and it is the backend we have leaned on most heavily while proving out the core data model.

NanoSVG support is already useful for importing SVG paths, transforms, and gradients. Strokes and text are possible, but we have not spent the time there yet.

The Blend2D, Cairo, and Skia paths are currently more rudimentary. They are useful for converting path data into Slughorn content, but they do not yet expose every feature those libraries can express. We expect those backends to grow after the core Slughorn pieces settle down.

Optional dependencies

Slughorn does not require third-party dependencies for the core build, but some features use optional components:

NanoSVG, as a submodule

MSDF support, as a submodule

pybind11, as a submodule

serialization and glTF support, as submodules

Cairo, Blend2D, and Skia import support, when available externally

Cairo, Blend2D, and Skia are not submoduled. That is intentional for now. Those libraries are large enough, and system-specific enough, that we do not want to pretend there is one clean dependency situation for every build environment yet.

Slughorn is not actually a production renderer by itself

Slughorn is not a rendering library. It does not try to own your renderer, scene graph, swap chain, camera system, material system, or UI toolkit. Its job is to act as an input and adaptation layer. It gives other systems Slug-compatible or Slug-adjacent data that they can render inside their own GPU pipelines.

This is deliberate and intentional. We are not trying to replace OpenSceneGraph, VulkanSceneGraph, bgfx, Unreal, Unity, ImGui, Qt, or a custom renderer. We want Slughorn to be something those systems can consume.

For now, the most featureful way to see rendered output is osgSlug:

https://github.com/AlphaPixel/osgSlug

OpenSceneGraph has been our rapid testbed because we know it well. OSG is not a requirement though. Slughorn also includes a pure OpenGL demo showing how the library can be integrated without a full scene graph. You do not need OpenSceneGraph but you do need some kind of renderer to jam all the data and shaders into and execute them.

Why vector graphics?

Slug was designed for text and is already very useful. GPU-rendered glyph curves are a better fit than texture atlases, SDFs, MSDFs, or other approximation techniques in a lot of situations, especially when the camera is not tightly controlled....