feat: Dynamic Runtime Rasterized MSDF Sprite Font #3055

yuechen-li-dev · 2026-02-04T10:20:03Z

PR Details

This PR adds an experimental runtime MSDF font path to Stride’s sprite font system.

Introduction

Stride’s current sprite font rasterization options each have trade-offs. Dynamically generating MSDF glyphs on-demand is the common approach in modern engines (e.g., Unity/Unreal): it combines the benefits of Stride’s runtime rasterized fonts (large character sets like CJK) with offline SDF/MSDF advantages (smooth edges at high resolution, easy scaling) with minimal downsides.

Implementation

Dynamic MSDF generation differs substantially from Stride’s existing static SDF pipeline.

Uses SharpFont (already a Stride dependency) to extract glyph outlines on-demand when glyphs are requested at runtime.
Generates MSDF textures asynchronously via a bounded Channel + worker pool, then uploads into the font atlas.
The MSDF rasterizer is intentionally modular / swappable to keep the pipeline future-proof.

Rasterizer backends

Two managed, cross-platform MSDFGen ports are included (no P/Invoke):

Remora.MSDFGen: lighter/older, fewer features
MSDFGen-Sharp / msdfgen.core: newer, more features, slightly better results on some fonts

Also included:

Two debug rasterizers:
- a simple pattern output backend
- an outline diagnostic backend

Notes / limitations

"Default Size" parameter is used for baking, keep it relatively large (64+) for best results.
Some fonts (especially those with overlapping / self-intersecting contours) can produce repeatable MSDF artifacts (notably in punctuation/CJK). Current workaround: preprocess fonts in FontForge (Remove Overlap / Simplify / Correct Direction). This keeps runtime lightweight and avoids bundling heavy geometry cleanup.
Game Studio “Play” vs running from Visual Studio can differ in dependency deployment. Ensure the MSDF backend assemblies are present in the runtime output; if needed, run the game via VS at least once so dependencies get copied/resolved. Otherwise, fonts may render in the editor but not in-game.
Thumbnail preview for runtime MSDF fonts is currently blank; I wasn’t able to find a clean fix yet.

Testing

Verified glyph generation + atlas upload in the editor.
Verified runtime behavior when launched from Visual Studio.
Used debug backends to validate atlas upload/sampling independently of MSDF generation.

Core files:

RuntimeSignedDistanceFieldSpriteFont.cs
SharpFontOutlineExtractor.cs
MsdfGenCoreRasterizer.cs (MSDFGen-Sharp backend)
RemoraMsdfRasterizer.cs
Pipeline glue (MsdfGenerationPipeline.cs, etc.)

Thanks. This took a lot longer than I thought it would.

Comparison

Existing Runtime Rasterized Font:

New Runtime MSDF Font:

Related Issue

#2584

Types of changes

Docs change / refactoring / dependency upgrade
Bug fix (non-breaking change which fixes an issue)
New feature (non-breaking change which adds functionality)
Breaking change (fix or feature that would cause existing functionality to change)

Checklist

My change requires a change to the documentation.
I have added tests to cover my changes.
All new and existing tests passed.
I have built and run the editor to try this change out.

This reverts commit 0dc668c.

…-in-runtimesigneddistancefieldspritefon Remove runtime SDF bake size plumbing and use SpriteFont.Size for glyph generation.

…ary integration.

…stride into Runtime-SDF-Font

…ey cache into ConcurretDictionaries to future-proof multithreaded calls in the future.

yuechen-li-dev · 2026-02-04T10:22:22Z

@dotnet-policy-service agree

Eideren · 2026-02-04T18:49:54Z

We already have an offline SDF option - but I understand that the reason you implemented this feature is because non-latin character sets tend to be very large and require a high resolution. Offline SDF we currently have wouldn't work because it would have to cover multiple thousands of characters with a fairly high resolution, potentially blowing out build sizes.

Definitely cool to see, now, is there a particular reason why this PR specifically sidesteps using most of the logic already setup for offline SDF ?

Also, as it stands, the limitations seems a bit like a show stopper. Our engine already has enough quirk as it is, best to fix those before we merge this in

yuechen-li-dev · 2026-02-04T23:58:50Z

Thanks for the thoughtful review - I agree with the motivation you outlined (CJK + large character sets + resolution/build-size constraints is the core reason for doing this at runtime).

Why this approach doesn’t reuse most of the offline SDF pipeline

Stride’s current offline SDF path is essentially a font compiler wrapper around an external tool (msdfgen.exe) to generate bitmap plus some atlas bookkeeping called through DirectWrite. In other words, the “real” work (outline extraction, contour cleanup/orientation, MSDF generation, shape normalization) happens inside the external binary, not inside Stride’s runtime code, as we can see in SignedDistanceFieldFontImporter.cs here.

For runtime MSDF, we need a very different shape of solution:

no external exe (shipping an msdfgen tool / invoking processes at runtime isn’t viable, especially cross-platform)
async generation + caching, because glyph generation is heavy and needs to happen incrementally under gameplay timing constraints
incremental atlas updates while the game is running

So there isn’t much logic to reuse without effectively rewriting the offline pipeline into a reusable in-process library anyway, which is what this PR does, but oriented around runtime constraints.

This approach lets us keep the pipeline cross-platform and embeddable (no msdfgen.exe / no DirectWrite-only path), and it would cleanly resolve #3021 (because no platform specific font compilation is required, as atlas generation happens at runtime using managed portable C# libraries, rather than an external Windows-specific toolchain).

Finally, because of the modular architecture, this approach unlocks future extensions, such as MTSDF alpha map based effects (outlines, glow, rich text effects) which can be done by evolving just the rasterizer/shader instead of reworking the full asset pipeline again.

To address notes and limitations I listed:

This implementation is fully functional. The only real issue is where the font thumbnail for Runtime SDF fonts in the Game Editor do not render correctly. Attempts to isolate a fix for this specific UI element currently impact standard font thumbnails; given it is purely cosmetic, it has been left as-is to preserve the integrity of the runtime rendering.
For optimal quality and performance, it is recommended to set a relatively large default size in the asset properties. This defines the "bake" resolution; however, the font remains fully resizable within TextBlocks without loss of clarity.
Like the existing offline MSDF implementation, certain fonts with overlapping or self-intersecting contours may display artifacts. This is a characteristic of the MSDF algorithm needing a clearly defined "inside" and "outside" and not an issue with this implementation. If artifacts appear, preprocessing the font file to simplify contours once before import is an easy solution. Integrating a SkiaSharp based preprocessing step was considered but omitted to avoid unnecessary project complexity for a niche edge case.

This is from release version of stride to demonstrate these artifacts on offline SDF fonts:
Font used: https://fonts.google.com/noto/specimen/Noto+Sans+SC, the static semi-bold version from the zip file.

Fixed after preprocessing:

Eideren · 2026-02-05T10:16:28Z

Thank you for the clarification, the source for msdfgen isn't part of this repository, but we do maintain our own version through https://github.com/stride3d/msdfgen - which could have been used as the base for a c# port or integration, but doesn't matter too much now, even more so with the fixes you've introduced.

I'll try to find the time to take a look at it this week end, thanks for the work.

Eideren

Looks really good, I was able to repro the missing characters when building a game, haven't had time to look into it yet, but we can't quite merge before this is fixed.
Still, I have a fair amount of things to run by you.

Eideren · 2026-02-07T11:27:04Z

sources/engine/Stride.Assets/SpriteFont/SpriteFontAssetCompiler.cs

+                    Parameters.FontSource.Style,
+                    runtimeSdfType.PixelRange,
+                    runtimeSdfType.Padding,
+                    useKerning: false,


Is there a reason why kerning is always off, on this call site and all other usage I could find

The initial basis of this project is an exact copy of the runtime rasterized font that was already in the system.

https://github.com/stride3d/stride/blob/master/sources/engine/Stride.Assets/SpriteFont/SpriteFontAssetCompiler.cs

And kerning was set as off for it, so I just copied.

Eideren · 2026-02-07T11:30:34Z

sources/engine/Stride.Assets/SpriteFont/SpriteFontAssetCompiler.cs

+                // M1 NOTE:
+                // This is a scaffolding step. We serialize a functional font so the pipeline works end-to-end.
+                // In M3/M4, this will be replaced by a real Runtime MSDF font object.
+                commandContext.Logger.Warning("Runtime SDF font is currently scaffolded in M1 (temporary). It will behave like a runtime raster font until the MSDF runtime generator is implemented.");


This seems either unrelated or too loosely documented, what do you mean by M1 and co. ?

These are personal milestones for me to keep track of project development. Since MVP Is complete, this can and will be removed.

I just had the warning to label it as an experimental feature.

Eideren · 2026-02-07T11:35:54Z

sources/engine/Stride.Graphics/Font/RuntimeMSDF/DummyTestRasterizer.cs

+    /// Dummy MSDF rasterizer that generates simple test patterns.
+    /// Use this to isolate pipeline issues from MSDF generation issues.
+    /// </summary>
+    public sealed class DummyTestRasterizer : IGlyphMsdfRasterizer


Could you set it up as a test in Stride.Graphics.Tests ?

These two debug rasterizers are for visual debug feedbacks. I can set up some unit test to test outline extraction/MSDF generation functionality without having to manually switch out rasterizers.

Eideren · 2026-02-07T12:03:57Z

sources/engine/Stride.Graphics/Font/RuntimeMSDF/MsdfGenCoreRasterizer.cs

+            {
+                if (contour.Edges.Count == 0) continue;
+
+                EdgeColor[] colors = { EdgeColor.CYAN, EdgeColor.MAGENTA, EdgeColor.YELLOW };


This could be a static array, or a stack allocated one

Eideren · 2026-02-07T12:04:51Z

sources/engine/Stride.Graphics/Font/RuntimeMSDF/MsdfGenCoreRasterizer.cs

+                    foreach (var c in colors)
+                    {
+                        if (c != prevColor && c != nextColor)
+                        {
+                            chosen = c;
+                            break;
+                        }
+                    }


You only need to test the two other colors afaict ?

sources/engine/Stride.Graphics/Font/RuntimeSignedDistanceFieldSpriteFont.cs

Eideren · 2026-02-07T18:44:43Z

sources/engine/Stride.Graphics/Font/RuntimeSignedDistanceFieldSpriteFont.cs

+            // Prefer outline-based MSDF generation when available.
+            // We still rely on the bitmap path to populate glyph metrics today, but MSDF uses the outline.
+            if (FontManager != null &&
+                FontManager.TryGetGlyphOutline(FontName, Style, Size, key.C, out var outline, out _))


Shouldn't we warn users somewhere that the font they chose does not provide glyph outline, maybe as part of the build steps for a Runtime SDF asset ?

That was something I was unsure about when coding this, but it really looks like all fonts would always have a glyph outline and the extraction process is fairly direct. I will set up some unit tests for this, but ideally, I would like to see if it is possible to include an open source .ttf font file （I would suggest Noto Sans CJK Regular for coverage） so the unit tests aren't reliant on checking what font does the tester have installed on their computer.

Sounds good, we have a test setup for japanese over here
https://github.com/stride3d/stride/blob/master/sources/engine/Stride.Graphics.Tests/TestDynamicSpriteFontJapanese.cs
Which uses a font bundled with the repo:
https://github.com/stride3d/stride/blob/master/sources/data/tests/Fonts/SourceHanSans-Light.otf
Feel free to look at how that one is setup to build yours, as long as the font is compatible with MIT it'll be fine.

yuechen-li-dev · 2026-02-07T20:27:23Z

Looks really good, I was able to repro the missing characters when building a game, haven't had time to look into it yet, but we can't quite merge before this is fixed.

Yeah, my findings on this issue are that the atlas generation/upload for runtime SDF is async, and the existing font thumbnail compiler is not async aware and since it is only called once to generate the thumbnail, and since the fonts aren't ready when it is called, it returns nothing. I'm not sure what the clean way to resolve it would be, and I've experimented a lot on this.

I might be a little busy this weekend, so I'll address these gradually over the next week. Thanks for the thorough review.

…ral cleanup of FontManager.

…mplified some expression for readability with pattern matching.

…nd bug around fallback logic on full channel queue.

…bility.

…le for efficiency.

yuechen-li-dev and others added 26 commits January 28, 2026 20:09

M1: Added Runtime SDF placeholder.

d49b9ff

M2. MSDF Cache Scaffold.

3275c16

M3: Font works end to end, renders ugly circles.

5d9185f

M4 WIP: Buggy implementation with flickers so far.

75f5369

It works, but each text spins computer like jet engine.

1fa1cd4

Async implementation and various optimizations.

2f0b165

Fixed bad copypaste for SpriteFontAssetCompiler.cs

dd4f8e0

Less sloppy Async.

0dc668c

Revert "Less sloppy Async."

69e2f15

This reverts commit 0dc668c.

Remove runtime SDF bake size plumbing

7ad4caa

Merge pull request #4 from yuechen-li-dev/codex/refactor-glyph-sizing…

b04c959

…-in-runtimesigneddistancefieldspritefon Remove runtime SDF bake size plumbing and use SpriteFont.Size for glyph generation.

Adjusted default bakesize to 64 so SDF is high quality.

d5d9576

Merge branch 'stride3d:master' into Runtime-SDF-Font

18e227d

Changed to channel based async design.

217a8fd

Channel based refactor for async, introduce interface for easier libr…

e2e9f09

…ary integration.

See above message. Wrong commit lol.

ae2e234

Merge branch 'Runtime-SDF-Font' of https://github.com/yuechen-li-dev/…

a0058c4

…stride into Runtime-SDF-Font

refactor for future MSDFGeneration.

914819d

Initial wiring. Need to fix generationPipeline.

048b521

Ok, it renders but only as blocks or dots. Debug time.

d7d8d5b

It works! Mostly. Need to squash some font specific bugs.

dbba408

Next try with MsdfGen too.

a22eb17

Comment edits.

e455a49

clean up gitignore of temp file.

cc65561

Move offset logic out of ApplyUploadedGlyph for safety. Change glyphk…

4d9159c

…ey cache into ConcurretDictionaries to future-proof multithreaded calls in the future.

Minor changes so VS would have less messages.

dd6b53a

Eideren added the area-UI label Feb 4, 2026

Eideren changed the title ~~Add Dynamic Runtime Rasterized MSDF Sprite Font~~ feat: Dynamic Runtime Rasterized MSDF Sprite Font Feb 4, 2026

Eideren requested changes Feb 7, 2026

View reviewed changes

yuechen-li-dev added 13 commits February 9, 2026 11:34

Cleaned up nullable in FontSystem.

738280e

removed unsafe keyword and unneed cast for buffer copy.

92e5460

Spacing consistancy in pregenerated glyph method.

739c69e

Changed the font manager to private.

0bea15f

Remove extra colon.

6a98305

Remerged MSDF method into FontManager. Remerged unused overload. Gene…

a457fd6

…ral cleanup of FontManager.

Changed warning from scaffolding to indicate experimental feature. Si…

3463072

…mplified some expression for readability with pattern matching.

Moved comment to more accurately depict pipeline for upload step.

113d16d

Small refactor for EnsureSdfScheduled to address 0 dimension glyphs a…

f2930a2

…nd bug around fallback logic on full channel queue.

Removed debug message from FontCacheManagerMSDF and cleanup for reada…

3176a76

…bility.

Move oversized glyph dimension check from FontCacheManager to Font fi…

dcfae4b

…le for efficiency.

Re-added accidentally deleted packer logic.

f8aadd1

remove unused bool isClosed definition from outline extractor.

0753019

Uh oh!

feat: Dynamic Runtime Rasterized MSDF Sprite Font #3055

Are you sure you want to change the base?

feat: Dynamic Runtime Rasterized MSDF Sprite Font #3055

Uh oh!

Conversation

yuechen-li-dev commented Feb 4, 2026

PR Details

Introduction

Implementation

Rasterizer backends

Notes / limitations

Testing

Core files:

Comparison

Related Issue

Types of changes

Checklist

Uh oh!

yuechen-li-dev commented Feb 4, 2026

Uh oh!

Eideren commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yuechen-li-dev commented Feb 4, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Why this approach doesn’t reuse most of the offline SDF pipeline

Uh oh!

Eideren commented Feb 5, 2026

Uh oh!

Eideren left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yuechen-li-dev commented Feb 7, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

Eideren commented Feb 4, 2026 •

edited

Loading

yuechen-li-dev commented Feb 4, 2026 •

edited

Loading