
It’s 2015 and drawing text is still hard - parris
https://engineering.eventbrite.com/its-2015-and-drawing-text-is-still-hard-webgl-threejs/
======
mattdesl
I have been working a lot with WebGL text in the past several months. Our
current solution uses SDF with standard derivatives (crisp anti-aliasing
regardless of zoom level) and supports kerning (depending on the font),
batched glyphs, and word wrapping. It's not perfect, but it's pretty good for
common use cases.

Since the OP is using modules already, they might enjoy some of the libraries
and tools here:

[https://www.npmjs.com/package/text-
modules](https://www.npmjs.com/package/text-modules)

Or a ThreeJS specific implementation of bitmap / SDF:

[https://github.com/Jam3/three-bmfont-text](https://github.com/Jam3/three-
bmfont-text)

And lots more reading on the subject:

[http://mattdesl.svbtle.com/material-design-on-the-
gpu](http://mattdesl.svbtle.com/material-design-on-the-gpu)

Some practical implementations of it:

\- npm dataviz: [http://mattdesl.github.io/npm-
names/](http://mattdesl.github.io/npm-names/) (over 40k glyphs, could go
higher)

\- physical text: [http://mattdesl.github.io/physical-
text/index.html](http://mattdesl.github.io/physical-text/index.html)

~~~
parris
Whoa that's really cool!

------
AndyKelley
Drawing text _is_ hard, and not something that should be solved at the OpenGL
level. It involves coordinating with the window manager and user settings.

But I'm just responding to the gimmicky title. It looks like the article has
some interesting technical content to it.

~~~
mrec
> Drawing text is hard, and not something that should be solved at the OpenGL
> level.

Agree completely with the first part, less sure about the second. Almost
everything needs to do it. Text rendering _was_ included in OpenVG, which
seems to have flopped completely. And rendering _anything_ to the screen with
OpenGL will involve coordinating with the window manager.

Mark Kilgard's gigantic NV_path_rendering extension included a LOT of
font/glyph support. It surprised me as well when I first read it, but there's
some interesting discussion of the rationale in the second item of the Issues
list at the end of the spec [1].

[1]
[https://www.opengl.org/registry/specs/NV/path_rendering.txt](https://www.opengl.org/registry/specs/NV/path_rendering.txt)

------
tehansen
Google "loop blinn". There are a few papers by those guys on the topic of
rendering smooth anti aliased cubic bezier paths, which is really what you
want.

You can read font data directly from ttf e.g. And render text nicely with few
polygons and shaders taking care of very nice accurate edge rendering.

I wrote a half finished c implementation a couple of years ago that might be
useful as a reference if you want to look into this more :
[https://github.com/hansent/lbfont](https://github.com/hansent/lbfont)

It's mainly based on the paper/article inter book GPU gems 3.

Accelerated 2D Vector graphics are hard, when I was working on this nvidia was
announcing the nv_path_rendering extension; don't know how widely this is
supported these days. But I doubt it's available in webgl.

Edit: few typos...writing on mobile

------
mrdoob2
Feel free to do a PR with your solution, just so no one has to write a "It's
2016 and drawing text is still hard" blog post next year ;)

~~~
parris
Ha! I might split out the code into its own repo so it can be used as an add-
on library for ThreeJS. I think the code here might push it over the 100kb
limit. We'd also need to get a license to SDF'ify a default font (possibly
Helvetiker). We had to get permission to do it with our font "Benton Sans".

------
hyperion2010
I have been building a tool for interactive data visualization using panda3d.
Running absurd amounts hideously complex static geometry? No problem. Want to
render short labels on a couple thousand objects? Draw calls aside, renderer
slows to a crawl because it also uses the text geometry approach. Does anyone
know if there are other approaches that work aside from the the SDF described
in the article?

~~~
mattdesl
If you are OK with (a) processing font atlases offline and (b) simple
languages (no complex text layout) then SDF fonts is a really great solution.
It's fast, memory efficient, easy to anti-alias, and real-time effects
(shadows, edge fuzz, etc) are easy to add.

------
sdafsdfafasdfsd
This site looks terrible in chrome.

[https://i.imgur.com/39warVl.png](https://i.imgur.com/39warVl.png)

~~~
flohofwoe
Did a quick check and it looks fine in Chrome v44 on OSX 10.11, Windows10 and
Android.

More on-topic: text rendering _is_ a hard problem, kerning and UNICODE support
is only the beginning of the rabbit hole. Once you need to render Arabic, you
also need bi-directional text rendering (normal text is RTL, number and latin-
characters-strings are LTR), and you also need context-sensitive glyph-shaping
(the same character is rendered differently depending on whether it stands
alone, at the beginning, end or middle of a word).

------
andrewmcwatters
Who or what says it should easy?

