Effect Files

An effect file is a script that handles all the rendering of the objects it manages.

Currently there exists two dominant languages for writing effect files; Nvidia’s CgFX [13] and Microsoft’s Effect Files (FX) [11]. Effect files are often used for implementing shaders, as they have control to setup and handle rendering passes, while they can also incorporate a shading language for customizing the rendering pass. Often the shader is implemented by a single effect file. Most effect file languages are very similar in their structure, and if a user is familiar with one, it should not be a problem to understand effects written in the others.

We will now give a brief description to the structure of the effect file used in this thesis. In AppendixB.1we show an implementation of a shader that does specular lighting, with the specular component modulated by a texture. The shader uses the effect file format called Shaderlab, which illustrated below in figure1.2. For now it should be thought of as a pseudo format, but it is actually an real effect file format that is a part of the game engine we have chosen to integrate our work with.

The properties scope is used for defining variables that can be modified exter-nally. These could be colors, textures or similar variables used for the rendering.

When defined in the Properties scope they will automatically be setup by the effect file language. The Category defines a scope of states common to every-thing inside it. It is possible to overwrite these state settings in subsequent subshaders and pass scopes though. The subshader scope is used to set up the rendering passes for the effect. Only one subshader will be executed in an effect file. Shader Lab examines the subshaders in a top-down approach, and uses the first one it encounters that will be able to execute on the underlying hardware. If no subshader in a particular effect file is supported, the shader will fall back to another shader, as specified with the Fallback command, that is set as the last thing in the effect file. Within a subshader it is possible to alter the OpenGL rendering state, and have any number of rendering passes. These passes are set up using the Pass scope. Each Pass results in an actual rendering pass being performed by the engine. In a Pass scope it is possible to modify the OpenGL Rendering state, plus specify vertex and/or fragment programs. If such programs are specified they will substitute the fixed function pipeline that OpenGL otherwise uses. If no programs are specified, most effect file formats has a material tag that can be used to set material constants used by OpenGL.

S h a d e r ” S h a d e r Name” { P r o p e r t i e s {

}

Ca t e g o r y {

// OpenGL S t a t e s can be w r i t t e n h e r e , t h e y w i l l work i n t h e wh o l e Ca t e g o r y s c o p e . s u b s h a d e r { // For GPUs t h a t can do Cg programs

// OpenGL S t a t e s can be w r i t t e n h e r e , t h e y w i l l work i n t h i s Su bShader s c o p e . P a ss {

// OpenGL S t a t e s can be w r i t t e n h e r e , t h e y w i l l work i n t h i s P a ss . CGPROGRAM

// Put y o u r normal Cg c o d e h e r e ENDCG

}

// . . . More p a s s e s i f n e c e s s a r y . }

s u b s h a d e r { // For a l l OpenGL c o m p l a i n t GPUs

// . . . P a s s e s t h a t u s e s o t h e r r e n d e r i n g t e c h n i q u e s // Such a s normal OpenGL f i x e d f u n c t i o n

} }

F a l l b a c k ” f a l l b a c k s h a d e r name”

Figure 1.2: The structure of an effect file.

This thesis will describe a system that presents the structure outlined above in a graphical manner. We will show how this results in a far more accessible way of creating shaders, a way that does not require knowledge about programming or the underlying graphics hardware. This results in great workflow improvements for shader development, and will enable more users to have a greater control over the appearance of their scenes.

Chapter 2

Previous Work

The previous work on shader graphs can be divided into two main categories, Industrial and Academic work. In this chapter we will discuss the most rel-evant work in both categories. The main difference between industrial and academic work, is that the industrial work is only documented towards using the final product, and very little information about the underlying technology is revealed. This is quite logical, as the companies does not wish to reveal any specific technology they have developed to competing companies. The industrial work also tends to be more finalized than the academic work, which mainly fo-cuses on specific problems, rather than creating a full solution. Besides previous shader graph work, we also discuss Renderman, IDE’s like RenderMonkey and FX Composer and content creating tools such as Maya and Softimage. These are all relevant industry tools that either contains shader graph editors, or has significant relevance for shader programming.

The project discussed in this thesis is an industrial project, therefore it will be relevant to compare the final result with the industrial work discussed in this chapter. We will also discuss the academic work though, as they reveal more details about their implementation, which we can analyze and compare with our implementation. We will begin this chapter with a brief discussion of the Renderman Shading Language, which were developed by Pixar, as this were one of the first shading languages.

Shader Type Definition

Light-source Shader The light-source shader uses variables such as the light color, intensity and falloff information to calcu-late the emitted light.

Displacement Shader Displacement shaders can be used to add bumps to surfaces.

Surface Shader In renderman surface shaders are attached to every primitive, and they use the properties of the surface to calculate the lighting reflected from it.

Volume Shader Can be used to render volume effects in participating media.

Imager shaders Performs pixel operations before an image is quan-tized and output.

Table 2.2: Shader types in Renderman