abstract shade trees
Post on 31-Dec-2015
28 Views
Preview:
DESCRIPTION
TRANSCRIPT
Abstract Shade TreesAbstract Shade Trees
Morgan McGuire1 George Stathis2
Hanspeter Pfister2,3 Shriram Krisnamurthi1
1Brown University 2Harvard Extension School 3MERL
Shaders
• Programs that color (“shade”) a pixel
• Often execute on a graphics card
• Pervasive in film and game rendering
[Proudfoot01]
Shaders
• Programs that color (“shade”) a pixel
• Often execute on a graphics card
• Pervasive in film and game rendering
[Proudfoot01]
Let’s author a pixel shader
Shading Language
(Renderman, RTSL, HLSL, GLSL, Cg)// glass_ball.glsluniform float etaRatio;uniform float fresnelPower;uniform samplerCube environmentCubeMap;varying vec3 objectSpaceIncomingVector;varying vec3 n, b,t;uniform sampler2D normalMap;varying vec3 tangentSpaceViewVector;varying vec2 textureCoordinates;
void main(void) { float bump = ((texture2D(heightFieldTexture, textureCoordinates).a) + bumpBias) * bumpScale; vec2 bumpCoords = bump * vec2(tangentSpaceViewVector.x, tangentSpaceViewVector.y) + textureCoordinates;
vec3 tangentSpaceNormalVector = texture2D(normalMap, vec2(bumpCoords.x,bumpCoords.y)).xyz * 2.0 - 1.0;
mat3 tangentObjectSpaceMat = mat3(t,b,n); vec3 objectSpaceNormalVector = tangentObjectSpaceMat*tangentSpaceNormalVector; vec3 objectSpaceReflectedVector = normalize(reflect(objectSpaceIncomingVector,objectSpaceNormalVector)); vec4 color1 = textureCube(environmentCubeMap, objectSpaceReflectedVector);
float fresnelRatio = max(0.0,min(1.0, fresnelBias + fresnelScale* pow(1.0 + dot(normalize(objectSpaceIncomingVector), normalize(objectSpaceNormalVector)),fresnelPower))); vec3 objectSpaceRefractedVector = normalize(refract(objectSpaceIncomingVector,objectSpaceNormalVector,etaRatio)); vec4 color2 = textureCube(environmentCubeMap, objectSpaceRefractedVector); vec4 mixedColorOutput = mix(color1,color2,fresnelRatio);
gl_FragColor = mixedColorOutput;}
Shade Tree for Visual Programming[Cook84; Abram+Whitted90; Borau04; Unreal06; Hargreaves04]
Parameter
Function call
Authoring in a production context…
Shader Authoring Problems1. Dependent workflow
– Artists define and use
– Programmers implement
– Frequently block on each other
2. Shaders are rarely modular– Overlapping features [Dijkstra76]
– Exacerbated by restrictive execution environments
– Programmers frequently rewrite from scratch
Artist Programmer
Shader Authoring Problems1. Dependent workflow
– Artists define and use
– Programmers implement
– Frequently block on each other
2. Shaders are rarely modular– Overlapping features [Dijkstra76]
– Exacerbated by restrictive execution environments
– To combine features, programmers frequently rewrite both from scratch
Artist Programmer
void main() {
New authoring idea…
Shade Tree
Abstract…
Abstract Shade TreeSuperposition
Reflection Refraction
Parallax Bump Mapping
Abstract Shade Tree
Superposition
Reflection Refraction
Parallax Bump Mapping
• Node = Code atom– Like functions with funny scopes
(See the paper for details)
• Arrow = Dependency– Not parameters!
• Outline = Feature– Note the overlap at Fresnel
• Requires a weaver to convert into executable code
New Workflow
1. Programmer writes atoms2. Both can visually combine atoms into features3. Artist visually combines features into trees4. Weaver synthesizes:
– Shader entry and exit points– Program structure– Parameter linkage– Type coercions– “Glue” code
5. Rendered in IDE for feedback
Problems Addressed
1. Workflow dependency reduced– Programmer writes atoms once– Artist can independently generate many shaders– Abstract Tree is independent of atom signatures
2. Modularity improved– Visualized feature interaction– Weaver resolves overlapping features– Abstract Tree is independent of atom signatures
Related Feature Work• Features as abstractions
[Parnas72; Dijkstra76; Turner99]
• Feature/Aspect-oriented programming
[Batory92; Kiczales97; Batory04]
• Software product lines
[Clements02]
• Sh Language, Combining shaders
[McCool et al. 02, McCool et al. 04]
• Über-Shader alternative
[Barzel97/Gritz98; Pellacini+Vidimce04; McGuire05]
The Weaver
Weaving Algorithm
• Input: Abstract shade tree• Output: GLSL shader
1. -Rename parameters2. Topologically sort nodes3. Match inputs to outputs4. Generate code5. Generate boilerplate
Match Inputs to Outputs
Lambertian Shading
Normal Map
Some node in the middle of an Abstract Shade Tree
Match Inputs to Outputs
OWT
Lambertian Shading
Transform
Normalize
ON
Normal Map
WN̂
WL̂
WN
12
1ON
Unpack
The abstracted parameters the Weaver must reconstruct
Lambertian Shading
Transform
Normalize
ON
Normal Map
WN̂
WL̂
WN
12
1ON
Unpack
Match Inputs to Outputs
Globals
Basis Change
Upstream Output
Storage Class Change
OWT
The abstracted parameters the Weaver must reconstruct
Matching Algorithm
• Bind each input parameter to the “closest” matching output parameter of some ancestor node
• “Closest” = shortest/fastest type coercion
• Typical GLSL types are just storage classes– e.g., float3 vector color point …– float LambertianShading(float3 normal, float3 light)
– Not much information in “float3”
• Need a richer type system…
Semantic Types
• Encode information like “world-space vector” in types
• Two variables with precisely the same semantic type are likely semantically interchangeable
Semantic Types
1
TLK JavaC/GLSL
Too general Useful Too specificNumber of types
Some Semantic Types for Shading
Float1 LambertianShading(UnitWorldNormalFloat3 normal, UnitWorldVectorFloat3 light)
Dimension: {2, 3, 4, any }
Length: {Unit, any }
Basis: {Tangent, Object, World, Screen, any }
Interpretation: {Color, Texcoord, Normal, Point, Vector, any}
Precision: {float32, int32, Boolean, any }
• Type coercion now includes normalization, basis change, unpacking, storage change, etc.
• “any” allows polymorphism• Could add “meters,” “non-negative,” etc.
Parameter Matching is Semantic Coercion Tree Search
VEC3___O_NOR
NormalWorldToEyeSpace
VEC3___W_NOR
NormalTangentToObjectSpace
VEC3___T_NOR
VEC3___O_NOR
VEC3___E_NOR
VEC3___T_NOR
VEC3___O_NOR
NormalObjectToTangentSpace NormalObjectToWorldSpace
NormalWorldToObjectSpace NormalTangentToObjectSpace
Weaver Properties
• Always terminates• Bounded (and small) memory requirements• Always generates a legal program
• …but sometimes it is the wrong program• Most common error: Parameter aliasing
– Artist missed a dependency– Programmer assigned an overly generic type– Anecdotally infrequent
Results
Bumpy Glass
Bumpy GlassManual
(GLSL)
Automatic
(AST)
Final Source Length 58 lines 188 lines
Assembled 41 instr. 46 instr.
Radeon 9700 @ 512 x 512
245 fps 240 fps
1024 x 768 50 fps 50 fps
User experience?
IDE
Phong Illum. + Parallax Map + Texture Map
Anisotropic + Diffuse Lighting
Phong Illum. + Projective Light + Shadow Map
Summary of Contributions
• Abstract shade trees
• Semantic type system
• Weaver for shader synthesis
• Visual editor
Future Directions
• Consider performance model during parameter matching
• Beyond pixel shaders• Other interesting semantic types
• How do you debug abstract trees?
• Applications to general scripting
Thanks
• NVIDIA
• MERL
• NSF
• Iron Lore Entertainment
top related