BRINK: Multi-core support and better scaling on the PC
When Brink was announced at the E3 many people were surprised by the targets the developers at Splash Damage, the creators of Enemy Territory: Quake Wars, set for their new project.
At the E3 2009 in Los Angeles Splash Damage announced their new action game Brink. The information that has been revealed up to now is quite interesting and the first screenshots make gamers hungry for more. Now PC Games Hardware had a chance to interview Splash Damage's Technical Director, Arnout van Meer, who had already had this position during the development of Enemy Territory: Quake Wars. As usual our questions focused on the technical aspects of the game and the engine which it is based on. Currently a more exact release date than Spring 2010 is not available, but the available Brink footage is worth-seeing.
PCGH: Did you develop your own engine for BRINK or did you license a technology? What were the reasons for developing your own technology/using middleware? What are the advantages when utilizing your own technology/a commercial product?
Arnout: BRINK's technology started out as the version of id Tech 4 developed by us for Enemy Territory: QUAKE Wars. We've since upgraded major parts of the technology and it now runs on PC, Xbox 360 and PS3 from the same codebase and tries to share as many assets as possible between those platforms. As part of this process, the renderer has been revamped to be friendlier for consoles and modern graphics cards. Multi-threading is also more important, both for the asymmetric architecture of the PS3 as well as for the more symmetrical PC and Xbox 360. We are parallelising more and more areas of our code to try and utilise all the available hardware resources.
Aside from the core technology, an entirely new toolset with tighter integration into the engine was written to aid development. It contains heavily updated versions of tools people might be familiar with, such as our level editor EditWorld, as well as entirely new animation and scripting functionality.
There are many benefits on staying with already familiar technology. Being able to start on day one without re-training people is a big plus. The engine has also proven itself by being used in several shipped games, with the added bonus of us knowing exactly what its strengths and weaknesses are.
PCGH: You announced that BRINK will be released for the Xbox 360 and PS3 too. Can we speak of a pure cross platform development or do you heavily adjust your base technology for each platform?
Arnout: BRINK is being developed as a fully cross-platform game. We try to share as much code and as many assets as possible between the platforms. During work on our previous games we already had a solid understanding of doing cross-OS development and this experience partially translated over to working with multiple hardware platforms in writing portable code.
For example, we have developed a job system for BRINK, which can be used to offload code to the SPEs of the PS3 or to the various hardware threads available on the PC or Xbox 360. We also know what the strengths of each of the platforms are and we make sure that all of them receive the attention they need in order to fully utilise them. We don't want any of them to feel like they are ‘just a port'.
PCGH: If you develop special PC build of BRINK, what are your reasons to do so? What technical features can only be realized with the PC as platform? What are the main differences between the console and the PC version as far as general technical aspects as well as the visuals is concerned?
Arnout: Our main goal is to make sure we have a great game on all of the platforms. This includes the PC, which will get special attention to be able to benefit from, for example, the more customisable input features a mouse and keyboard offer.
Because we are writing a single game, there won't be many visual differences on the various platforms to ensure the artists can concentrate on creating good art, rather than on tweaking it. That said, the PC version will be more scalable and will be able to make use of more powerful hardware if available. There are various areas where we provide extra features you can enable to show your über-PC off to your mates.
On the hosting end, dedicated servers have always been a strong backbone of any multiplayer PC shooter and we will be offering these for people to host themselves.
PCGH: It seems that a detailed visual presentation is very important for BRINK. What would you mention, when asked about modern rendering techniques that are utilized in BRINK besides Virtual Texturing? Can you please give some practical examples (you're welcome to use very technical terms)?
Arnout: Besides the already mentioned Virtual Texturing, we have moved over from shadow volumes to shadow buffers. While shadow volumes still have their place and some of their properties are still preferable, the overall look of the game benefits from having the smoother look of blurry shadows as a result of shadow buffers. Our artists definitely agree with this.
The engine features a powerful material and shader system allowing us to have many varying ways of rendering surfaces. Parallax mapping, anisotropic lighting and various other techniques are also used to create the look desired for the game.
We have spent some time making sure our whole rendering pipeline is gamma-correct as well. All our lighting calculations are done correctly in linear colour space, resulting in a much more predictable output. One of the areas where this is most noticeable is on lighter surfaces, where we no longer get undesirable highlights.
As graphics hardware gets more powerful, it allows us to do more and more effects through post processing. A wide range of techniques is available to us here, such as motion blur and depth of field.
PCGH: By now multi core CPUs are very popular and the numbers of players with such machines is rapidly increasing. Did you integrate multi-core support into the engine from the beginning?
a) If yes how many core are supported and what is the expected performance gain from 2, 4 or even 8 cores?
b) What different systems run in separate threads?
c) Does your engine profit from SMT/Hyperthreading or do you recommend to turn it off for maximum performance?
Arnout: Our goal for BRINK is to ensure as much code as possible is executing in parallel. All our target platforms have multiple cores, both symmetrical and asymmetrical. The job system we have created makes it possible to scale to any amount of cores we desire; the system's scheduler just divides the load. Physical hardware threads are always preferred, but we have seen benefits from logical cores in the past. We still have to make sure that all supported systems can play the core game so we can't scale too much in that area, but more available hardware threads will improve performance as well as offer the potential for more complex auxiliary operations.
There are a wide range of systems that we are looking at turning into jobs, like the always popular particle simulations, but also animation blending, mesh skinning, texture compression, culling, asynchronous memory copy operations, etc. The more code we find to move over to our job system, the better our technology will scale.
PCGH: Will BRINK have a special physics simulation?
a) If yes: Does it affect visuals only or is it used for gameplay terms like enemies getting hit by shattered bits of blown-away walls and the like?
b) Did you program your own physics engine or do you utilize a middleware? Does the game even support hardware accelerated physics calculated on the GPU (via PhysX, OpenCL or even DX Compute)?
c) If no: Why did you decide against it? Does it not improve the game experience or is the available middleware like Physx, Havok or ODEM not suited to your particular needs?
Arnout: The physics system in BRINK has been redesigned to be able to run operations in parallel as well as have a more correct simulation when multiple objects are interacting together all at once.
When you have several people playing together, it is important to ensure that physics simulation is consistent for every single one of them. On this front, we benefit greatly from having full control over our proprietary and tightly integrated code, which allows us to easier replicate the simulation over the network, as well as have better error correction.
All of our physics code is executed on the CPU. While GPGPU techniques are very popular nowadays for physics simulations, this code is currently still hard to share across various platforms or even hardware vendors. However, APIs such as OpenCL are definitely improving the options here and it will become an interesting area of research in the future.
PCGH: Does BRINK still support Windows XP? If yes: When do you think game development will be at a juncture where it's more viable to put all the effort into one rendering-path using only DirectX 11 (with downlevel-paths) and drop support for XP?
Arnout: Windows XP is still a very popular operating system so it doesn't make any sense for us to not support it. Being an OpenGL game it is arguably easier for us to still support this platform while making use of newer hardware features - all it needs is a new extension to be exposed by the driver and it can be used on any of the supported operating systems.
Rather than worrying too much about API transitions, we tend to focus on hardware capability transitions. For example, since geometry shaders are not available on all cards, we would have to split our rendering pipeline to support these down one branch. But since we only split for this newly developed hardware feature, the more standard resource management for textures, geometry data, etc does not have to be reworked at all.
PCGH: Will BRINK offer a support for Direct X 11?
a) If no: What are the reasons to do without? Are there any existing plans to patch in support for DX11 later?
b) If yes:
• What was or were the deciding technical advantages of the DX11 API/Shader Modell 5?
• In what way does it allow you to optimize or simplify the rendering process in your game?
• From what DX11-feature do you think your games profits most?
• Do you use DX11-Multithreading to lighten the load on the CPU?
• Will the DX 11 visualization differ substantially from the graphics that are rendered with DX 10(.1) hardware or will DX11 just speed up the rendering process?
• If there are special DX11 visuals, what are the graphical features that can only be rendered with shader model 5 hardware?
Arnout: Being an OpenGL game the situation is a bit different for us. We look at new hardware coming out and see if there are any features we can make use of. API- only changes, such as the move to per-thread render contexts, don't apply to us at all. Interestingly enough we are running per-thread GPU context internally in our renderer for the consoles and might well apply this to the PC platform too.
DirectX 11 class hardware does offer several features that will become very interesting to use in the future. Finally being able to do correct per-sample operations will make correct MSAA doable for deferred techniques. Tessellation is also an appealing avenue for the artists to use as it can greatly improve the quality of rendered art. It does require custom-made art though, making it hard to warrant the investment until it is available on all platforms.
Finally, with Intel's Larrabee being on the horizon it is good to remember that the more traditional design of DirectX 11 might well have some big competition in the near future. Interesting times indeed.