Rendering Overrides

This section describes the new rendering interface. It is intended to subsume the existing hardware “multi-pass” interface which is exposed in MPx3dModelView.

Main Features of the New Interface

To allow for control of the render loop at the start of a refresh or batch render.
To be able to have explicit rendering “operations” (e.g. a scene render) and to be able to use an arbitrary number of such render operations.
To be able to have explicit “render targets” (e.g. color, depth stencil buffers).
To allow for a sense of “context” as to where the rendering will occur (e.g. which viewport).
To allow for render operation “overrides” similar to what is currently available, and allow for future override enhancements.
To have a logical separation of drawing the scene versus the UI element.
To have the ability to access hardware resources.

Key Differences in the New Interface

To override or extend how rendering is performed, the level of integration need not be at the view or panel level. That is, a new API view and API panel are not required. The amount of overhead to introduce an override has been greatly reduced.
There is no longer any fixed looping logic where N iterations of a refresh with pre and post callbacks are required.
Instead of intercepting callbacks from the internal render loop logic, the logic now allows the API writer to queue a set of rendering operations.
Render target or output buffers need no longer be externally defined and are presented as formal rendering resources.
The mechanism has been standardized to work both for interactive as well as batch rendering.
A render logic description is formally defined by the user for the renderer to execute. This can be thought of as “retained” versus “immediate” mode execution.

Key Concepts and Constructs

Render Override

There is a formal notion of a rendering override. An override will override all rendering per refresh for interactive rendering or per frame output for batch rendering. An override is composed of a set of rendering operations. The key class for this is MRenderOverride.

Render Operation

An operation can be loosely thought of as being equivalent to a “pass” in the MPx3dModelView pass based system, except that they are explicitly defined. The key class for this is MRenderOperation. There can be predefined operations as well as custom user operations. The basic operation set includes:

A background clear operation (MClearOperation)
A 3D scene render operation (MSceneRender)
A 2D HUD (heads up display operation) (MHUDRender)
A user defined operation (MUserRenderOperation)
A quad blit operation (MQuadRender) which renders a 2D screen space quad
A target presentation operation (MPresentTarget)

Render Target Overrides

Render targets are now formalized. This is so that there is a managed and recognized set of resources that both the renderer and the plugin writer can use. Being formalized also means that the resource can be defined in a draw API agnostic way (e.g. for OpenGL and DirectX). The interface presented is a render target description, MRenderTargetDescription. The descriptions are used to describe desired render target inputs or outputs for rendering operations.

An access to the device level resource is provided so that users can write their own custom code which accesses targets.
It is still possible to use user defined render targets but device state must be restored or the renderer’s render target state will be corrupted. This is not a new restriction.

Shader Overrides

The MShaderManager interface allows access to some simple stock shaders as well as access to file based effects. These shaders can then be applied as overrides in one of two places:

As per object shader overrides for 3d scene renders.
As per quad render shader for quad blits.

State Overrides

State setting has been formalized and is managed by the renderer. State setting can be performed per render operation.

General Scene and User Operation Overrides

Basic overrides formally presented include:

Camera specification
World or scene filtering
Object type filtering
Draw mode filtering (e.g. filled, wire, component)
Access to M3dView for interactive rendering which will allow the user to use other existing overrides.
For batch rendering, the user also has access to hardware and common render globals.
As custom user operations are available, users are still free to perform their own direct drawing with the restriction that they restore the previous device level state. The same restriction currently applies for all existing hardware rendering interfaces, including MPx3dModelView overrides.

Render Logic Building

The main steps for defining a render override are:

Derive a custom render override.
Register the override with the renderer. Any number of overrides can be registered.
Set the active override for a viewport or for batch rendering.
Set up a set of render operations and overrides as an ordered list. If the render logic is a graph, then this can be broken down into a series of render operations.
Provide the list of operations when queried and update parameters per operation as required.
Custom operations and custom overrides have the ability to intercept intermediate and final render targets and may do so to use the resources as required (e.g. to save to disk, or to route to custom rendering code).

Key Restrictions

Scene modifications may not occur during rendering. This is not a new restriction.
Currently, there is no formal mechanism available for providing feedback (looping) overrides to specific points in a scene render, as the interfaces for those specific points do not yet exist. For example, looping shadow maps back to custom lights is currently not possible, as a custom light interface does not currently exist.