OpenGL Programming/Modern OpenGL Tutorial Text Rendering 01



= Introduction =

It is very likely that at one point you will want to draw text with OpenGL. It may seem like a very basic functionality of any drawing API, but you will not find any function in OpenGL that deals with text. There are good reasons for that: text is much more complicated than you think. If you are American and use a fixed-width font, then life is simple. You don't have more than 128 possible characters to think about, and they are all the same size. If you have a proportional-width font, things are already getting more difficult. If you are European, then 256 characters might be just enough for one language, but it is already impossible to represent all European languages with that. If you include the rest of the world, then you need more than 65536 (16-bit) characters, and text might need to be rendered from right to left or from top to bottom, and you might have to use other techniques than just drawing characters next to each other on the screen to produce something intelligible. Related to text rendering, you might also want to render mathematical equations, Feynman diagrams, chess board diagrams or sheet music. I hope you are convinced now that text rendering is a very high-level function that has no place in a low-level graphics API such as OpenGL.

That said, we still want to draw text with OpenGL. There are various ways to do this, including:


 * Draw text directly to the framebuffer with glDrawPixels (not available in OpenGL ES 2.0).
 * Draw letter shapes using GL_LINES.
 * Draw filled letter shapes using GL_TRIANGLES.
 * Draw real 3D letters using 3d meshes of letters.
 * Draw each glyph as a textured quad from a texture library of glyphs
 * Draw text with the CPU onto a texture similar to classical 2d text rendering, then project that texture onto a quad in 3d space.
 * Draw each glyph as a textured quad from a vector texture library of glyphs.

In this tutorial, we will start with rendering very simple (US-ASCII) text using one textured quad per letter, or, in font terminology, "glyphs". This technique is quite flexible, and if you are able to cache textures properly it is also one of the fastest ways to render text. With a little care, the visual quality of the text is as good as the text rendered by your browser or word processor.

If this technique is extended using some form of vector textures, such as Alpha Tested Magnification, the results can be crisp after arbitrary transforms.

= The FreeType library =

In order to draw text, we will need some way to read a font, and have it converted into a format that we can use with OpenGL. Many operating systems have a standard way to read fonts, but there are also many libraries that can do this. A very good, well-known, cross-platform library is FreeType. It supports a lot of font formats, including TrueType and OpenType.

With FreeType, you can look up characters, query their dimensions, and find out how to position them more or less correctly; most importantly, it provides you with a grey-scale image of any character. This is exactly the functionality that we need for the text-drawing method that we will use in this tutorial.

While FreeType allows you to access font data, it is not a text layout engine. That means it will not render whole lines of text or paragraphs for you. It also cannot automatically render diacritics, automatically use ligatures or reproduce other complex typographic features. If you need this functionality, you should use a text layout library such as Pango, and draw a whole text at a time instead of a character at a time. This can use more memory and will certainly be slower when dynamically changing text is drawn.

Using FreeType is quite simple. The following two lines should be added to the top of the source code to include the right headers:

Before using any other FreeType function, we need to initialize the library:

= Fonts and Glyphs =

The term font can have different meanings, but generally we think of "Times New Roman" or "Helvetica" as fonts. We also make a distinction between regular, bold, italic, and other styles, so "Helvetica Bold" is a different font than "Helvetica Italic". If you use the FreeType library, you have to specify the full filename of the file containing the font you want to render text with. In FreeType, this is called a "face". For example, to load the regular FreeSans font from the current directory, we use:

After we have loaded the face, we basically have only one parameter we can adjust, and that is the font size. To set it to a height of 48 pixels, we use:

A face is basically a collection of glyphs. A glyph is usually a single character, but it can also be a diacritic or a ligature. A font can also contain more than one glyph for the same character, providing alternative renderings. (See for example the list of features of the excellent Linux Libertine font.) Even Unicode characters do not necessarily have a one-to-one mapping to font glyphs. We will forget about all this complexity though, and focus on the good old ASCII character set. For example, to get the glyph for the character "X" from the font, we use the following code:

The  function will fill all the information of that character into the face's "glyph slot", which can be accessed through. Because we specified, FreeType will also have created an 8-bit greyscale image that can be accessed via. Because it is tedious to write  all the time, and because the pointer   never changes, we will define the following variable as a shortcut:

We will use the following information in this tutorial:


 * g->bitmap.buffer : Pointer to the 8-bit greyscale image of the glyph, rendered at the previously selected font size.
 * g->bitmap.width : Width of the bitmap, in pixels.
 * g->bitmap.rows : Height of the bitmap, in pixels.
 * g->bitmap_left : Horizontal position relative to the cursor, in pixels.
 * g->bitmap_top : Vertical position relative to the baseline, in pixels.
 * g->advance.x : How far to move the cursor horizontally for the next character, in 1/64 pixels.
 * g->advance.y : How far to move the cursor vertically for the next character, in 1/64 pixels, almost always 0.

Why all these values? The reason is that not every glyph has the same size. FreeType renders an image that is just large enough to contain the visible parts of the character. That means a period "." has only a very small bitmap, and the "X" will have a large bitmap. This is why it is important to know the width and height of the bitmap. The comma "," and apostrophe "'" might be rendered as the same bitmap, but the position relative to the baseline is very different. The "X" character starts at the baseline but extends to very high above it, while the "p" character doesn't go that high but dips below the baseline. These things make it necessary to know the offset of the bitmap relative to the cursor and baseline. Furthermore, the visible size of a character does not necessarily tell you how far to move the cursor for the next character. Think for example about the space character!

= Shaders =

For text rendering, we can usually settle for very basic shaders. Since text is basically two-dimensional, we could use an attribute vec2 for vertices, and another attribute vec2 for texture coordinates. But it is also possible to combine the vertex and texture coordinates into a single four-dimensional vector, and have the vertex shader split it in two:

Although this might not be directly obvious, the best way to draw text is to use a texture that contains only alpha values. The RGB color itself is set to the same value for all the pixels. Where the alpha value is 1 (opaque), the font color is drawn. Where it is 0 (transparent), the background color is drawn. Where the alpha value is between 0 and 1, the background color is allowed to mix with the font color. The fragment shader is as follows:

This fragment shader allows us to render transparent text, and should be used in combination with blending:

= Rendering lines of text =

Before we can start rendering text, there are still some things that need initialization. First, we will use a single texture object to render all the glyphs:

To prevent certain artifacts when a character is not rendered exactly on pixel boundaries, we should clamp the texture at the edges, and enable linear interpolation:

It is also very important to disable the default 4-byte alignment restrictions that OpenGL uses for uploading textures and other data. Normally you won't be affected by this restriction, as most textures have a width that is a multiple of 4, and/or use 4 bytes per pixel. The glyph images are in a 1-byte greyscale format though, and can have any possible width. To ensure there are no alignment restrictions, we have to use this line:

We also need to set up a vertex buffer object for our combined vertex and texture coordinates:

We now have everything in place to render a line of text. The recipe we will use is simple. We start with a certain baseline (vertical) and cursor (horizontal) position, load the first character, upload it as a texture, draw it at the correct offset from the starting position, and then move the cursor to the next position. We repeat this for all the characters in the line.

The function  takes 5 arguments: the string to render, the x and y start coordinates, and the x and y scale parameters. The last two should be chosen such that one glyph pixel corresponds to one screen pixel. Let's look at the  function which draws the whole screen:

We start by clearing the screen to white, and setting the font color to black. Since we are not using any transformation matrix, we can simply calculate the scaling factors by dividing 2 by the screen's width and height. The first line (a well-known pangram) is aligned exactly to pixel coordinates. The second line is deliberately misaligned by half a pixel in each direction. The difference is obvious; the second line looks more fuzzy and some ugly artifacts are visible.

You might naively think that it would be better to have textures that are twice or more times bigger than how you draw them, so that OpenGL does the anti-aliasing. Unless you use multi-sampling or FSAA, this is not what will happen. It will always be better to have FreeType render the font at the right size, and render it correctly aligned. To illustrate, let's draw the 48 point font scaled down 2 and 4 times, and compare that to "unscaled" 24 and 12 point font sizes. Add the following to the  function:

You should see that despite the linear texture interpolation of OpenGL, the quality of the downscaled text is worse than the unscaled text. There are several reasons for this. First is that by scaling the text, you are letting OpenGL anti-alias an already anti-aliased glyph image. Second, linear texture interpolation uses a weighted average of at most four texture elements, and is not really the same as calculating the average of a 2x2 or 4x4 region from the texture. Last but not least, the FreeType library will by default apply hinting to improve the contrast of the characters. The effect of hinting is lost when the pixels of the hinted glyph image are not mapped on-to-one to screen pixels.

Rendering colored and/or transparent text is easy, we just change the uniform color to our liking:

Exercises:
 * Try changing the background color.
 * Try using GL_LUMINANCE and GL_INTENSITY instead of GL_ALPHA.
 * Try changing the blending to.
 * Try removing the call to.
 * Try different texture wrapping and interpolation modes.
 * Try drawing the text . What happened?
 * Draw the baselines and cursors for every character.
 * Add a transformation matrix and use it to rotate the text by 30 degrees.
 * Use a perspective transformation matrix, and look at the text from an oblique angle.