Tech Focus: Crysis 2 and the future of CryEngine 3

Q: There's a rumour that you were showing a Crysis 1 prototype on Xbox 360 behind closed doors as far back as GDC 2008 - a year before you went public with CryEngine 3. Is this fact or fiction?

Cevat Yerli: I think that was 2009 and what we were showing back then was a CryEngine 3 tech demo. In this demo there was a section with a tropical island we partially generated with existing Crysis 1 assets. In 2008 we were working with consoles already but I can't remember us showing something at GDC.

Q: Surely with CE3 at your fingertips and all the Crysis 1/Warhead assets at your disposal, a console Crysis collection would have been an easier - and certainly cheaper - project? Why make the jump to Crysis 2?

Cevat Yerli: We wanted to move on to our next game and come up with a fresh setting to further develop the Crysis franchise. A port to consoles wouldn't have been easier or cheaper necessarily and we always want to innovate and thus offer improved and refined gaming experiences.

Q: The move from wide-open spaces to the more linear cityscapes of Crysis 2 must surely have performance benefits in its own right. How much was the change in location down to technological issues in having to deal with the limitations of console architecture?

Tiago Sousa: It was a game design choice to move away from jungles which we have been doing for almost ten years. This decision was completely unrelated to any technological issues. But from a technical perspective it was a nice change to go out of our comfort zone.

Q: Crysis 2 is in stores now has already proven to be a commercial success, but there is still a level of controversy concerning the PC version of the game. Do you feel that your approach in targeting consoles has been vindicated now the game has shipped?

Cevat Yerli: Yes, absolutely. I think we have achieved what we aimed for - the best Crytek game yet on all major platforms.

Q: Do you feel that the issue of piracy on PC can ever be successfully tackled or is the cross-platform approach the only way to justify a AAA game budget?

Tiago Sousa: We could not have created a game with the scope, scale, and multiplayer features of Crysis 2 if it were a PC only title. The PC market just does not support that cost of development, but going multiplatform does.

If making a game that is bigger, better, more stable, performs better across a wider range of hardware, provides a continued visual benchmark for PC gaming, and more fun with a huge singleplayer and multiplayer offering is considered selling out, that seems like a really odd application of the phrase. The decision to go multiplatform has allowed us to bring a better game to everyone, which has been our goal all along.

Q: Can you give us some background on your initial R&D work on Xbox 360 and PlayStation 3? What was your first assessment of the technology?

Tiago Sousa: It was a giant task, extremely challenging, and a very, very long process. At least speaking from my own point of view, my first impression was that this was going to be our biggest challenge ever. How the hell are we going to make a Crysis game running on five-year-old hardware, and to top that, do it for all platforms? Most developers tend to go the easier route, and focus on a single platform - but Cevat wanted our first multiplatform engine/game, to ship simultaneously on all platforms.

There's a reason why most developers focus on a single platform only: although high quality multiplatform gaming is definitely doable, it's extremely hard and time consuming, especially for the first technology iteration. We started by first "making it work": step-by-step adding all the missing core functionalities on consoles, doing straight forward ports of all PC features.

We then started to "make it right and make it fast": when all basic functionality was in place, it was clear that a massive amount of low level optimisation and re-factoring would be required across the entire project. The best example (or worst depending on your perspective) from GPU performance side: the straight port of our old post processing was taking around 30ms, and HDR post processing took an additional 10ms. On the current CryEngine3 iteration for both together, it is around 5ms on consoles, which is almost ten times faster.

Q: Were you struck by any significant strengths or weaknesses of any platform? Did any technology in the consoles excite you with possibilities?

Tiago Sousa: When you spend many years working on cutting edge PC technology, it's difficult to get very excited with console platform tech, but it was definitely an exciting challenge for the graphics team to push the console hardware to its limits.

GPU side, when programmed properly, they are fairly similar. We just have to be conscious of the clear handicap on PS3 RSX in terms of vertex processing, but other than that, on fragment processing side they are relatively similar, both have their strengths but such differences become irrelevant in the long run, especially when compared to PC platforms.

My finger pointing at Microsoft/Sony would really be on the memory side; it's way too low, and the biggest crippling factor from a visual perspective. I would really like to see next gen console platforms with a minimum of 8GB.

My highest praise goes to the amazing work they did for their performance profilers, with Xbox 360 PIX and PS3's GPAD, the PC industry has a lot to learn from such tools. I think it's great to see NVIDIA's NSight trying to raise the bar once again on this area.

Both platforms also benefit greatly from their vast documentation and support.

Q: How much commonality is there between CE2 and CE3 in terms of overall functionality and base code?

Tiago Sousa: From a graphics perspective, most functionality had to be generalised both for performance and for workflow efficiency. It was not possible at all for our old technology to run out of the box on consoles, and it was definitely not efficient time/QA-wise to have a team of programmers doing a feature for platform X and then doing the same feature for platform Y, and platform Z.

So the right approach for us was to generalise and optimise as much as possible and only go per-platform specific when it really gave a big bang for buck in performance or memory gain. Such a generalised approach also went for the graphics feature set; every platform supports all base graphics features. I believe such an approach is likely to become the standard for multiplatform titles that wish to maintain a high quality bar across all platforms.

Q: The consoles are weak on RAM, but relatively stronger on multi-core capabilities. Benchmarks of Crysis 1 suggested you supported dual core architecture, but quads gained little advantage. What can you tell us about the new approach in CryEngine 3?

Michael Glück: The PS3 required a different approach than the 360: lots of tasks need to be spawned to run on the SPUs whereas on Xenon you have three cores with each two hardware threads. Therefore we re-factored the computational intensive parts to run as tasks or as threads capable of spawning many tasks. We also implemented special tricks like fibres to run two threads extremely efficient on a single hardware thread. The PC gained scalability from that as well, running on quad core is much more efficient than on a dual core. But in the near future the engine will be even more task oriented to scale on arbitrary core numbers.

Q: What are the specific differences between your approach to multi-core processing between the Xbox 360 and PS3 versions of CryEngine 3?

Michael Glück: Xbox 360 can run six hardware threads whereas PS3 has only two hardware threads but six SPUs. If you write an engine from scratch you would establish a task pool sitting on top of five or six hardware threads and design all parts to run as tasks. But coming from a sequentially designed engine we required an incremental approach. Therefore we took three steps:

1. We re-factored the major parts into more and more coarse grained threads. This way it runs asynchronously and can be put onto one hardware thread on Xbox 360 right away.

2. We then refactored the coarse grained threads into task based processing.

3. We ported those onto SPU.

For physics for example we took a hybrid approach of embedding a coarse thread as a fibre into the main thread on the same hardware thread and it spawns tasks onto SPU.

Overall the Xbox 360 was very similar to PC multi-core architecture and easy to port. PS3 required a different approach and additional effort.

Also the PowerPC architecture missing out of order instruction processing, required changing the way we wrote code and required a significant effort to rewrite the hot spots.

Q: Sony first party developers address the disadvantages of the RSX chip by adopting SPUs as VFX co-processors and also for culling unseen polygons. From documents available online it seems your approach is quite different... why?

Michael Glück: The SPUs do indeed allow to ease the workload for the RSX. We decided not to go too crazy in this direction as it requires render targets and assets to reside in main memory. We are able to run skinning for example on SPUs as well, but we could not afford the additional memory required in the end.

It is possible to use the SPUs to support deferred shading, run post process effects and do triangle culling. But again, it all requires main memory we did not have as our levels are fairly large compared to other games and our SPUs were in fact pretty loaded with particles, animations, physics, low level rendering and culling already.

Q: You went with 1152x720 and 1024x720 resolutions on Crysis 2 on 360 and PS3 respectively. Can you discuss your reasoning here? There's also a note in your config files that the resolution drop saves 14MB of RAM on PlayStation 3 - how is this possible?

Tiago Sousa: The 1152x720 resolution on 360, simply allows you to maximise eDRAM usage on a deferred lighting engine without having to resort to tiled rendering.

On the PS3, due to the extremely limited system memory we resorted to downloading memory into video memory. We bumped into severe video memory limitations, so it was a good compromise to save a big chunk of video memory for other usages. Plus, while on consoles we are CPU bound during combat due to physics, AI, etc, on less intensive situations on the PS3 we are GPU bound, so the additional quick ten per cent performance gain was also very welcome.

Q: To what level do the console optimisations you've made benefit the PC version of the game? Crysis 2 manages to perform superbly, even on old hardware like the 8800GT.

Tiago Sousa: We learned a lot with the consoles, especially how to make smarter and efficient usage of scarce rendering resources. In Crysis 1 times, our attitude was, "oh what the heck, what's one more additional full resolution FP16 target or a couple of full screen passes, let's just add it" - you can't take such a naive approach for consoles. We could have gone the easy way and simply disabled features for consoles and lower specs machines, but this time around we wanted everyone to experience our game in the best possible way their favourite system allows. We spent a huge amount of time refactoring, optimising and balancing our rendering pipeline in order to maximise GPU performance for every system.

Q: There's an argument that some of the strengths of CryEngine 3 are invisible to the end-user, but hugely relevant to the game developer - real-time preview cross-platform, for example. What are the other major advantages of CE3 and how did they make Crysis 2 become a better game?

Tiago Sousa: From a graphics programming perspective, firstly we switched to a gamma correct HDR rendering, which is the main reason our final lighting result looks so good on every single platform. Then the lighting system was completely revamped; there was simply no way to achieve same results (at interactive frame rates) with CE2, especially at HD resolutions. We can have many, many more light sources in a scene; we also introduced deferred cube map probes, meaning we can now literally have every surface with HDR reflections. This is something we never had in CE2 and finally introduced for CE3.

Besides a lot of other significant changes, the aforementioned developments are the main reasons for an increased speed in workflow from an art developer perspective - art doesn't have to care much with texture/lighting/ fog/etc precision issues like in old school LDR rendering engines, or spend time pre-baking lighting at all.

Q: Can we resolve the issue of how real-time global illumination is implemented cross-platform? The impression we had pre-release was that it would be deployed across all SKUs, but Crysis 2 suggests it is a high-end PC feature only. What's the story here?

Tiago Sousa: Our innovative real-time GI solution was not fully complete/robust on consoles yet, it still had visible issues/artefacts which we ran out of time to address. Due to this, also on consoles all milliseconds and memory counts, so at end of this project we made the tough decision to disable it for consoles. We still have a very simple and coarse GI approximation on consoles, where our art department fully controls the look, meaning we pay couple of ms on areas where it is actually making a significant visual contribution.

Q: What's the future for the GI solution? Is it ever likely to attain some of its promise on the current consoles, or are you waiting for next-gen to really shine?

Tiago Sousa: We have plans to optimise and extend our GI solution further but also to improve it, to make it more of a general solution, not just for sunlight.

Q: Let's talk about the anti-aliasing solution you employ. You don't want it to be labelled temporal AA, but reprojection is certainly a key element and ghosting is certainly an issue common to TAA and your approach. Factoring out the edge-detect component for a moment, why shouldn't we call your technique temporal AA?

Tiago Sousa: If we want to be technically accurate, TAA is actually what is commonly known as Motion Blur. But TAA in gamer language is the naive denomination for the simplest form of amortisation of super sampling cost: a simple linear blending between current and previous frames sub-samples and which looks very similar to the old school cheap "motion blur" trick seen in many older games.

There is no re-projection involved. At 60FPS or more, this is ok and not easily perceptible, but it's not really useable for 30FPS or lower. PostMSAA 1.0 relies on previous frames re-projection and it's prone to artefacts when there are un-occluded pixels, most noticeable when camera is panning fast.

Although both techniques rely on amortising cost across frames, the end result and implementation is quite different.

Q: What are the performance advantages of PostMSAA compared to the alternatives? Did you stack up the solution against alternatives like traditional MSAA, MLAA and even Microsoft's own XDK edge/detect blur component?

Tiago Sousa: MLAA costs around 3.5 ms on current consoles GPUs and still lacks subpixel accuracy like any other post processed approach. The Microsoft XDK edge blur solution is not useable at all on real world scenarios - except for a relatively graphically limited game.

MSAA, besides additional memory requirements, is not supported by PS3 hardware at all on alpha blended surfaces when rendering in HDR, like we do on CryEngine 3. And more globally it doesn't support alpha tested surfaces, without relying on ATOC, performs 0 shader anti-aliasing, plus final resolve needs to be done before tone mapping, which leads to incorrect results in high-contrast areas.

With PostMSAA 1.0, although this shipped version was far from perfect, all previous drawbacks are addressed and the cost was 1ms on console hardware, while on PC hardware the cost was irrelevant, in order of 0.2 ms at 1080p.

I believe in future, for the current console hardware generation we'll be seeing improved hybrids of our approach, allowing subpixel accuracy, with faster post processed techniques. NVIDIA's FXAA 2 for example looks quite promising and from what I've seen, was already 2x faster than MLAA.

Q: Bearing in mind the additional power available, why stick to PostMSAA with no choice of alternatives in the PC version?

Tiago Sousa: PC DX9 version shipped with PostMSAA 1.0, plus enabled NVIDIA's FXAA 1 for extreme specs. DX11 will feature our next step in this area.

Q: Can you describe the relationship between the main studio and Crytek UK in developing Crysis 2? Is the multiplayer component effectively a separate game developed external to the single-player campaign? What are the commonalities between the two game modes and where could the UK team go off in their own direction?

Cevat Yerli: Crytek UK was working on the multiplayer part of Crysis 2 quite autonomously, however, we had to make sure it fits the overall game world and the Nano Suit experience. Direction and project leadership were coming from the main studio. Overall I think it was a collaborative, creative process where new ideas and features got exchanged between both studios for both the single and multiplayer part of the game.

Q: You recently released a CryEngine 3 trailer aimed at the motion picture business. What can the engine offer the movie biz and where would you expect to see it utilised?

Carl Jones: CryEngine3 Sandbox for Cinema is a new version of our engine and it's actually being built in response to demand from the movie industry for us to make CryEngine more accessible to them.

I think the speed, quality and power of the CryENGINE renderer was the first thing that appealed to the film makers, but in speaking with them, we've discovered that so many of the advances we have made in real-time production for games over the last ten years, really apply to the movie industry in a big way.

So we're honing the tools, adding in some features that will help film makers and improve game cinematics and animation quality. The potential use of the engine is very broad and we're not closing any doors at this early stage; so while game graphics aren't quite good enough for a full scale movie production (yet!), there are many ways that CryEngine can save time, money and increase quality in the film and TV production. That's a powerful combination and we're being inundated with interest in the tools from all over the world.

Q: Is there any interest from non-game companies in things like fast architectural previews?

Carl Jones: Similarly to the film industry - real-time, interactive graphics can benefit almost any industry or production.

An obvious group are architects - being able to explore their designs, not just fly through them in pre-rendered CG. With CryEngine Sandbox real-time tools as well, you can change your designs instantly, as you are experiencing them - this is nothing new for CryEngine game developers, but it is a sea-change for architects and their customers.

Imagine buying a car, shopping online, or having some construction or decoration work done and being able to experience what you will be buying, and even request changes to it, in real-time. You'd get more choice, better value for money and it'd be fun! It's the future!

Q: CryEngine 3 is "next gen ready". Can you tell us exactly what that means? How quickly do you envisage CE3 being ready for a next gen console once the dev kits are out there?

Carl Jones: We've been considering the next generation and what it will likely consist of for many years now, so everything we did in CryEngine 3 has been with an eye on future hardware architectures.

Some recently advertised "next-gen" features in other middleware are running in an unplayable tech demo on a supercomputer. But a bunch of these same features are available right now, in the current generation, in Crysis 2!

We've been waiting for the next generation of consoles since we released Crysis 1, as the high end PC features we invented back then will be pretty standard on next gen consoles, we believe. Developers can work with CryEngine 3 right now, running real-time GI, sub-surface scattering, movie quality camera effects, etc. in vast worlds with extreme complexity and be confident that the technology they are working with will be scalable to the next generation.

Q: What's the future for CryEngine 3? Are you hoping to develop it significantly over the current generation, and how much room do you see for CE3 improvement on the current consoles?

Tiago Sousa: I think we already tapped a large part of the consoles' resources and hardware potential. But there is still quite some potential to push it further, especially from art side, since it was their first game with this engine iteration. I'm quite confident they will learn to push our engine to its limits by carefully using their resources. From the tech side we will of course keep optimising and improving further, there is no such thing as the best optimisation/approach, performance and quality is always a moving target.

There were also some areas we wanted to push further, for example minimising memory transfers, but we just lacked the time to make it happen.

Q: You've already licensed CE3 externally - what kind of valuable feedback have you had from developers using your tech and has this led to any direct improvements in the features and performance of the engine?

Carl Jones: We're always improving the engine - we never stop! But we've certainly been working with our licensees to make our engine easier to modify at all levels, we've been supplying more and more samples for developers to get a head start at the beginning of their projects. We've now got really great documentation, which was certainly a weakness a few years ago. All of this is based on us listening to our licensees and ensuring we focus on delivering what they need as quickly as possible.

Q: What is your view of Cloud gameplay streaming and now that OnLive has been active for a while, and can you go into more detail on how you would approach using this tech?

Cevat Yerli: As I mentioned in the past already I'm convinced that Cloud gameplay streaming certainly CAN rule the future gaming market IF applied correctly. I think current applications are pointing in the right direction but still need some major adjustments. In general cloud gameplay streaming needs to become a more user friendly and commercially viable solution in order to appeal to the mass market.

Q: In your presentations, you seem to be targeting 2012 for the arrival of next gen architecture. Is this still your target or have the goal posts shifted since you gave that talk?

Cevat Yerli: I still believe that we'll see a wave of next-gen platforms in 2012 and 2013 (not all at once though!)

Q: PC GPUs are already orders of magnitude more powerful than the hardware found in the consoles. When we shift to a new console generation, will we see current PC GPU power being utilised more effectively? Shouldn't that already be happening with DX11?

Tiago Sousa: What the user sees is merely the end result of additional GPU power together with much more memory available. Which API it comes from, doesn't really matter.

I'm a strong believer that we should already be at Avatar quality in real-time, but the mass market (not everyone has the highest end cards or cpus for example) is significantly delaying this next step. The transition to a new console generation that is far less memory-bound, will allow for less painful QA/maintenance of PC assets versus console assets from an art perspective. Ideally, you want to have the same asset everywhere and not have artists making custom assets, or even levels, for specific platforms.