FOOTBALL AT 60 FPS: FOOTBALL AT 60 FPS: The Challenges of Rendering Madden NFL 10

Introduction Jayeson Lee-Steere – Technical Director for Footballs 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

The Challenges of Rendering Madden Football

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

Maya rendering with game shaders

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 Maddens 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

Glint

Time of day

Fields

View of field from game play camera

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

Field Texture Components

Field with no degradation

Field with heavy degradation

Field with snow

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 HueSaturationValue

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;

RGB Hue and Saturation combined Value

One DXT5 512x256 textureOne 128x128 A8R8G8B8 One 512x512 DXT1

One DXT5 512x256 textureOne 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, weve done this – Have to duplicate it to get enough people – Lots of redundant authoring (e.g. duplicating mesh parts to assign unique UVs) – 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 slidesappendix

Crowd Rendering Good – Authoring – Extensible content – Super fast (100x +) – Variety Bad – Complicated shader – Complicated pipeline/runtime – 1 shader (alpha?)

Colorization and texture compositing

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 Colorize Composite Selection Colors

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

Questions?

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