Tech Focus: Crysis 2 and the future of CryEngine 3

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.

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.

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.

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.

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.

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.

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.