Project Phoenix

Report
HOW CRYENGINE 3 AND AMD GCN
ARCHITECTURE GAVE BIRTH TO A
RED GEM: "PROJECT PHOENIX"
Bill Bilodeau
Developer Relations Engineer
AMD
Kedhrin Gonzalez
Creative Director
Illfonic
Sean Tracy
Senior Field Applications Engineer
Crytek
Dongsoo Han
Software Research Engineer
AMD
Creating A New Ruby
3 | 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
4 | Project Phoenix | March 27, 2013
RE-IMAGINING AN ICON | RUBY IN THE PAST
 Ruby through the ages
– Showcasing new technology
– Anime Style
5 | 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
6 | Project Phoenix | March 27, 2013
RE-IMAGINING AN ICON | NEW DESIGN
Showcase Materials and Lighting
7 | 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
8 | 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
9 | 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
10 | 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
11 | Project Phoenix | March 27, 2013
LEVERAGING TECHNOLOGY | CRYENGINE 3
 Complete Toolset
– Lighting
– Animation
– FX
– Materials
 Rapid Development
– Deployment from authoring tools
– Flexible Pipeline
12 | Project Phoenix | March 27, 2013
LEVERAGING TECHNOLOGY | MESH TESSELLATION
 Mesh Tessellation
– Gain Depth
– Planning for Phong
– Planning for Displacement
13 | Project Phoenix | March 27, 2013
CRYENGINE 3 FEATURES
LEVERAGED FOR PROJECT
PHOENIX "RUBY"
14 | 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 | 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 | Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
Point Lights
Area Lights
 Point lights cast infinitely Sharp shadows.
 Area Light is a light that has volume.
 Real Shadows never look so sharp.
 Its shadow starts sharp near to the object but blurs
more and more at distance.
 CryENGINE uses shadow maps which allows
them to be slightly blurred with a fixed width.
17 | Project Phoenix | March 27, 2013
 Much more physically plausible
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.
Area Light Highlight and Texture Reflection
Point Light Specular Highlight
Note the difference in specular highlight shape
18 | 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.
Area Light Texture Reflection
Point Light Helper Shape
Area Light Helper Shape
Area Light Helper Shape
19 | 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 | Project Phoenix | March 27, 2013
APPLIED LIGHTING TECHNOLOGY
 3d Composite Lens Flares
Composite Flare with 3 Sub Effects
Composite Flare with 1 Sub Effects
Composite Flare with 2 Sub Effects
No Flares
21 | 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 | 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 | 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.
Box Projection More Accurate
24 | Project Phoenix | March 27, 2013
Spherical Projection Less Accurate
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.
SSDO OFF
25 | Project Phoenix | March 27, 2013
SSDO ON
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.
 Red and Blue Light is seen here bleeding into each other for Purple Contact Shadows
SSDO Off
26 | Project Phoenix | March 27, 2013
SSDO On
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 | 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.
RLR Off
28 | Project Phoenix | March 27, 2013
RLR On @ 32 Samples
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 | 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.
No AA
30 | Project Phoenix | March 27, 2013
FXAA
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 | 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 realtime 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 | Project Phoenix | March 27, 2013
TESSELLATION
33 | Project Phoenix | March 27, 2013
TESSELLATION
34 | Project Phoenix | March 27, 2013
TressFX HAIR TECHNOLOGY
IN THE RUBY DEMO
35 | 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 shaders
Very flexible to allow for different hair styles and different conditions
36 | 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
37 | Project Phoenix | March 27, 2013
Anti-Aliasing
+ Volume Shadows
+ Transparency
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 highlights
Primary light colored highlight shifted towards the tip
Secondary hair colored highlight shifted towards the root
38 | 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
39 | Project Phoenix | March 27, 2013
RUBY HAIR RENDERING | TressFX Self Shadowing
Self Shadowing
– Uses a simplified Deep Shadow Map technique
No Self Shadows
40 | Project Phoenix | March 27, 2013
With Self Shadows
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
41 | Project Phoenix | March 27, 2013
With Transparency
TressFX HAIR SIMULATION
IN THE RUBY DEMO
42 | Project Phoenix | March 27, 2013
RUBY HAIR SIMULATION | TressFX Physics Simulation
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
43 | Project Phoenix | March 27, 2013
RUBY HAIR SIMULATION | TressFX Physics Simulation
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

 = 0 ∙ 01 … ∙
−2
−1 ∙ −1
We find goal positions using local/global transforms for each
vertex and update vertex position by interpolating it using
stiffness value.
44 | Project Phoenix | March 27, 2013
RUBY HAIR SIMULATION | TressFX Physics Simulation

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
dry
45 | Project Phoenix | March 27, 2013
wet
REFERENCES
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.
46 | Project Phoenix | March 27, 2013
ADDITIONAL REFERENCES
 . Hayward, K, "Reflections with Billboard Imposters", http://graphicsrunner.blogspot.de/2008/04/reflectionswith-billboard-impostors.html
 . Huang, X. "Think DirectX11 Tessellation! Lots of Options", GDC 2010 (link: http://www.microsoft.com/enus/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-cubemapenvironment-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
47 | Project Phoenix | March 27, 2013
QUESTIONS?
For follow-up questions, email:
[email protected]
[email protected]
[email protected]
48 | Project Phoenix | March 27, 2013
Disclaimer & Attribution
The 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.
49 | 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.
50 | Project Phoenix | March 27, 2013

similar documents