HOW CRYENGINE 3 AND AMD GCN ARCHITECTURE GAVE BIRTH TO A RED GEM: "PROJECT PHOENIX"
Bill Bilodeau Developer Relations EngineerAMD
Kedhrin GonzalezCreative DirectorIllfonic
Sean TracySenior Field Applications EngineerCrytek
Dongsoo HanSoftware Research EngineerAMD
3| Project Phoenix | March 27, 2013
Creating A New Ruby
4| Project Phoenix | March 27, 2013
CREATING A NEW RUBY
Re-imagining an icon
– Ruby in the past
– New design
Cinematic Feel
– Established Partners
– Making a game cinematic
Authoring Tools
– Tools Used
– TressFX
Leveraging Technology
– CryENGINE 3
– Mesh Tessellation
5| Project Phoenix | March 27, 2013
RE-IMAGINING AN ICON | RUBY IN THE PAST
Ruby through the ages
– Showcasing new technology
– Anime Style
6| Project Phoenix | March 27, 2013
RE-IMAGINING AN ICON | NEW DESIGN
New Design
– Modern look and design
– Realistic “combat ready” Ruby
– Based off realism
– Showcase materials and tech
7| Project Phoenix | March 27, 2013
RE-IMAGINING AN ICON | NEW DESIGN
Showcase Materials and Lighting
8| Project Phoenix | March 27, 2013
CINEMATIC FEEL | ESTABLISHED PARTNERS
The Graphic Film Company
– Simon West Directed
– Experienced Film Team
– Editing, Cinematography, and Animation Support
Digital Domain
– Body Motion Capture
– Facial Motion Capture
Art Bully Productions
– Outsourced Character Models
87Eleven
– Stunts and Fight Scenes
9| Project Phoenix | March 27, 2013
CINEMATIC FEEL | MAKING A GAME CINEMATIC
Make a game first, cinematic second
– Environment built like a game
– Focusing on Next Gen
– High pixel density assets
– Detailed Backgrounds
– Assets that can be reused
– New techniques
10| Project Phoenix | March 27, 2013
AUTHORING TOOLS | TOOLS USED
Tools Used
– 3D Studio Max, Maya, Mudbox, Crazybump, nDo 2, dDo, Zbrush, Photoshop, Illustrator, Motionbuilder, Shave and a Haircut
– Full Body Motion Capture
– Facial Motion Capture
– CryENGINE 3
11| Project Phoenix | March 27, 2013
AUTHORING TOOLS | TRESS FX
Tress FX
– Created hair in Maya using Shave and a Haircut
– Convert strands to NURB curves
– Export with Python script
– Import to Engine and finish settings
12| Project Phoenix | March 27, 2013
LEVERAGING TECHNOLOGY | CRYENGINE 3
Complete Toolset
– Lighting
– Animation
– FX
– Materials
Rapid Development
– Deployment from authoring tools
– Flexible Pipeline
13| Project Phoenix | March 27, 2013
LEVERAGING TECHNOLOGY | MESH TESSELLATION
Mesh Tessellation
– Gain Depth
– Planning for Phong
– Planning for Displacement
14| Project Phoenix | March 27, 2013
CRYENGINE 3 FEATURES LEVERAGED FOR PROJECT
PHOENIX "RUBY"
15| Project Phoenix | March 27, 2013
CRYENGINE FEATURES LEVERAGED FOR RUBY
Applied Lighting Technology
– Real-Time Area Lights with texture reflection
– Composite 3d Lens Flares and FX
– Spherical and Box Projected Image Based Lighting
Innovations in Shading and Rendering
– Screen Space Directional Occlusion – SSDO
– Real-Time Local Reflections – RLR
– Anti Aliasing for Ruby
– Eye Shader
Tessellation and Displacement
– Displacement Mapping
– Phong
15
16| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Real-Time Area Lights with texture reflection
– Light sources in videogames are usually simulated analytically via an infinitely small point light source or directional light source when projection is required.
– This is a fairly good approximation for most cases, but in the real world light can come from anywhere and has a volume, this affects shadows and light reflection appearance.
– Many situations in Ruby when light sources cannot be simple points.
Billboards, Neon Lamps, Translucent materials
Too many point lights required to simulate these effects!
16
17| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Point Lights
Point lights cast infinitely Sharp shadows.
Real Shadows never look so sharp.
CryENGINE uses shadow maps which allows them to be slightly blurred with a fixed width.
Area Lights
Area Light is a light that has volume.
Its shadow starts sharp near to the object but blurs more and more at distance.
Much more physically plausible
17
18| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
For the Ruby Project, the real-time area lights are used for artificial lighting, when the actual light sources are so large that their point-specular highlights would become a visual issue.
18
Point Light Specular HighlightArea Light Highlight and Texture Reflection
Note the difference in specular highlight shape
19| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Texture reflection and shape control
– The Ruby project also contains materials that are quite smooth and glossy as the environment is wet and in the rain.
– Area Lights are quite noticeable in this situation with the shape control over the specular highlights and with accurate texture reflection.
19
Area Light Texture Reflection
Area Light Helper Shape
Area Light Helper Shape
Point Light Helper Shape
20| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
3d Composite Lens Flares
– Procedural Flares seem great, but in practice we need Artistic Input!
– A usual solution for such challenges is to hardcode a couple cases and that’s it.
– We created something much more user friendly and to help each project have its own look without a programmer having to write anything new.
– In Ruby, most key-lights are able to produce flares, orbs, streaks and other kind of visual aberrations due to the scratches and irregularities on the lens.
20
21| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
3d Composite Lens Flares
21
Composite Flare with 3 Sub Effects
Composite Flare with 2 Sub Effects
Composite Flare with 1 Sub Effects
No Flares
22| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Image Based Lighting – IBL
– IBL is a rendering technique where complex lighting is stored in a environment map which is projected onto the scene.
Positive points:
– High quality
– Fast for many lights and even a complex environment is reflected
– Energy preserving specular power
Negative points
– Works only well for local positions with distant emitters and reflection content
– Static content only
In the CryENGINE IBL implementation diffuse lighting can be approximated very well by convolving an environment map (diffuse convolution) which is stored as a cube map again. Because of bilinear filtering, the texture can be quite low resolution as seen here.
Hard specular reflections are simple as a single texture lookup in the mirrored eye direction gives the lighting in that direction
22
23| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Depending on the light probe, the lighting can be more ambient or harsh or even colored. The following images show some examples (including sun which casts shadow)
23
24| Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Box Projected Image Based Lighting – IBL
– Essential to the ruby demo was an advancement made for IBL probes called box projected IBL.
– This is a good technique for flat mirrors.
– In the Ruby demo this is how we achieving very accurate reflections without scrolling or rotating the IBL probe.
24
Box Projection More Accurate Spherical Projection Less Accurate
25| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Screen Space Directional Occlusion
– Contact Shadows or Screen Space Directional Occlusion (SSDO) is a novel technique developed for Crysis 2.
SSDO is more physically correct than our former technique SSAO.
We came up with a new implementation which is efficient enough to allow contact shadows to be applied from every light source in the world
SSDO can also help fixing self-shadowing issues and greatly improves the global lighting quality, especially when many different objects interact with each other from a lighting standpoint.
25
SSDO OFF SSDO ON
26| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Screen Space Directional Occlusion
– SSDO provides smooth “free” contact shadows that are especially noticeable when using ambient deferred lights which do not cast traditional shadow.
– It retains the color information and applies it to the contact shadow.
26
SSDO Off SSDO On
Red and Blue Light is seen here bleeding into each other for Purple Contact Shadows
27| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Real time Local reflections
– Reflections are one of the biggest challenges to solve efficiently in real-time rendering, particularly for deferred rendering/lighting based engines.
– We introduced a novel approach we call real-time local reflections (RLR).
RLR is a screen space approximation to ray-traced HDR reflections, from and on all objects on screen.
We use a ray marching technique combined with blur and jitter to disguise low sample counts.
Although the results are not always perfect this technique allows for any kind of curved surface in the scene to efficiently reflect the nearby surroundings in real time, including self-reflections which are not possible with cube maps or planar reflections.
27
28| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Real time Local reflections
– Currently uses 9 ray marched samples but was increased to 32 for Ruby as GCN Hardware manages the high sample count quite well because of efficient flow control hardware.
– Can be increased further as hardware becomes even more powerful.
28
RLR Off RLR On @ 32 Samples
29| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Anti Aliasing
– The latest engine iteration introduces the richest set of Anti aliasing options ever available within the CryENGINE.
Anti-Aliasing and its effectiveness can vary from user to user as some prefer a very sharp image, whilst others prefer a blurrier image.
– CryENGINE gives developers and their players all of the most effective and technically sophisticated modes to suit their preferences. Each mode has very different implications in terms of overall performance, quality and sharpness.
– The CryENGINE now supports the following anti-aliasing techniques with user controlled settings for number of samples and overall quality per mode.
FXAA (Fast-Aproximate Antialiasing)
SMAA (Subpixel Morphological Antialiasing)
MSAA (the foundation DX11 support for SMAA)
And also no AA, since surprisingly some users prefer no AA at all.
29
30| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Fast Approximate Anti-Aliasing – FXAA
– This is the mode with the best performance of the pack, while offering fairly reasonable image quality. It’s a post process solution, hence it doesn’t tackle any sub pixel information, some shimmering might be noticeable on slow camera movements due to lack of sub pixel movement.
30
No AA FXAA
31| Project Phoenix | March 27, 2013
SHADING AND RENDERING
Improved Eye Shader
– The new eye shader uses Iris Parallax Mapping by default. The old alpha-blended method has been deprecated as it doesn't work with deferred lighting.
Luckily, fixing the assets requires very little work.
The new shader was designed with merged textures in mind (character head texture contains eyes and overlay in the same texture).
31
32| Project Phoenix | March 27, 2013
TESSELLATION
Tessellation and Displacement
– One of the most important updates provided by the DirectX 11 API was the introduction of Programmable Hardware Tessellation.
– With the improvements to tessellation artists working on Ruby no longer had to go through a process of pre-tessellated their assets before seeing them in engine, thus allowing them to set tessellation in real-time by clicking a checkbox on a per-material basis
– Displacement mapping
Tessellates the mesh uniformly and Reads a displacement height map to extrude the vertices.
– Phong
Phong is an approximation technique designed to smooth, based on vertex normals. The only drawback is that the surface is not perfectly smoothed across patch boundaries and can look a bit inflated.
All Tessellations Schemes are now adaptive mitigating the cost on a per patch basis of all tessellated meshes.
32
33| Project Phoenix | March 27, 2013
TESSELLATION
33
34| Project Phoenix | March 27, 2013
TESSELLATION
34
35| Project Phoenix | March 27, 2013
TressFX HAIR TECHNOLOGY IN THE RUBY DEMO
36| Project Phoenix | March 27, 2013
RUBY HAIR | TressFX
Realistic hair rendering and simulation
– Also used in Tomb Raider
– Goes beyond simple shells and fins representation used in games
– Hair is rendered as actual strands with self shadowing, antialiasing and transparency
– Physical simulation using GPU compute shadersVery flexible to allow for different hair styles and different conditions
37| Project Phoenix | March 27, 2013
RUBY HAIR RENDERING | TressFX
What goes into good hair?
– Anti-aliasing
– Volumetric self shadowing
– Transparency
Thousands of individual hair strands
– Tessellation not necessary
Based on I3D 2012 paper from AMD
“A Framework for Rendering Complex Scattering Effects on Hair”, Yang, et al.
– Algorithms modified for improved real-time performance Anti-Aliasing + Volume Shadows + Transparency
38| Project Phoenix | March 27, 2013
RUBY HAIR RENDERING | TressFX
Kajiya Hair Lighting Model
– Anisotropic hair strand lighting model
– Uses the tangent along the strand instead of the normal for light reflections
– Instead of cos(N, H) , use sin(T,H)
Marschner Model
– Two specular highlightsPrimary light colored highlight shifted towards the tip
Secondary hair colored highlight shifted towards the root
39| Project Phoenix | March 27, 2013
Anti-Aliasing
Every hair strand is anti-aliased manually
–Not using Hardware MSAA!
Compute pixel coverage on edges of hair strands and convert it to an alpha value
40| Project Phoenix | March 27, 2013
RUBY HAIR RENDERING | TressFX Self Shadowing
Self Shadowing
– Uses a simplified Deep Shadow Map technique
No Self Shadows With Self Shadows
41| Project Phoenix | March 27, 2013
RUBY HAIR RENDERING | TressFX Transparency
Order Independent Transparency (OIT) using a Per-Pixel Linked Lists (PPLL)
– Fragments are stored in link lists on the GPU Nearest K fragments are sorted and used for rendering
No Transparency With Transparency
42| Project Phoenix | March 27, 2013
TressFX HAIR SIMULATION IN THE RUBY DEMO
43| Project Phoenix | March 27, 2013
Hair strand is represented as polylines with vertices and edges
LC(Length constraints) is for inextensible hair.
Efficient global and local shape constraints to simulate various hair styles
GSC(Global shape constraints) help preserve hair style and initial shape
– It can guarantee that initial hair style can be restored even after strong agitations
LSC(Local shape constraints)
– For bending/twisting forces to support various hair styles i.e. straight, curly or wavy
Stable time integration with Verlet method
Collision detection and response between hair and model using capsules
RUBY HAIR SIMULATION | TressFX Physics Simulation
44| Project Phoenix | March 27, 2013
The most difficult part of simulation was to figure out how to simulate stylized hair.
In other words, how to hold curly hair shape?
To do it, bending and twisting forces are crucial.
As in robotics, an open-chain structure has joints and each joint has parent-child relationships to its connected joints.
With local transforms in chain structure, we can get a global transform
We find goal positions using local/global transforms for each
vertex and update vertex position by interpolating it using
stiffness value.
RUBY HAIR SIMULATION | TressFX Physics Simulation
45| Project Phoenix | March 27, 2013
Hair can be assigned to the different groups
– Allows different simulation parameters such as stiffness and damping
Fine tuning mechanism for users
– Various hair conditions can be simulated such as wet or heavy on the fly
A simple aerodynamics for wind
All simulation is processed inside GPU using Compute Shader in DX11
Mixed hair vertex and strand level parallel processes utilize GPU architecture efficiently.
By combining with vertex instancing, the actual simulated number of hair can be lower – guide hairs
RUBY HAIR SIMULATION | TressFX Physics Simulation
dry wet
46| Project Phoenix | March 27, 2013
Xuan Yu, Jason C. Yang, Justin Hensley, Takahiro Harada, and Jingyi Yu, A Framework for Rendering Complex Scattering Effects on Hair, I3D 2012.
Dongsoo Han and Takahiro Harada, Real-time Hair Simulation with Efficient Hair Style Preservation, VRIPHYS 2012 .
J. Kajiya and T. Kay. Rendering Fur with Three Dimensional Textures, SIGGRAPH 89 Conference Proceedings, pp 271-280, 1989
Stephen R. Marshner, Henrik Wann Jensen, Mike Cammarano, Steve Worley, and Pat Hanrahan, Light Scattering from Human Hair Fibers, In Proceedings of SIGGRAPH 2003.
TressFX rendering implementation by Karl Hillesdale, Research Engineer, AMD.
REFERENCES
47| Project Phoenix | March 27, 2013
ADDITIONAL REFERENCES
. Hayward, K, "Reflections with Billboard Imposters", http://graphicsrunner.blogspot.de/2008/04/reflections-with-billboard-impostors.html
. Huang, X. "Think DirectX11 Tessellation! Lots of Options", GDC 2010 (link: http://www.microsoft.com/en-us/download/details.aspx?id=27397 (batch link together with tittle name)) . BEHC "Box Projected Cubemap Environment Mapping" , http://www.gamedev.net/topic/568829-box-projected-cubemap-environment-mapping/
. McDonald, J. "Tessellation on Any Budget", GDC 2011 (http://developer.amd.com/wordpress/media/2012/10/Tessellation_On_Any_Budget-GDC2011.pps)
. Kasyan, N. , Schulz, N., Sousa, T. "Secrets of the CryENGINE 3 Graphics Technology", Siggraph 2011 (link: http://www.crytek.com/download/S2011_SecretsCryENGINE3Tech.ppt)
. Lagarde, S. "Local Image Based Lighting With Parallax Corrected Cubemaps", Siggraph 2012 (link: http://seblagarde.wordpress.com/2012/11/28/siggraph-2012-talk/)
. Sousa, T. , Wenzel, C. , Raine, C. "The Rendering Technologies of Crysis 3", GDC 2013
48| Project Phoenix | March 27, 2013
For follow-up questions, email:
QUESTIONS?
49| Project Phoenix | March 27, 2013
Disclaimer & AttributionThe information presented in this document is for informational purposes only and may contain technical inaccuracies, omissions and typographical errors.
The information contained herein is subject to change and may be rendered inaccurate for many reasons, including but not limited to product and roadmap changes, component and motherboard version changes, new model and/or product releases, product differences between differing manufacturers, software changes, BIOS flashes, firmware upgrades, or the like. There is no obligation to update or otherwise correct or revise this information. However, we reserve the right to revise this information and to make changes from time to time to the content hereof without obligation to notify any person of such revisions or changes.
NO REPRESENTATIONS OR WARRANTIES ARE MADE WITH RESPECT TO THE CONTENTS HEREOF AND NO RESPONSIBILITY IS ASSUMED FOR ANY INACCURACIES, ERRORS OR OMISSIONS THAT MAY APPEAR IN THIS INFORMATION.
ALL IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR ANY PARTICULAR PURPOSE ARE EXPRESSLY DISCLAIMED. IN NO EVENT WILL ANY LIABILITY TO ANY PERSON BE INCURRED FOR ANY DIRECT, INDIRECT, SPECIAL OR OTHER CONSEQUENTIAL DAMAGES ARISING FROM THE USE OF ANY INFORMATION CONTAINED HEREIN, EVEN IF EXPRESSLY ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
AMD, the AMD arrow logo, and combinations thereof are trademarks of Advanced Micro Devices, Inc. All other names used in this presentation are for informational purposes only and may be trademarks of their respective owners.
[For AMD-speakers only] © 2013 Advanced Micro Devices, Inc.[For non-AMD speakers only] The contents of this presentation were provided by individual(s) and/or company listed on the title page. The information and opinions presented in this presentation may not represent AMD’s positions, strategies or opinions. Unless explicitly stated, AMD is not responsible for the content herein and no endorsements are implied.
IllFonic® and the IllFonic® logo are trademarks and/or registered trademarks of IllFonic, LLC throughout the world.
50| Project Phoenix | March 27, 2013
Trademark Attribution
AMD, the AMD Arrow logo and combinations thereof are trademarks of Advanced Micro Devices, Inc. in the United States and/or other jurisdictions. Other names used in this presentation are for identification purposes only and may be trademarks of their respective owners.
©2013 Advanced Micro Devices, Inc. All rights reserved.