replicator.org ... continuous garbage collection

Introduction

Visualization toolkits today and 3D user interfaces in the future require solutions for displaying 2D text decals in 3D space.

Current 3D text rendering libraries suffer from the following restrictions:

• The inability to use arbitrary true-type fonts.
• The low rendering quality of the 3D characters.

• Slow rendering in case of polygonised glyphs.

With the combination of well chosen mechanisms to display text in 3D, it is possible to achieve a high (though unhinted) text quality while rendering many thousands of glyphs per second on stock 3D hardware.

This text will show how and describes an implementation of a platform independent OpenGL library for 3D text.

Design decisions

Before displaying 3D text, the following decisions had to be made. These are dependent on the abilities of current stock hardware and the software-libraries available to render fonts.

Polygons or Textures

At first sight and when using hardware acceleration, polygonized fonts seem to be practical with the today’s throughput. But even the fastest consumer cards on the market are not able to render anti-aliased polygons at a reasonable speed, and because screen pixel resolution is currently somewhat limited, jagged edges are to be expected.

Even with full-screen anti-aliasing (FSAA), polygonized text quality is not acceptable, FSAA puts together a number of pixels to one (technically the complete scene will be rendered at a higher resolution and then scaled down), making low-contrast scenes look perfect, but high-contrast edges will result in a pulsating appearance when moved slowly.

There is another drawback using polygons: The high number of transformations used for the vertices and the high number of polygons needed to make rounded strokes appear without irregularities.

Current hardware is optimized for games, games are mostly texture-based including real-time alpha-blending support.

Font rendering library or pre-created font textures

Some text rendering libraries are using pre-rendered glyphs placed in a small texture to display the fonts. Obviously such applications are limited:

• the fonts to be used are static, so if one wants to use a new font, it had to be created by an independent tool.
• the used font format is proprietary.

• The fonts used have a limited, fixed quality, because all the glyphs of a font were placed in one texture of a fixed size.

But on current stock hardware:

• the pixel size of the textures has been increased (some are able to store textures with a resolution of 2048×2048 pixels).

• texture memory has been increased to allow much more textures directly to be stored in the graphics-hardware RAM. Also there are well tested open-source libraries available to render font glyphs at arbitrary resolutions.

As a conclusion, using a font library for creating the 2D glyphs and rendering the text decals by using hardware-accelerated texture mapping is appropriate for a text-rendering library implemented to support current stock hardware.

GLTX uses textures and the font-library FreeType.

Features

Initially GLTX should be small, optimized only for the best results in terms of quality and rendering speed. But while developing the library it turned out that all features needed were easy to implement in an orthogonal fashion.

arbitrary fonts

Using the FreeType library, GLTX is able to use arbitrary fonts and even supports most of the font formats available.

font hinting

Hinting 2D fonts for output in a 3D environment reduces output quality. Hinting unbalances the weight of the individual glyph strokes. Optional font hinting is supported, but not recommended.

texture and glyph creation on demand

GLTX realizes each glyph in a texture on its first use. So if an application uses only a subset of a font, only these glyphs have to be created.

anti-aliased glyphs

Beginning with version 2, the FreeType library supports rendering of anti-aliased glyphs, which turned out to be a big improvement of the output quality, surprisingly not interfering with FSAA. And if being rendered using a higher resolution, not decreasing the sharpness of the stroke edges.

ordered rendering

Texture state changes may be performance critical, and sorting for different textures is not that expensive, so optionally ordered rendering may be applied to render the glyphs in the order they appear in the different textures.

linear filtering

Linear filtering is strongly recommended, the quality of a nearest filtered texture output is obviously much worse.

mip-mapping

Even if mip-mapping sometimes avoids pulsating effects and visual artifacts, mip-mapping is not recommended for the following reasons:

• controlling the spacing between the glyphs in one texture is not an easy task and requires much empty, unused space in the used glyphs inside the composite textures.

• when rendering a mip-mapped texture, the engine usually selects the best matching mip-map level where the pixel resolution is similar to the resolution on the screen, this may be a good choice for colored, graphical textures, but not for displaying high-contrast (possibly anti-aliased) text. Experience shows, that for the best rendering quality, the resolution of the texture should be doubled compared to the resolution of the final transformed texture displayed on the screen. To support higher quality mip-mapping, there is a need of an extension to specify the algorithm how the renderer selects the individual mip-map levels.

Limitations

fonts

• only left-to-right fonts are supported.

• only the default ASCII character set is supported.

mip-mapping

• metric computation is wrong.

• mip-mapping takes too much texture-space, this is because of the additional margins required depending on the requested mip-map levels.

anisotropic filtering

• is not supported, you may enable anisotropic filtering directly by adjusting your display driver settings, or by applying the appropriate OpenGL extension.

Appendix

Mip-Mapping implementation

This is a short overview about the (currently not recommended) mip-mapping implementation.

Two options are available for creating mip-map texture. One is to derive each mip-map level by using a predefined filtering algorithm from the original texture, the other is to create each texture by hand.

Mechanically scaling down character glyphs likely introduces blurry edges, so the current implementation creates each mip-map level glyph using the FreeType library.

The proper control of the individual mip-map textures allows the exact computation of the required gaps between the glyphs, and even allows font-hinting algorithms to adjust the look of the glyphs at different levels.

The drawbacks of the current mip-map implementation are:

• The application calling the library has to decide about how much mip-levels should be used. If the number is too high, the spacing between the individual glyphs consumes very much texture-memory and rendering takes much more time (this is because the gaps must be rendered, even at higher resolutions). If the number is too low, smaller text won’t be displayed, fading out at a given resolution.

• The selection of the mip-maps can not be customized, so you will experience a lower quality compared using regular textures at a doubled internal resolution.

GLTX is part of the paramatrix project.