Real-Time 3D Rendering with DirectX and HLSL: Hello, Shaders!
This chapter is from the book
This chapter is from the book
This chapter is from the book
In this chapter, you write your first shaders. We introduce HLSL syntax, the FX file format, data structures, and more. By the end of this chapter, you’ll have a base from which to launch the rest of your exploration into graphics programming.
Your First Shader
You might recognize the canonical programming example “Hello, World!” as a first program written in a new language and whose output is this simple line of text. We follow this time-honored tradition with the shader equivalent “Hello, Shaders!”—this time, your output is an object rendered in a solid color.
To begin, launch NVIDIA FX Composer and create a new project. Open the Assets panel, right-click on the Materials icon, and choose Add Material from New Effect. Then choose HLSL FX from the Add Effect dialog box (see Figure 4.1).
)
Figure 4.1 NVIDIA FX Composer Add Effect dialog box.
In the next dialog box, select the Empty template and name your effect HelloShaders.fx (see Figure 4.2).
)
Figure 4.2 NVIDIA FX Composer Select HLSL FX Template dialog box.
Click Finish in the final dialog box of the Effect Wizard to complete the process. If all went well, you should see your HelloShaders.fx file displayed in the Editor panel and associated HelloShaders and HelloShaders_Material objects listed in the Assets panel. Notice that the Empty effect template isn’t empty after all—NVIDIA FX Composer has stubbed out a bit of code for you. This code is actually close to what you want in your first shader, but it’s written for DirectX 9, so delete this code and replace it with the contents of Listing 4.1. Then we walk through this code step by step.
Listing 4.1 HelloShaders.fx
cbufferCBufferPerObject {float4x4WorldViewProjection : WORLDVIEWPROJECTION; }RasterizerStateDisableCulling { CullMode = NONE; };float4vertex_shader(float3objectPosition : POSITION) : SV_Position {returnmul(float4(objectPosition, 1), WorldViewProjection); }float4pixel_shader() : SV_Target {returnfloat4(1, 0, 0, 1); }technique10main10 {passp0 { SetVertexShader(CompileShader(vs_4_0, vertex_shader())); SetGeometryShader(NULL); SetPixelShader(CompileShader(ps_4_0, pixel_shader())); SetRasterizerState(DisableCulling); } }
Effect Files
Direct3D pipeline stages can be programmed through separately compiled shaders. For instance, you can house a vertex shader in one file (commonly with the extension .hlsl) and a pixel shader in a different file. Under this configuration, each file must contain exactly one shader. By contrast, HLSL Effect files enable you to combine multiple shaders, support functions, and render states into a single file. This is the file format we use throughout this text, and Listing 4.1 uses it.
Constant Buffers
At the top of your HelloShaders.fx file, you find a block of code starting with cbuffer. This denotes a constant buffer, whose purpose is to organize one or more shader constants. A shader constant is input the CPU sends to a shader, which remains constant for all the primitives processed by a single draw call. Put another way, cbuffers hold variables, “constant variables.” They’re constant from the perspective of the GPU while processing the primitives of a draw call yet variable from the perspective of the CPU from one draw call to the next.
In your HelloShaders.fx file, you have just one cbuffer containing only one shader constant, WorldViewProjection, of type float4×4. This is a C-style variable declaration in which the data type is a 4×4 matrix of single-precision floating-point values. This particular variable (WorldViewProjection) represents the concatenated World-View-Projection matrix specific to each object. Recall from Chapter 2, “A 3D/Math Primer,” that this matrix transforms your vertices from object space, to world space, to view space, to homogeneous space, in a single transformation. You could pass the World, View, and Projection matrices into the effect separately and then perform three different transforms to produce the same result. But unless you have a specific reason to do so, sending less data as input and performing fewer shader instructions is the better option.
Note the text WORLDVIEWPROJECTION following the colon in the variable declaration. This is known as a semantic and is a hint to the CPU-side application about the intended use of the variable. Semantics relieve the application developer from a priori knowledge of the names of shader constants. In this example, you could have named your float4×4 variable WVP or WorldViewProj without any impact to the CPU side because it can access the variable through the WORLDVIEWPROJECTION semantic instead of through its name. A variety of common semantics exist, all of which are optional for shader constants. However, in the context of NVIDIA FX Composer, the WORLDVIEWPROJECTION semantic is not optional; it must be associated with a shader constant for your effect to receive updates to the concatenated WVP matrix each frame.
Render States
Shaders can’t define the behaviors of the nonprogrammable stages of the Direct3D pipeline, but you can customize them through render state objects. For example, the rasterizer stage is customized through a RasterizerState object. A variety of rasterizer state options exist, although I defer them to future chapters. For now, note the RasterizerState object DisableCulling (see Listing 4.2).
Listing 4.2 RasterizerState declaration from HelloShaders.fx
RasterizerState DisableCulling
{
CullMode = NONE;
};
We briefly discussed vertex winding order and backface culling in Chapter 3, “Tools of the Trade.” By default, DirectX considers vertices presented counter-clockwise (with respect to the camera) to be back-facing and does not draw them. However, the default models included with NVIDIA FX Composer (the Sphere, Teapot, Torus, and Plane) are wound in the opposite direction. Without modifying or disabling the culling mode, Direct3D would cull what we would consider front-facing triangles. Therefore, for your work within NVIDIA FX Composer, just disable culling by specifying CullMode = NONE.
The Vertex Shader
The next HelloShaders code to analyze is the vertex shader, reproduced in Listing 4.3.
Listing 4.3 The vertex shader from HelloShaders.fx
float4vertex_shader(float3objectPosition : POSITION) : SV_Position {returnmul(float4(objectPosition, 1), WorldViewProjection); }
This code resembles a C-style function, but with some key differences. First, note the work the vertex shader is accomplishing. Each vertex comes into the shader in object space, and the WorldViewProjection matrix transforms it into homogeneous clip space. In general, this is the least amount of work a vertex shader performs.
The input into your vertex shader is a float3, an HLSL data type for storing three single-precision floating-point values—it’s named objectPosition to denote its coordinate space. Notice the POSITION semantic associated with the objectPosition parameter. It indicates that the variable is holding a vertex position. This is conceptually similar to the semantics used for shader constants, to convey the intended use of the parameter. However, semantics are also used to link shader inputs and outputs between shader stages (for example, between the input-assembler stage and the vertex shader stage) and are therefore required for such variables. At a minimum, the vertex shader must accept a variable with the POSITION semantic and must return a variable with the SV_Position semantic.
Within the body of your vertex shader, you’re calling the HLSL intrinsic function mul. This performs a matrix multiplication between the two arguments. If the first argument is a vector, it’s treated as a row vector (with a row-major matrix as the second argument). Conversely, if the first argument is a matrix, it’s treated as a column major matrix, with a column-vector as the second argument. We use row-major matrices for most of our transformations, so we use the form mul(vector, matrix).
Notice that, for the first argument of the mul function, you are constructing a float4 out of the objectPosition (a float3) and the number 1. This is required because the number of columns in the vector must match the number of rows in the matrix. Because the vector you’re transforming is a position, you hard-code the fourth float (the w member) to 1. Had the vector represented a direction, the w component would be set to 0.
The Pixel Shader
As with the vertex shader, the HelloShader pixel shader is just one line of code (see Listing 4.4).
Listing 4.4 The pixel shader from HelloShaders.fx
float4pixel_shader() : SV_Target {returnfloat4(1, 0, 0, 1); }
The return value of this shader is a float4 and is assigned the SV_Target semantic. This indicates that the output will be stored in the render target bound to the output-merger stage. Typically, that render target is a texture that is mapped to the screen and is known as the back buffer. This name comes from a technique called double buffering, in which two buffers are employed to reduce tearing, and other artifacts, produced when pixels from two (or more) frames are displayed simultaneously. Instead, all output is rendered to a back buffer while the actual video device displays a front buffer. When rendering is complete, the two buffers are swapped so that the newly rendered frame displays. Swapping is commonly done to coincide with the refresh cycle of the monitor—again, to avoid artifacts.
The output of your pixel shader is a 32-bit color, with 8-bit channels for Red, Green, Blue, and Alpha (RGBA). All values are supplied in floating-point format, where the range [0.0, 1.0] maps to integer range [0, 255]. In this example, you’re supplying the value 1 to the red channel, meaning that every pixel rendered will be solid red. You are not employing color blending, so the alpha channel has no impact. If you were using color blending, an alpha value of 1 would indicate a fully opaque pixel. We discuss color blending in more detail in Chapter 8, “Gleaming the Cube.”
Techniques
The last section of the HelloShaders effect is the technique that brings the pieces together (see Listing 4.5).
Listing 4.5 The technique from HelloShaders.fx
technique10main10 {pass p0{ SetVertexShader(CompileShader(vs_4_0, vertex_shader())); SetGeometryShader(NULL); SetPixelShader(CompileShader(ps_4_0, pixel_shader())); SetRasterizerState(DisableCulling); } }
A technique implements a specific rendering sequence through a set of effect passes. Each pass sets render states and associates your shaders with their corresponding pipeline stages. In the HelloShaders example, you have just one technique (named main10) with just one pass (named p0). However, effects can contain any number of techniques, and each technique can contain any number of passes. For now, all your techniques contain a single pass. We discuss techniques with multiple passes in Part IV, “Intermediate-Level Rendering Topics.”
Note the keyword technique10 in this example. This keyword denotes a Direct3D 10 technique, versus DirectX 9 techniques, which have no version suffix. Direct3D 11 techniques use the keyword technique11. Unfortunately, the current version of NVIDIA FX Composer does not support Direct3D 11. But you won’t be using any Direct3D 11–specific features at the beginning of your exploration of shader authoring, so this isn’t a show stopper. We start using Direct3D 11 techniques in Part III, “Rendering with DirectX.”
Also notice the arguments vs_4_0 and ps_4_0 within the SetVertexShader and SetPixelShader statements. These values identify the shader profiles to use when compiling the shaders specified in the second arguments of the CompileShader calls. Shader profiles are analogous to shader models, which define the capabilities of the graphics system that are required to support the corresponding shaders. As of this writing, there have been five major (and several minor) shader model revisions; the latest is shader model 5. Each shader model has extended the functionality of the previous revision in a variety of ways. Generally, however, the potential sophistication of shaders has increased with each new shader model. Direct3D 10 introduced shader model 4, which we use for all Direct3D 10 techniques. Shader model 5 was introduced with Direct3D 11, and we use that shader model for all Direct3D 11 techniques.
Hello, Shaders! Output
You’re now ready to visualize the output of the HelloShaders effect. To do so, you first need to build your effect through the Build, Rebuild All or Build, Compile HelloShaders.fx menu commands. Alternately, you can use the shortcut keys F6 (Rebuild All) or Ctrl+F7 (Compile Selected Effect). Be sure you do this after any changes you make to your code.
Next, ensure that you are using the Direct3D 10 rendering API by choosing it from the drop-down menu in the main toolbar (it’s the right-most toolbar item, and it likely defaults to Direct3D 9). Now open the Render panel within NVIDIA FX Composer. Its default placement is in the lower-right corner. Create a sphere in the Render panel by choosing Create, Sphere from the main menu or by clicking the Sphere icon in the toolbar. Finally, drag and drop your HelloShaders_Material from either the Materials panel or the Assets panel onto the sphere in the Render panel. You should see an image similar to Figure 4.3.
)
Figure 4.3 HellShaders.fx applied to a sphere in the NVIDIA FX Composer Render panel.
This might be a bit anti-climactic, given the effort to get here, but you’ve actually accomplished quite a lot! Take a few minutes to experiment with the output of this shader. Modify the RGB channels within the pixel shader to get a feel for what’s happening.