Shading language

A shading language is a special programming language adapted to map on shader programming. Those kind of languages usually have special data types like color and normal. Because of the various target markets of 3D graphics, different shading languages have been developed: a brief overview is given below.

Offline rendering

Shading languages used in offline rendering are geared towards maximum image quality. Material properties are totally abstracted, little programming skill and no hardware knowledge is required. These kind of shaders are often developed by artists to get the right "look", just as texture mapping, lighting and other facets of their work.

Processing these kinds of shaders is usually a time-consuming process. The computational power required to get this kind of shading to work can be rather expensive because of their ability to produce photorealistic results. Most of the time, production rendering is run on large computer clusters.

RenderMan Shading Language

The RenderMan Shading Language (often referenced as RSL or SL, for short), which is defined in the RenderMan Interface Specification, is the most common shading language for production-quality rendering. It is also one of the first shading languages ever implemented.

The language defines six major shader types:

• Light source shaders compute the color of the light emitted from a point on the light source towards a point on the surface being illuminated.
• Surface shaders model the optical properties of the object being illuminated. They output the final color and position of the point being illuminated by taking into account the incoming light and the physical properties of the object.
• Displacement shaders manipulate the surface's geometry independent of its color.
• Deformation shaders transform the entire space that a geometry is defined in. Only one RenderMan implementation, the AIR renderer, actually implemented this shader type with the restriction of only supporting a single linear transformation applied to the space (this was more like a Transformation shader, if such a type existed).
• Volume shaders manipulate the color of a light as it passes through a volume. They create effects like fog.
• Imager shaders describe a color transformation to final pixel values. This is much like an image filter, however the imager shader operates on prequantized data, which typically has a greater dynamic range than can be displayed on the output device.

Houdini VEX Shading Language

Houdini VEX (Vector Expressions) shading language (often referenced as VEX, for short) is closely modeled after the RenderMan Shading Language. Since it is integrated into a complete 3D package though, the shader writer has access to information inside the shader which is commonly not available in a rendering context. The language differences between RSL and VEX are mainly syntactical. A few shadeops have different names.

Gelato Shading Language

Gelato's shading language, like Houdini's VEX, is closely modeled after the RenderMan Shading Language. The differences between Gelato Shading Language and RSL are mainly syntactical -- Gelato uses semicolons instead of commas to separate arguments in function definitions and a few shadeops have different names and parameters.

Real-time rendering

Until recently, developers did not have the same level of control over the output from the graphics pipeline of graphics cards, but shading languages for real-time rendering are now widespread. They provide both higher hardware abstraction and a more flexible programming model when compared to previous paradigms which hardcoded transformation and shading equations. This results in both giving the programmer greater control over the rendering process, and delivering richer content at lower overhead.

Quite surprisingly those shaders, which are designed to be executed directly on the GPU at the proper point in the pipeline for maximum performance, also scored successes in general processing because of their stream programming model.

This kind of shading language is usually bound to a graphics API, although some applications also provide built-in shading languages with limited functionalities.

Historically, only few of those languages were successful in both establishing themselves and maintaining strong market position; a short description of those languages follows below.

ARB low-level assembly language

The OpenGL Architecture Review Board established ARB (GPU assembly language) in 2002 as a standard low-level instruction set for programmable graphics processors.

High-level OpenGL shading languages compile to ARB for loading and execution. Unlike high-level shading languages, ARB assembly does not support flow control or branching. However, it continues to be used for portability to a variety of GPUs.

OpenGL shading language

Also known as GLSL or glslang, this standardized high level shading language is meant to be used with OpenGL.

The language unifies vertex and fragment processing in a single instruction set, allowing conditional loops and (more generally) branches.

Historically, GLSL was preceded by various OpenGL extensions such as ARB_vertex_program and ARB_fragment_program. These preceding extensions were limited, low-level, assembly-like languages and their usage is now discouraged. The preceding extensions were themselves preceded by other proposals which did not survive in the new version.

Cg programming language

This language developed by NVIDIA has been designed for easy and efficient production pipeline integration. The language features API independence and comes with a large variety of free tools to improve asset management.

The first Cg implementations were rather restrictive because of the hardware being abstracted but they were still innovative when compared to previous methods. Cg seems to have survived the introduction of the newer shading languages very well, mainly of its established momentum in the digital content creation area, although the language is seldom used in final products.

A distinctive feature of Cg is the use of connectors, special data structures to link the various stages of processing. Connectors define the input from application to vertex processing stage and the attributes to be interpolated as input to fragment processing.

DirectX High-Level Shader Language

The high level shader language (also called HLSL for short) is a C-style shader language for DirectX 8, 9, 10, Xbox and Xbox 360. It is similar to Nvidia's Cg but is only supported by DirectX and Xbox game consoles.

References

1. ^  https://renderman.pixar.com/products/rispec/
2. ^  NVIDIA Gelato official website, http://film.nvidia.com/page/gelato.html
3. ^  Official language specification, http://www.opengl.org/documentation/glsl/
4. ^  http://oldsite.vislab.usyd.edu.au/resources/guide/houdini/
5. ^  http://oldsite.vislab.usyd.edu.au/resources/guide/houdini/vex
6. ^  Previous vertex shading languages (in no particular order) for OpenGL include EXT_vertex_shader, NV_vertex_program, the aforementioned ARB_vertex_program, NV_vertex_program2 and NV_vertex_program3.
7. ^  For fragment shading nvparse is possibly the first shading language featuring high-level abstraction based on NV_register_combiners, NV_register_combiners2 for pixel math and NV_texture_shader, NV_texture_shader2 and NV_texture_shader3 for texture lookups. ATI_fragment_shader did not even provide a "string oriented" parsing facility (although it has been later added by ATI_text_fragment_shader). ARB_fragment_program, has been very successful. NV_fragment_program and NV_fragment_program2 are actually similar although the latter provides much more advanced functionality in respect to others.
8. ^  Official Cg home page, http://developer.nvidia.com/object/cg_toolkit.html
9. ^  Fx composer from NVIDIA home page, http://developer.nvidia.com/object/fx_composer_home.html
10. Rudy Cortes and Saty Raghavachary: The RenderMan Shading Language Guide, Course Technology PTR, 1 edition (December 27, 2007), ISBN 1-598-63286-8