Shader Interfaces

Deprecated

To realize the goal of providing inaccurate but fast previews, it is important to replace any software node with a hardware node, or omit it altogether, and still obtain a reasonable simplified image. Global illumination has no hardware equivalent, but a software shader that renders an object layer (such as the three object nodes in the above graphs) may have an equivalent or simplified hardware version. This requires that a shader interface is introduced that allows defining hardware and software shaders that provide a similar interface to the scene. The following intrinsic differences need to be abstracted:

Software shaders have inputs and outputs. It is possible to create graphs of shaders where shaders obtain their inputs from the outputs of other shaders. Such graphs can be used to create Phenomena, which encapsulate one or more shader graphs and other information such that the Phenomenon appears like a monolithic shader. This allows a separation of functions: different components of a complex effect may be built from simple shaders, each taking care of some aspect of the effect.
Hardware shaders consist of two functions, one modifying geometry and precalculating data (called the vertex shader), and one doing the actual shading calculation (the fragment shader). There is also a constant shared data storage called uniform variables. Both types of shaders are monolithic; it is not possible to build up complex effects from simple dedicated functions. Also, the uniform variables are the only place to pass input parameters to both types of shaders. Most importantly, mental ray's separation of surface, volume, texture, and light shaders cannot be represented in hardware.
However, NVIDIA's Cg 1.2 shader language compiler has the ability to compile the shader nodes of Phenomena and their connections into monolithic hardware shaders. This was developed in close cooperation between NVIDIA and mental images.

Although the implementation is obviously different, both software shaders and hardware shaders accept parameters in a similar way. mental ray supports mapping standard mental ray shader parameters to uniform variables, unpacking information into a form that the hardware shaders can use:

Simple data formats such as vectors, floats, and matrices can be stored in uniform variables without change.
Integers and booleans require conversion to floating-point format.
Lights require obtaining light information from the referenced light instances and light elements, such as position, orientation, cone angles, and energy, storing the resulting data set in uniform variables. Lights must be part of the material definition otherwise they will no be part of the illumination calculation in the fragment shader.
Textures and other maps require preloading the necessary textures into hardware memory, probably at a reduced resolution to fit into the limited space. The necessary reference data is stored in uniform variables.

Software shaders have no inherent limit on the number of lights and textures. Hardware shaders do, because the number of uniform variables, registers or number of instructions are rather limited. Effects that would exceed this limit require layering. For example, if there is only room for ten lights in the uniform variables but the shader's light list contains twenty, the shader must be called twice to layer the effect. The design does not attempt to automate this at this time because it is not known how lights and other parameters interact. If the shader fails to load, it will either render with a default hardware material or with rendered the software version.