Week 3 -Wednesday What did we talk about last time? Graphics - - PowerPoint PPT Presentation

Week 3 -Wednesday

 What did we talk about last time?  Graphics processing unit  Programmable shading

 You can do all kinds of interesting things with programmable

shading, but the technology is still evolving

 Modern shader stages such as Shader Model 4.0 and 5.0

(DirectX 10 and 11) use a common-shader core

 Strange as it may seem, this means that vertex, pixel, and

geometry shading uses the same language

 They are generally C-like  There aren't that many:

• HLSL: High Level Shading Language, developed by Microsoft and used

for Shader Model 1.0 through 5.0

• Cg: C for Graphics, developed by NVIDIA and is essentially the same as

HLSL

• GLSL: OpenGL Shading Language, developed for OpenGL and shares

some similarities with the other two

 These languages were developed so that you don't have to write

assembly to program your graphics cards

 There are even drag and drop applications like NVIDIA's Mental

Mill

 To maximize compatibility across many different graphics cards,

shader languages are thought of as targeting a virtual machine with certain capabilities

 This VM is assumed to have 4-way SIMD (single-instruction

multiple-data) parallelism

 Vectors of 4 things are very common in graphics:

• Positions: xyzw
• Colors: rgba

 The vectors are commonly of float values  Swizzling and masking (duplicating or ignoring) vector values are

supported (kind of like bitwise operations)

 A programmable shader stage

has two types of inputs

• Uniform inputs that stay constant

during draw calls

▪ Held in constant registers or constant buffers

• Varying inputs which are different

for each vertex or pixel

 Fast operations: scalar and vector multiplications, additions,

and combinations

 Well-supported (and still relatively fast): reciprocal, square

root, trig functions, exponentiation and log

 Standard operations apply: + and *  Other operations come through intrinsic functions that do

not require headers or libraries: atan(), dot(), log()

 Flow control is done through "normal" if, switch, while,

and for (but long loops are unusual)

 In 1984, Cook came up with the idea of shade trees, a series of

• perations used to color a pixel

 This example shows what the shader language equivalent of the

shade tree is

 There are three shaders you can program  Vertex shader

• Useful, but boring, mostly about doing transforms and getting

normals

 Geometry shader

• Optional, allows you to create vertices from nowhere in hardware

 Pixel shader

• Where all the color data gets decided on
• Also where we'll focus

 The following, taken from RB Whitaker's Wiki, shows a shader for ambient lighting  We start with declarations:

float4x4 World; float4x4 View; float4x4 Projection; float4 AmbientColor = float4(1, 1, 1, 1); float AmbientIntensity = 0.1; struct VertexShaderInput { float4 Position : POSITION0; }; struct VertexShaderOutput { float4 Position : POSITION0; };

VertexShaderOutput VertexShaderFunction(VertexShaderInput input) { VertexShaderOutput output; float4 worldPosition = mul(input.Position, World); float4 viewPosition = mul(worldPosition, View);

• utput.Position = mul(viewPosition, Projection);

return output; } float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0 { return AmbientColor * AmbientIntensity; } technique Ambient { pass Pass1 { VertexShader = compile vs_4_0_level_9_1 VertexShaderFunction(); PixelShader = compile ps_4_0_level_9_1 PixelShaderFunction(); } }



The following, taken from RB Whitaker's Wiki, shows a shader for diffuse lighting

float4x4 World; float4x4 View; float4x4 Projection; float4 AmbientColor = float4(1, 1, 1, 1); float AmbientIntensity = 0.1; float4x4 WorldInverseTranspose; float4 DiffuseLightDirection = float4(0.7071f, 0.7071f, 0, 0); float4 DiffuseColor = float4(1, 1, 1, 1); float DiffuseIntensity = .5; struct VertexShaderInput { float4 Position : POSITION0; float4 Normal : NORMAL0; }; struct VertexShaderOutput { float4 Position : POSITION0; float4 Color : COLOR0; };

VertexShaderOutput VertexShaderFunction(VertexShaderInput input){ VertexShaderOutput output; float4 worldPosition = mul(input.Position, World); float4 viewPosition = mul(worldPosition, View);

• utput.Position = mul(viewPosition, Projection);

float4 normal = mul(input.Normal, WorldInverseTranspose); float lightIntensity = dot(normal, DiffuseLightDirection);

• utput.Color = saturate(DiffuseColor * DiffuseIntensity * lightIntensity);

return output; } float4 PixelShaderFunction(VertexShaderOutput input) : COLOR0 { return saturate(input.Color + AmbientColor * AmbientIntensity); } technique Diffuse { pass Pass1 { VertexShader = compile vs_4_0_level_9_1 VertexShaderFunction(); PixelShader = compile ps_4_0_level_9_1 PixelShaderFunction(); } }

 Supported in hardware by all modern GPUs  For each vertex, it modifies, creates, or ignores:

• Color
• Normal
• Texture coordinates
• Position

 It must also transform vertices from model space to

homogeneous clip space

 Vertices cannot be created or destroyed, and results cannot be

passed from vertex to vertex

• Massive parallelism is possible

 Lens effects for distortion

• Novel perspective correction

 Object definition

• Creating a mesh and having the vertex shader form its shape

 Object twist, bend, and taper  Procedural deformations

• Flags
• Cloth
• Water

 Primitive creation

• Degenerate 2D meshes given a third dimension by the shader

 Page curls, heat haze, water ripples

• Make a mesh of the screen and distort it

 Vertex texture fetch

• Apply a texture to vertices, making ocean surfaces or terrain in

hardware

 Newest shader added to the family, and optional  Comes right after the vertex shader  Input is a single primitive  Output is zero or more primitives  The geometry shader can be used to:

• Tessellate simple meshes into more complex ones
• Make limited copies of primitives

 The geometry shader is guaranteed to return output in the

same order as the input was received

 In Shader Model 4.0 and later, the output of the GS can be put

into a stream (an ordered array)

 This stream can be rasterized or it can be sent back through

the pipeline for multi-step effects

 For computational purposes, the stream could simply be

• utput non-graphically

 Clipping and triangle set up is fixed in function  Everything else in determining the final color of the fragment is

done here

• Because we aren't actually shading a full pixel, just a particular fragment
• f a triangle that covers a pixel

 So much goes on that we'll have to put it off until later

• Various lighting models are a lot of it

 The pixel shader is limited in that it cannot look at neighboring

pixels

• Except that some information about gradient can be given

 Multiple render targets means that many different colors for a

single fragment can be made and stored in different buffers

 Fragment colors are combined into the frame buffer  This is where stencil and Z-buffer operations happen  It's not fully programmable, but there are a number of

settings that can be used

• Multiplication
• Addition
• Subtraction
• Min/max

 So, people in the industry have tried to collect useful

programs for rendering things

 A collection of shaders to achieve a particular rendering effect

can be stored in an effect file (commonly with extension .fx)

 The syntax of the effects language allows your application to

set specific arguments

 You can download existing .fx

files or write your own

 There are also tools like

NVIDIA's FX Composer 2.5 that allow you to create effects with a GUI

 Now, let's examine the book's

example effect file for Gooch shading

 Camera parameters are supplied automatically  Syntax is type id : semantic

• type is a system defined type or a user defined struct
• id is whatever identifier the user wants
• semantic is a system defined use

float4x4 WorldXf : World; float4x4 WorldITXf : WorldInverseTranspose; float4x4 WvpXf : WorldViewProjection;

 Default values are given for these variables  The annotations given inside angle brackets allow the outside

program to set them

float3 Lamp0Ps : Position < string Object = "PointLight0"; string UIName = "Lamp 0 Position"; string Space = "World"; > = {-0.5f, 2.0f, 1.25f}; float3 WarmColor < string UIName = "Gooch Warm Tone"; string UIWidget = "Color"; > = {1.0f, 0.9f, 0.15f}; float3 CoolColor < string UIName = "Gooch Cool Tone"; string UIWidget = "Color"; > = {0.05f, 0.05f, 0.6f};

 Input and output types are usually defined by the user  The TEXCOORD1 and TEXCOORD2 semantics are used for

historical reasons

struct appdata { float3 Position : POSITION; float3 Normal : NORMAL; } struct vertexOutput { float4 HPosition : POSITION; float3 LightVec : TEXCOORD1; float3 WorldNormal : TEXCOORD2; };

vertexOutput std_VS(appdata IN) { vertexOutput OUT; float4 No = float4(IN.Normal,0); OUT.WorldNormal = mul(No,WorldITXf).xyz; float4 Po = float4(IN.Position,1); float4 Pw = mul(Po,WorldXf); OUT.LightVec = (Lamp0Pos – Pw.xyz); OUT.HPosition = mul(Po,WvpXf); return OUT; }

 We linearly interpolate between cool and warm colors based

• n the dot product

float4 gooch_PS(vertexOutput IN) : COLOR { float3 Ln = normalize(IN.LightVec); float3 Nn = normalize(IN.WorldNormal); float ldn = dot(Ln,Nn); float mixer = 0.5 * (ldn + 1.0); float4 result = lerp(CoolColor, WarmColor, mixer); return result; }

 Z-buffer configuration is done here

technique Gooch < string Script = "Pass=p0;"; > { pass p0 < string Script = "Draw=geometry;"; > { VertexShader = compile vs_2_0 std_VS(); PixelShader = compile ps_2_a gooch_PS(); ZEnable = true; ZWriteEnable = true; ZFunc = LessEqual; AlphaBlendEnable = false; } }

 The result of the shader given before applied to a teapot:

 The Utah teapot was modeled in 1975 by graphics pioneer

Martin Newell at the University of Utah

 It's actually taller than it looks

• They distorted the model so that it would look right on their non-

square pixel displays

 Original  Modern

 Linear algebra review  Vectors and matrices

 Read Appendix A  Finish Assignment 1, due Friday by 11:59  Keep working on Project 1, due Friday, September 27 by 11:59