There's quite a bit of helper code plus stb_truetype.h and stb_ds.h under the hood to parse TTF files and crunch the TTF curve data into the runtime format expected by the Slug shader (this stuff should better go into an offline asset pipeline tool):
...the list of external dependencies is a bit scary for a small self-contained sample though (Harfbuzz, SheenBidi, libunibreak, etc...), but that basically shows that proper international text rendering is really damn hard, even when trying to simplify the code as much as possible.
I do MSDF as well and since I'm not doing a huge-ass text editor (and even then) it works and it's great. One thing to consider is that with any solution that does things directly from vector outlines means you also then have to distribute proper font outlines and you might not have a license to do that. With MSDF and similar atlas-like solutions, you pre-render a font and distribute that rendered image instead of an actual font.
The project I'm most known for is basically an MSDF shader with a bloom pass. It serves my needs 100%, though if I expand to support arbitrary text, I may reach for Slug.
The one issue with MSDF I want to raise is, it seems everybody uses the same msdfgen texture creation program from Viktor Chlumský's master's thesis 11 years ago. I wish there were other implementations. Who ever heard of a graphics technique that was only ever programmed once, and then used everywhere without substantial iteration? We need to de-XKCD-2347 MSDFs for everyone's sake, including and especially Chlumský.
Man, I am getting incredibly tired of reading LLM-generated writing
Author probably didn't even read...
Here's a simple Slug rendering example on top of sokol_gfx.h:
via WebGPU backend: https://floooh.github.io/sokol-webgpu/slug-sapp.html
via WebGL2 backend: https://floooh.github.io/sokol-html5/slug-sapp.html
There's quite a bit of helper code plus stb_truetype.h and stb_ds.h under the hood to parse TTF files and crunch the TTF curve data into the runtime format expected by the Slug shader (this stuff should better go into an offline asset pipeline tool):
https://github.com/floooh/sokol-samples/blob/master/libs/slu...
...the actual text rendering code is also taking a couple of shortcuts, e.g. no kerning, no right-to-left, and also no text shaping.
There's also a new and complete text rendering stack by Mikko Mononen called Skribidi (AFAIK not based on Slug though):
https://github.com/memononen/Skribidi
...the list of external dependencies is a bit scary for a small self-contained sample though (Harfbuzz, SheenBidi, libunibreak, etc...), but that basically shows that proper international text rendering is really damn hard, even when trying to simplify the code as much as possible.
MSDF corners gave me trouble til I bumped the distance range at small sizes.
MSDF looks better than Slug for me in the first example.
But slug wins in perspective in my eyes.
I use MSDF to render crisp text in my webgl hobby game. Hope to publish it with source code when I get the time.
thanks for sharing the article. I'll take a deeper look at it later.
I do MSDF as well and since I'm not doing a huge-ass text editor (and even then) it works and it's great. One thing to consider is that with any solution that does things directly from vector outlines means you also then have to distribute proper font outlines and you might not have a license to do that. With MSDF and similar atlas-like solutions, you pre-render a font and distribute that rendered image instead of an actual font.
Excellent write up. The cited references are on point too. Eric Lengyel is a legend.
Slug looks impressive!
The project I'm most known for is basically an MSDF shader with a bloom pass. It serves my needs 100%, though if I expand to support arbitrary text, I may reach for Slug.
The one issue with MSDF I want to raise is, it seems everybody uses the same msdfgen texture creation program from Viktor Chlumský's master's thesis 11 years ago. I wish there were other implementations. Who ever heard of a graphics technique that was only ever programmed once, and then used everywhere without substantial iteration? We need to de-XKCD-2347 MSDFs for everyone's sake, including and especially Chlumský.