New Graphics

This page is a collection of all Dev Blogs made for the new graphics engine update (currently in Beta).

First Dev Blog Post for the Graphics Engine Update (10/21/16)
Over the years, we have focused on bringing you new maps and fun gameplay-based updates, but we have left much of the core engine untouched. However, after conducting on-site meetings with our existing players, hosting on-site focus group tests, and listening to the community's outspoken desire for an engine update, we have decided to initiate a project that would significantly improve the game's graphics capabilities. Since Combat Arms’ release in 2007, there have been many advances in graphics hardware and sophisticated techniques for real-time rendering. We have decided to update the original LithTech Jupiter engine to support advanced graphical features comparable to those of other modern game engines, such as Unreal Engine 4 and CryEngine 3.

We have decided to primarily modify the rendering layer so that the game would be able to take advantage of modern graphics hardware capabilities. The player would be able to choose to play using the original LithTech Jupiter engine or the updated one. The underlying physics engine, network code, and collision system are not affected, and the game would allow players with different graphics settings to play on the same server. There were many interesting technical challenges to support this requirement, and we'll share some of them with you in future posts.

[Insert YT Link]

Below are some of the major features we have implemented for the graphics improvement project.

Shader-Based Rendering Pipeline
The current engine is based on a Fixed-Function pipeline with Forward Rendering, and we have implemented a Shader-Based pipeline with Deferred Rendering to allow efficiently implementing realistic lighting models. Deferred Rendering allows the engine to implement significant screen-space effects, such as Screen Space Ambient Occlusion (SSAO) and Screen Space Reflection (SSR).

[Insert Gallery (#1 - 7)]

Physically Based Rendering (PBR)
Adopting Physically Based Rendering (PBR) allows the engine to render objects realistically and consistently in a unified manner by more accurately calculating the properties of light. It also allows the artists to easily create 3D assets that look great in every lighting situation.

[Insert Gallery (#8-9)]

Higher Quality Lightmaps with Global Illumination
We've implemented a solution to vastly improve the quality of the generated lightmaps. More information is now pre-computed, including indirect lighting, high resolution shadows, and radiosity normal map information. This allows for advanced Global Illumination techniques that vastly improve the quality of the rendered scene.

[Insert Gallery (#10-11)]

Modern Shaders
We've implemented various modern shaders, such as realistic water and glass.

[Insert Gallery (#12-15)]

Post-Process Effects
We've implemented various post-process effects to improve the rendering quality. Bloom, motion blur, and various other post-process effects add a lot of depth to the rendered scene.

[Insert Gallery (#16-17)]

Fourth Dev Blog Post: New Graphics Features in Combat Arms (11/11/16)
With the first Dev Blog post for the Graphics Engine Update, we briefly went over some of the new graphics features being added to the game. Even making the bold claim that some of these graphics features would be comparable to those from other modern graphics engines like Unity 5, Unreal 4, or CryEngine 3. But what does that actually mean? First of all, initially on release we want to make very clear that this will be a gradual release process and not all of the maps, characters, weapon texture, and model assets will be updated to take full advantage of all the new features right away. Most of these features will work with the existing Combat Arms assets, but they will need to be updated over time in order to give Combat Arms a truly modernized look and feel. It is worth mentioning that getting many of these graphics features to work in such an old engine, while at the same time keeping it backwards compatible with the old graphics engine and assets, took a lot of interesting and crazy hacks and workarounds, all while still being limited to what can be done with DirectX 9. It’s been a lot of fun!

Dynamic Lighting and Shadows
The original Lithtech Jupiter engine had limited support for dynamic lighting and shadows, though what the engine provided was fairly cutting edge for the era it was developed for. Basically in the original Lithtech Jupiter graphics engine, most lighting and shadowing was completely static, which means it is pre-computed and stored as a texture that is used when rendering the map’s geometry. However, static lights did allow some per-vertex lighting on dynamic objects in the scene, like character models and weapons. Because the dynamic lighting was per-vertex on objects, additional lighting details like bumps and normal on objects also had to be pre-computed and baked directly onto the diffuse textures. Because they were baked, they don’t interact dynamically with different light sources or fit in well with various different lighting conditions. This gave the scene a very flat and dated look for a game in 2016.

[Insert Gallery (2#1)]

Figure 1

The biggest feature we could only achieve with the new graphics pipeline was to allow both the static map geometry and objects to receive fully dynamic per-pixel lighting and shadows. Dynamic lighting can really bring a scene together with per-pixel lighting, specular highlights, dynamic shadows, and bump mapping.

[Insert Gallery (2#2)]

Figure 2

Though introducing a single dynamic light source initially was not that difficult to do, the challenge and complexity came from needing to support multiple dynamic light sources in an efficient way. Having support for multiple dynamic light sources has become a basic feature in pretty much every modern game engine. The only way the Lithtech engine natively supported rendering multiple dynamic light sources was to essentially re-render the entire scene multiple times; once for every light source in the map. This is sort of an exaggeration as the Lithtech is capable of clustering the map’s geometry in to blocks, and only the blocks of the map that could be effected by the light’s bounding sphere would need to be re-rendered, but it still puts a lot more strain on the CPU to render the scene multiple times and puts even more constraints on how complex the map geometry could be, and how many objects could be visible on the screen at a time. Initially we started with just allowing the main directional sunlight to be the only dynamic light source, and kept all the indoor omnidirectional lights and spot lights as static. But many of the maps in Combat Arms are indoors, or feature significant indoor areas and the quality difference between going from indoor static lighting to outdoor dynamic lighting was quite noticeable. So in order to do lighting from multiple light sources dynamically, a large change had to be done in how the engine renders the scene and handles lights. For this we employed a rendering technique known as Deferred Shading. The topic of Deferred Shading can be pretty in-depth and we casually mentioned it briefly in the first Graphics Update Dev Blog post. Basically, it allows all of the dynamic lighting to be done as a post-process rendering pass which is completely independent of the scene’s complexity and can be handled pretty much entirely by the GPU with very little CPU overhead.

[Insert Gallery (2#3)]

Figure 3

With these optimizations in place, we were able to implement a complex physically based lighting shader. We then benchmarked this lighting model by comparing it with how similar scenes would be rendered in other modern game engines, such as Unity 5 and Unreal 4, as well with fully ray traced scenes rendered using professional offline rendering software. We only limited it to what we could do in real-time with modern graphics hardware using advanced physically-based lighting shaders. The results are quite comparable with the ray traced render, the major differences being reflection accuracy and the lighting attenuation. Combat Arm’s New Dynamic Lighting Shaders:

[Insert Gallery (2#4)]

Figure 4 Ray traced version of the scene:

[Insert Gallery (2#5)]

Figure 5

Shadow Mapping
For Dynamic Shadows, there was a whole other set of challenges to get modern fully dynamic shadowing into Combat Arms. In the original Lithtech engine, most shadows are baked into the static lighting textures used when rendering the map’s geometry. This is why not all objects cast shadows, especially dynamic objects because the shadow is fixed and cannot be changed. Though Lithtech has a feature to enable dynamic shadows on specific objects, this feature was not heavily used by Combat Arms. Also this feature was very limited on where it can be used, and dynamic objects themselves are not able to receive shadows. We eventually settled on a solution that uses fully dynamic cascaded shadow maps (CSM for short) for the main directional light source from the sun, and a partially dynamic solution for omnidirectional lights and spot lights using a pre-computed omnidirectional shadow map that can be applied to both world geometry and dynamic objects. This is comparable to what other modern game engines provide for dynamic shadowing

[Insert Gallery (2#6)]

Figure 6

Also, what is Shadow Mapping? Shadow mapping is essentially a very clever trick that games and rendering software use to simulate dynamic shadowing with GPU acceleration. https://en.wikipedia.org/wiki/Shadow_mapping. The shadow mapping algorithm basically involves needing to render the scene from the perspective of the light source onto a texture, using that texture as input to the lighting pixel shader, and then using that texture to compute if a pixel is in shadow or not on the GPU. Think of it like taking a special depth-only camera and attaching it to an extremely long selfie stick pointing to yourself from the same direction of the light. Then basically, for each pixel on the screen, if that pixel is visible on the shadow map texture, it is in light, otherwise it is shadow. It is a pretty cool trick. Almost every modern game engine uses shadow mapping for shadowing.

shadowmapping📷irl

[Insert Gallery (2#7)]

Figure 7 (@ZoolanderMovie via Twitter)

In game, a shadow map texture actually looks like this:

[Insert Gallery (2#8)]

Figure 8

Notice how there are not 1, but 4 shadow maps on this texture. Each one of these shadow maps are called a Shadow Map Cascade. Depending on the distance of the surface from the viewer, a larger, yet lower resolution cascade is used. This allows the shadows to extend out very far, but still fit within a single fixed-sized texture, while still allowing shadows near to the viewer to be higher resolution. The resolution of the shadow map directly relates to how sharp and accurate the shadows can be. Since the shadow map is just another camera in the scene, the shadow map can be rendered dynamically in real-time. The newly added Shadow Quality settings will affect the resolution of the shadow map texture. Here is what a shadow map resolve pass along with shadow map filtering looks like.

[Insert Gallery (2#9)]

Figure 9

Shadow Map Filtering
Just using the shadow map by itself can lead to very hard shadows. While hard shadows can look pretty good on their own, it isn’t entirely realistic. In real life, shadows are not always hard or always soft, but vary depending on the size of the light. This can be seen these reference photos:

[Insert Gallery (2#10)]

Figure 10

[Insert Gallery (2#11)]

Figure 11

Notice how in these reference photos, shadows tend to get softer the further away the surface is from the object casting the shadows. Most other modern games still use a simple shadowing filter technique called Percentage Closer Filtering or PCF which applies a fixed amount of hardness or softness to all shadows.

[Insert Gallery (2#12)]

Figure 12 - Doom (2016)

[Insert Gallery (2#13)]

Figure 13 - Overwatch

These screen shots, taken from Doom and Overwatch respectively, show how most other games do simple shadow filtering using PCF. However, in Combat Arms we introduced a more advanced shadow filtering technique that is closer to how soft shadows look in real life. In-game we simulate this using a technique introduced by NVidia called Percentage Closer Soft Shadows. http://developer.download.nvidia.com/shaderlibrary/docs/shadow_PCSS.pdf Though this technique was presented way back in 2005, only now have graphics hardware become powerful enough to utilize this technique and modern commercial games have just recently started using it heavily for shadow map filtering. As of writing this blog, this feature is currently not available in Unreal 4 or Unity 5. Although, technically Unreal 4 provides an alternative feature called ray-traced distance field soft shadow feature, but it is limited to only allowing static geometry to cast shadows. PCSS Off:

[Insert Gallery (2#14)]

Figure 14

PCSS On:

[Insert Gallery (2#15)]

Figure 15

PCSS shadow filtering is enabled when using the higher Shadow Quality settings. Though currently PCSS is only used for the main directional sunlight at all quality levels. Unfortunately, PCSS is not compatible with hardware accelerated shadow filtering. DirectX 9’s Shader Model 3 doesn’t support Gather4 shader instructions, which are typically used in DirectX 10+/Shader Model 4+ pixel shaders for shadow map filtering. Due to the performance cost of PCSS using a Shader Model 3 pixel shader, dithered filtering, is used to reduce the GPU load.

Omnidirectional Shadow Mapping
For omnidirectional lights, things are a little bit more challenging. Since omnidirectional lights cast shadows in every direction, it is not as easy to render shadow maps for omnidirectional lights, as the scene needs to be rendered using some sort of 360 degree camera. This usually involves rendering the scene in multiple direction from the position of the light. However, it doesn’t scale well when there are many light sources. So for this, we settled with a pre-computed shadow map where the shadow map is computed only once when a map is loaded instead of every frame. A pre-computed shadow map can cast shadows onto dynamic objects in the scene, but dynamic objects within the scene will not cast shadows. To get around this, Lithtech’s native object shadow feature is used to give objects shadows from pre-computed omnidirectional shadow maps. We also combine this with Screen-Space Shadows Tracing to give objects detailed self-shadows and contact shadows. What is interesting is how the shadow map is used to project an omnidirectional shadow map into a single texture:

[Insert Gallery (2#16)]

Figure 16

This uses a full 360 projection technique known as Octahedron Spherical Parameterization, or sometimes known as Octahedron Mapping, where a sphere is mapped to a single texture based on its projection onto the faces of an octahedron.

[Insert Gallery (2#17)]

Figure 17

http://hhoppe.com/sphereparam.pdf http://www.vis.uni-stuttgart.de/~engelhts/paper/vmvOctaMaps.pdf Traditionally, omnidirectional shadow maps would use a cube-map, which requires at least 6 different textures to represent a full 360 omnidirectional shadow map, but using this map projection, only 1 texture is used. It also provides less distortion than most other spherical to 2D projection mapping techniques, and unlike an unwrapped cube-map, it fits perfectly within a single square texture. Many existing maps use a large amount of omnidirectional lights as the primary light sources, and this allows many lights to also support shadowing in real time.

[Insert Gallery (2#18)]

Figure 18

Wrapping Up
We believe that this combination of lighting and shadowing techniques bring 2016 modern graphics capabilities to Combat Arms and that these features also rival those found in other modern game engines. Though the features alone are not enough to make the game look like other 2016 games, many changes are yet to come to the artwork and assets that will take full advantage of the new features. There are still many more features added, this was just an in-depth look into the nitty-gritty technical details about the implementation dynamic lighting and shadowing into the upcoming Combat Arms Graphics Engine Update. Also, it is important to note that these screenshots are taken using a currently in-development build using some placeholder or sample assets for the purpose of demonstrating the graphics features. These may not accurately reflect the final update after its release. I must also reiterate that the updated graphics engine options are completely optional and you will be able to switch between engine versions after its release. We are developing these graphics features to target modern 2016 era mid- and high-end graphics hardware. We want the engine to be able to fully utilize the power of modern GPUs to give the best possible quality results. We are still continuously benchmarking and optimizing the new graphics features, but we anticipate that slightly older or lower end hardware should still be able to run the new graphics options with lowered settings or resolution. We are still committed to supporting the old graphics engine so that players with older or less powerful hardware, or those who just prefer the classic Combat Arms look and feel, will be able to continue to enjoy the game as they always have.

Sixth Dev Blog: Beta Feedback and Upcoming Improvements (12/07/16)
Hey Soldiers,

I have some news to share with all beta participants regarding the next upcoming Combat Arms Test client update. For this update we fixed an issue where maps would sometimes not load any textures. There has also been some minor performance optimizations, so we expect many players to see an average of about 5% increase in framerates. Also, there was a number of improvements made in direct response to player feedback that I would like to go over in detail. One of the most noticeable change is a noticeable the reduction in the color dithering. Dithering is an optimization technique used to increase the perceivable image quality without increasing memory cost or reducing performance. However, from feedback, many players found the dithering far too noticeable, especially in dimly lit indoor areas. After some adjustments and optimizations, I was able to squeeze in a few extra bits into the framebuffer texture used for precomputed light and global illumination. This reduced the need for as much dithering compared to before.

Dither before:

[Insert Gallery (3#1)]

Dither after:

[Insert Gallery (3#2)]

Some other general feedback we got was that outdoor areas seemed too bright. This has been improved by making some adjustments to how the HDR automatic exposure algorithm works so that it is more sensitive to bright areas on the screen. Also the range of HDR color has been slightly lowered so if automatic exposure is disabled, outdoor areas should be a little less brighter than before.

HDR before:

[Insert Gallery (3#3)]

HDR after:

[Insert Gallery (3#4)]

We also noticed from the feedback that many players were choosing the “Potato” lighting quality setting which switches the lighting model from GGX to a simple Lambert shading model with no specular lighting. It turns out that our PBR shader was not properly compensating for gamma correction on displays. This caused a grayish tint over that was a bit too intense in certain areas. This was very noticeable on monitors with a high gamma.

Specular before:

[Insert Gallery (3#5)]

Specular after:

[Insert Gallery (3#6)]

Some minor improvements were also made to the shadow map biasing which reduced some strange artifacts and light leakages in certain areas.

Shadows before:

[Insert Gallery (3#7)]

Shadows after:

[Insert Gallery (3#8)]

Some other minor optimizations have also been done to the rendering pipeline so certain configurations should notice a small increase in FPS of about 5%. I think there is always more room for more optimizations but the biggest detriment to performance that we have noticed from feedback was actually coming from the per-frame mouse input latency, and not so much from the performance itself.

Currently in Combat Arms, both with the new and the old graphics, there was always some additional frames of additional input latency due to how the Lithtech engine handles mouse input smoothing. Mouse input smoothing is handled in Lithtech by averaging the previous 3 frames of mouse input and weighting the average with the current frame to smoothening out the mouse look movement between frames.

This latency was not very noticeable before with the old graphics since even low end graphics hardware would get absurdly high framerates, typically over 300 FPS. With framerates so high and no vsync or framerate capping options, it was near harder to notice the latency introduced from a few extra frames and the smoothing had little effect. However, at lower framerates, the smoothing starts to become very noticeable. At even 60 FPS because about 3 extra frames of latency at 60 FPS is about 48 milliseconds of additional input latency which feels nearly unplayable.

Although I have been focusing exclusively on updating the graphics layer of the engine, with this new beta client update, the mouse smoothing has been removed. And the difference in mouse input latency with the new graphics is quite significant. It should feel much more responsive at 60 FPS. Using a very expensive and highly sophisticated slow motion recording apparatus (actually just my old iPhone), you can clearly see the amount of frame latency at 1/4th speed by comparing the timing of the movement of my hand with the look movement on screen. On the left you can see how much latency is introduced from the mouse smoothing. On the right, mouse smoothing is disabled.

Mouse Latency:

[Insert Gallery (3#9)]

We then noticed that it was actually the mouse smoothing implementation in Lithtech caused severe erratic mouse behavior with mice using a polling rate over 125 Hz. Here you can compare the results of having mouse smoothing disabled and setting the mouse polling rate to 1000 Hz on the right.

Mouse Polling Rate:

[Insert Gallery (3#10)]

I was happy to see that removing the smoothing also fixed this problem.

Keep in mind that with this update, mouse input sensitivity will be much different than before. You may need to adjust your mouse sensitivity settings with this new update. But you should now be able to use high polling rates with Combat Arms beta client in this update. This update will hopefully be released on Thursday, December 8th 2016. There will be definitely be more updates with further engine changes. Everything you see here is still a work in progress and likely to change based on more feedback.

Thanks!