How it Works: TressFX and its Extrapolated Capabilities for Other Graphics Tech
For some indescribable reason, AMD's TressFX announcement came without any videos or tech demos, so we haven't actually seen the physics components (easily the most impressive) in action, but we still know a bit about how it works.
First-and-foremost: TressFX operates on the DirectCompute API for graphics programming rather than some proprietary solution, meaning it will be universally scalable to competing products (read: nVidia). This is a common theme for AMD, who seem to advocate that most of their developed graphics technologies should be in the open for cross-platform use; this is also highlighted in their order-independent transparency tech, which overhauled semi-transparent object rendering on the HD 5000 series GPUs and serves as a foundation for TressFX. HDAO (Ambient Occlusion) is another example, though nVidia uses its own HBAO solution, AMD's HDAO will operate on IGPs, APUs, and discrete chips from most manufacturers.
The objective here is to be widely supported by the game development community. We've seen a famous lack of optimization using nVidia's proprietary PhysX hardware solution for physics processing, perhaps with exception granted to a few premiere games (often that received funding, testing, and dev support from nVidia), and this is attributable to its relatively closed accessibility. AMD's approach to open tech is one we can agree with, especially as the world shifts more heavily toward open platforms in effort to jointly advance technology across the board.
TressFX will be available on all chips and should theoretically just be another 'tick' on the graphics settings page - enabled or disabled. TressFX does require Dx11 compatible cards, though we would like to see an official statement on how OpenGL factors in, if at all.
TressFX is driven heavily by raw DirectCompute performance as it is exceptionally intensive computationally, meaning users of GCN (Graphics Core Next) GPUs from AMD will have the best ability to run TressFX without a large performance hit. The reason for this computational power requirement is based in the tech's focus on recreating real-world physics interactions within thousands of individually-drawn strands of hair. If things work out like we've been told, the hair should have full collision detection and appropriate reactions, programmable responses to weather (dry, wet, wind), and response to gravity and unique physics situations (falling down, getting hit, jumping). As AMD continues to find itself inside of consoles -- to include the PS4, impending Xbox, and most Steam Box options -- we suspect more widespread adoption of their developed graphics rendering technologies.
It's easy to dismiss TressFX as somehow "lesser" than other visual effects and downplay its significance, but it's a very important stepping stone in the computing world's forward progression in gaming. The ability to compute and track thousands of strands of hair without consuming all of the card's resources has strong implications for the likes of environmental graphics and other soft-body elements. Cloth movement and collision could also be revolutionized by tech built out of TressFX -- something we've been dying to see in games that involve quick movements and highly-active characters (see: Mirror's Edge). Dynamic grass in MMOs, for instance, is another such item that has been widely requested in the wake of TressFX. Tree/leaf physics and shrub/plant rendering could also build upon the tech used for hair, which would offer a move away from pre-baked tricks and simplistic physics dynamism used in most modern games.
This is further perpetuated by TressFX's support of surface deformity when hair comes in contact with objects, like the character's own shoulders or hats/hoods. All of this feeds into other forthcoming rendering techniques. We've got the power to render high-poly models -- now we can focus on some of the finer details.
The official, PR-heavy announcement can be found here.
- Steve "Lelldorianx" Burke.