480 likes | 701 Vues
FOOTBALL AT 60 FPS: The Challenges of Rendering Madden NFL 10. Introduction. Jayeson Lee-Steere Technical Director for Football’s Central Graphics & Infrastructure 7 Years with EA Tiburon 17 Years in Industry Joe Harmon Lead Technical Artist for Madden NFL Football 4 Years with EA Tiburon.
E N D
FOOTBALL AT 60 FPS: The Challenges of Rendering Madden NFL 10
Introduction • Jayeson Lee-Steere • Technical Director for Football’s Central Graphics & Infrastructure • 7 Years with EA Tiburon • 17 Years in Industry • Joe Harmon • Lead Technical Artist for Madden NFL Football • 4 Years with EA Tiburon
Overview • Challenges facing Madden Football • Shader Authoring Workflow • Lighting Workflow • Fields • Faces • Crowd Rendering • Colorization and Texture Compositing
Madden Rendering Challenges • Scale • 60,000+ characters on screen • 100+ characters on field • authentic stadium • realistic grass • costly post effects • Lighting Variation • geographic locations • time of day • weather conditions • Raising the bar • 6 iterations between 360/PlayStation 3 • 30fps -> 60fps
Shader Authoring Workflow • Madden shaders authored primarily by Technical Artists • Each shader is custom written for its application • No ‘do everything’ shaders • Shaders written using a variant of HLSL which compiles for both xbox 360 and ps3 • We use a custom version of Maya that allows artists to view the same real time shaders as used in game. • Artists set and tune material parameters within Maya
Shader Authoring Workflow • The Madden rendering technology automatically binds runtime variables to shader parameters to improve efficiency of rendering • Normalizing the light direction • Player Numbers and names
Lighting Workflow • Lighting is key for realistic sports rendering • Realistic lighting can also get expensive • Madden’s lighting solution is a hybrid of baked and real-time lighting • Increases efficiency • Environment objects and characters have separate lighting functions • Allows individual tuning for unique settings • Character lighting is more expensive
Lighting Workflow • All Madden shaders use global lighting functions • Important for consistency • Global changes can be made quickly • Environment lighting formula: • Color texture * (diffuse + ambient + night bake) • Night bake = vertex color * occlusion texture • Character lighting formula: • Color texture * (diffuse + ambient) + specular • Specular = rim spec + cube spec + direct spec
Lighting Workflow • Nearly all lighting tuned live in game • Lighting parameters controlled through blending files (basically XML) authored by lighting artists • Each BLE has keyframes for times of day • Lighters use our lighting tool, Glint, to adjust lighting parameters • Lighters control post effects through Glint
Fields • Field rendering is challenging due to the size of the field • A small shader change can have a large performance cost • Field rendering Performance and visual quality impact one another and must be balanced • The Field must support dynamic degradation and weather effects • Tunable through glint
Faces • Madden has 29 high res face texture sets loaded at any given moment • 22 Players • 2 Coaches • 5 Referees • Maintaining high visual quality becomes challenging due to memory limitations • Player heads consistently loading and unloading
Hue, Saturation, Value (HSV) • HSV is a color space, like RGB • Hue: A color • Saturation: The amount of a color • Value: The darkness of a color • Storing the color information in HSV format allows each channel to be compressed individually when using separate textures
RGB Hue Saturation Value
Hue, Saturation, Value (HSV) • The Hue texture is the RGB representation of Hue • Storing the Hue as an RGB texture avoids costly shader math when converting HSV to RGB • Once the Hue is stored as RGB into a texture the shader logic becomes simple Float3 Hue = tex2D(hueSampler, texCoords);Float3 Sat = tex2D(satSampler, texCoords);Float3 Val = tex2D(valSampler, texCoords);Float3 finalColor = lerp(1, Hue, Sat) * Val;
Hue, Saturation, Value (HSV) • The Hue and Saturation can be combined into a single texture for optimization • We call the combined texture ‘chroma’ Float3 Chroma = tex2D(chromaSampler, texCoords);Float3 Val = tex2D(valSampler, texCoords);Float3 finalColor = Chroma * Val;
One DXT5 512x256 texture One 128x128 A8R8G8B8 One 512x512 DXT1
One DXT5 512x256 texture One 128x128 A8R8G8B8 One 512x512 DXT1
Crowd Rendering • Not about card rendering • About 3D characters that: • Support swap parts for variety • Are easy to author • Render super fast • = one shader, one set of shader parameters*, one draw for everyone * We call a shader selection + set of parameters a material
Crowd Rendering • Can we just author the previous group as one mesh with one material? • Yes, we’ve done this • Have to duplicate it to get enough people • Lots of redundant authoring (e.g. duplicating mesh parts to assign unique UV’s) • Character locations fixed • Obvious patterns show up • Some workarounds possible but difficult, hacky and reduces performance
Crowd Rendering • Authoring for our solution • Make skinned meshes like usual • Restriction 1: All must use the same shader • Restriction 2: All textures must be the same size • Can have lots of meshes, materials • Swap parts defined using an existing technique • Now we need some pipeline/runtime magic to turn that into one draw call
Crowd Rendering • The pipeline/runtime magic • Collapse to one mesh • Similar to standard instanced rendering techniques • Collapse to one material • Copy all parameters into one • Collapse textures to texture atlas • Technical details in appendix slides
Crowd Rendering • Good • Authoring • Extensible content • Super fast (100x +) • Variety • Bad • Complicated shader • Complicated pipeline/runtime • 1 shader (alpha?)
Colorization and Texture Compositing • Common methods of authoring shaders: • Shader language • e.g. HLSL • Visual, node based • Maya layered shader, Houdini, etc. • Converted to shader language for game? • What about a hybrid? • Node based • Each node is a HLSL shader
Colorization and Texture Compositing • Our node + shader language implementation • Performs a rendering step for each node • The inputs are textures and other parameters • The output is a texture • Mostly used to bake results at load time • A sort is performed so that nodes are rendered in optimal order for memory usage
Example Select Selection Colorize Colorize Colors Colors Composite Composite
Colorization and Texture Compositing • Insights • A handful of generic shaders meet majority of needs • Select • Colorize • Composite • More intermediate textures actually reduces memory overhead • No need to create do-all-in-one-step shaders
Appendix: Crowd Tech Details • Mesh collapsing • General solution • Put all vertex data in one giant vertex buffer • For each character, copy swap part indices to one new index buffer per character • Use standard instanced rendering techniques to draw multiple characters at once • Software vertex pipeline (e.g. SPU) • Modify to combine output vertex data into a big buffer • Most flexible option, can make every character have unique look, behavior and animation
Appendix: Crowd Tech Details • Material Collapsing • Assign each material an index • Copy index into vertex data • Unique per material parameters copied to shader constant array (e.g. float4 params[]) • Texture assignments • Specular power • Colorization choices • etc. • Shader uses index in vertex data to look up material parameters
Appendix: Crowd Tech Details • Texture Collapsing • No texture [] in shader language • Tile each texture into one large texture (atlas) • Store texture index in float [] • Shader uses index to do UV offset