The Render Loop

A pipeline can be configured based on the requirements for either batch or viewport rendering. Each configuration may or may not be invoked and any series of configurations may be invoked per render. The logic for a render loop thus consists of all configurations executed within a single frame.

In such a scheme, it is possible (and common) for render items to be updated and drawn under different rendering contexts as defined by a configuration.

The rendering context can be logically split into two parts based on available data. The available set of data usable at draw time is called the draw context.

A draw context reflects the underlying GPU context or state. In general, the greatest variation in state occurs during the drawing of render items. Examples of variations of state include: object-to-world matrix, the bound shader, the current blend state, the currently bound textures and so forth. States such as camera matrices and viewport dimensions are generally constant within a pipeline and thus constant at draw time.

In addition to information available at draw time, the rendering context can also track rendering preferences which includes the layering in of semantic categorizations. In particular, the context can reflect the display mode categorizations as well as the logical categorization of objects. Sample display modes include: wireframe, shaded, textured, lit and transparent categorizations. For example a render item can be explicitly tagged with a semantic indicating that it is “transparent.” Examples of the latter include: filled surfaces, UI, grid and overlays.

With these additional concepts, we can extend the previous pipeline description with the notion of rendering and draw contexts, collections of renderable objects as lists, and add a Categorization phase:

Figure 9

Categorization makes use of semantics as well as shader and data properties to determine whether to produce additional lists. Render items in these lists flow down the pipeline in the same fashion as those not filtered into additional lists.

Context exists throughout the pipeline with data available for reading or writing at specific times. No draw context is provided when it is not required. In particular, no draw context is required during geometry data update.

A concrete example is transparency handling. A transparency list may result from categorization, resulting in a draw phase for handling opaque render items and one for handling transparent items. Often, even with the old system, plug-ins do not take into consideration that they may be drawn more than once and with different contexts. This is a common occurrence which may occur for various reasons based on the rendering configuration.

Another example follows, where we present shadow map generation “pass” followed by a beauty “pass”. Each pass can be said to have semantics which are relevant for that pass. A “pass context” would group such information. Each runs a pipeline with its own configuration parameters. In total, a render item could be drawn 2 or more times.

Figure 10

In the shadow map generation pipeline the render context would have a camera based on the light casting the shadow. The pass context would indicate rendering is occurring to create shadow maps. The categorization would prune out everything except “shadow casters” and discard all other render items.

Figure 11

In the beauty pass pipeline, this particular example extracts all opaque and transparent objects and places them into two lists for rendering. All other render items are discarded. The beauty pass context would provide information that a beauty pass is being performed as well indicate whether the opaque or transparent lists are being rendered.

These are just examples of internal scenarios. As the API is open for customizable render loops, plug-ins should not expect to be invoked to update or draw only once in a frame render.