glFX at a glance

Effects or FX have become an essential structuring device for graphics applications, particularly games. Definitions vary, but loosely speaking, an effect comprises

• a set of resources (textures, shader programs, render targets, and geometry),
• a defined set of control parameters, and
• a sequence of rendering steps or 'passes', each defined by a rendering pipeline state, the resources it uses, and (potentially) values for some of its control parameters, that define or modulate the appearance of a graphical model or scene in some desired way. Examples include classes of materials, lighting effects (including environment mapping and shadows), and global effects such as depth of field.

An effects framework has several components. First, there is the data model that describes the space of possible effects, in somewhat the same way that a attribute grammar can be used to define the space of possible programs in a programming language. Second, there is a run-time API that allows applications to build and use instances of effects. Third, a framework may optionally provide one or more file formats that define standard encodings of effects. These formats may serve various needs, including persistent storage, interchange with or between digital content creation (DCC) tools, and delivery to the end application.

The need for an effects framework grows along with the complexity and sophistication of the rendering API, and has become critical in the age of programmable (shader-based) graphics. High-end applications such as modern game engines typically include dedicated effects management systems that are tuned to their particular needs. However, general-purpose effects frameworks such as Microsoft's .FX and NVIDIA's CgFX have proven to be extremely useful. In particular, they are an essential link between DCC tools and applications. DCC tools create and edit abstract, portable representations of effects, which are ultimately delivered (suitably encoded) to the application. Effects runtime APIs allow the application to create runtime representations of the effects from their encoded descriptions, and apply them to models and scenes.

There is currently no standard effects runtime API for OpenGL or OpenGL ES. In the absence of a standard API, OpenGL applications must do the work of creating and maintaining effects themselves. This is burdensome, encouraging a proliferation of ad hoc, non-standard effects formats and APIs that are just complex enough to meet the needs of a single application. It also tends to hurt application performance, since the base rendering APIs have no opportunity to optimize rendering based on higher level information. Most damaging, however, is the fact that, without a standard effects framework, DCC tool vendors have little motivation to target OpenGL and OpenGL ES platforms. This limits the usefulness of these APIs and slows their adoption.

The Khronos Collada Working Group has addressed part of the problem by defining Collada FX, a data model and file format that is capable of describing OpenGL and OpenGL ES effects. The missing piece of the puzzle is the run-time effects API. glFX is intended to close the gap, providing an end-to-end tool chain that leads from DCC tools in the studio to fielded applications.

The glFX group will produce the following:

1. A specification for a C language API for creating and manipulating effects and effects instances based on the Collada FX data model. Manipulation will include setting mutable parameters of effects, setting rendering API state by reference to effects objects, and (perhaps) actual rendering. The rendering interface will be based on OpenGL and OpenGL ES, but may also be portable to other rendering APIs.
2. Conformance tests that verify the correct operation of an implementation of the API
3. Example programs, utilities in source code format, and other infrastructure as needed to encourage use and adoption.