Part 1: http://ftr.wot-news.com/2014/07/18/w...ient-analysis/ Hello everyone, Mr.Tiemo Jung is back with his analysis of the World of Tanks client. This time, he’ll be analyzing… Battle Mode Rendering (SS: the article is in its original form, I just fixed some typos) This part will cover the battle mode rendering. The rendering is very similar to the hangar mode, so I will mostly focus on the differences to the hangar mode. Data Streaming The engine is almost constantly streaming vertex, index and texture data. It is mostly parts of the map and objects on the map (houses, fences, etc). The streaming system suffers from the same resource management problems outlined in the hangar rendering part. They allocate the required memory at the beginning of each frame and copy the data into it, and use it some frames later. Allocating resources on each frame results in unpredictable frame timings and sometimes stutters, especially if the data source (disc where wot resides) is slow, the copy operation blocks all calls until it’s finished. There are numerous solutions to this problem -* resource pools, or keep all vertex data in gpu memory (vertex data is really small compared to textures, some kilobytes instead of many megabytes) and only stream texture data if needed. For texture streaming, especially for terrain, sparse virtual texturemapping or clipmaping is very appealing, but extensive to implement. General Observations I’m positively surprised by the usage of texture atlasing to store various sequences of special effects, like explosions and smoke. But they do not use this for all effects. They also use this for trees and bushes. For trees and bushes normal maps (fake surface depth) are loaded too. The engine copies textures manually from system pool (resides in ram for fast cpu access) to default pool (residence depends on usage, can be ram, agp region (if supported) or vram) to use static textures (resides in vram with a hint, that they never change), but after the upload from system pool to default pool, the no longer needed system pool texture are not always deleted, which wastes space in ram (it is possible they reuse them at some point, but this is hard to track down with that kind of logs I have to work with). Some very large textures only contain one color, which is a lot of wasted space. There also exist some duplicated textures, i would assume some artists just copy pasted some textures while they are reusing them. This is possibly a result of a limitation of their modeling/texturing software and/or model definition data formats. They should reference them instead to prevent duplicated textures. The first tank that gets loaded is your tank, in my case a Leopard 1 with camo pattern, 11 textures. Depending how much area a texture covers, its size goes from 512 by 512 to 2k by 2k, resulting in a memory consumption of just below 14 Megabytes. Other tanks are loaded with similar resolutions, resulting in a approximately 400 to 500 megabyte textures for all 30 tanks (assuming every tank participating is a different one). As we learned some time ago, 9.2 will use for non player tanks half sized textures (lod level 1), reducing the texture load per tank in half, this ‘optimisation’ will only help on graphics cards with low memory bandwidth and/or low amount of vram, but on such configurations you better not select max texture quality (cards with less than 1.5 Gigabyte of vram). HD Models use about 4 times the memory of a SD model, so up to 2 gigabytes only on tanks if all tanks are HD, with that in mind, the half sized textures make sense again. The new HD models have 2 display ‘modes’: HD with full res textures or SD with half res textures, they use a nifty trick to separate HD and SD textures, a HD texture is one texture lod level and the other SD versions are concatenated to the HD version, to make it a complete texture lod chain. With that trick it is possible to avoid downloading the HD version with an minimal effort, but they don’t give us the option in the launcher for updates yet. You can also judge which generation of content a model is done with, because there at least 3 (very old, updated and HD) different generations present with their own set of texture types and rendering techniques. At some point they switched from a old storage (just put it in a dxt1 texture) method of normal maps, to a more modern one (using dxt5 in a RGXA mode, this was firstly used by ID software in Doom 3) to reduce sampling artifacts. Camo rendering is very simple, they have small pattern texture that is multiplied with the camo colors and blended together with the default tank textures. This makes camo patterns cheap to draw and easy to add. It looks like all tanks get fully loaded during loading time, only the dead version is streamed in as needed. Almost every object has a normal map to improve visual quality. And the max resolution for object textures is 1k by 1k, and most are 512 by 512. Not all textures use a compressed format, especially the UI, all UI textures are uncompressed. They could be compressed to save some space, but most UI elements are so small, that the possible savings are minimal. But if texture caching becomes an issue every bit helps. Some UI element images a bit large, a 501 by 72 contains huge versions of the spectator mouse and esc icons. They do some optimization for static text elements, they render them into a texture and then use the texture instead of rendering the text all the time. At first this sounds nice, but this optimization is used rarely and does not save that much. I’ve also noticed some strange behavior regarding the management of render targets (special texture that can be used to store results of rendering operations). Some of them are very small render targets (16 by 1 pixel), created and destroyed almost every frame, but they are never used. The others are in the screen resolution size, or half the screen resolution size, and are used to render the final image into it, but there are many duplicates created on the fly on some frames. Some of them are never used as a contributor for the final image too. I have no clue why they are doing such things. Conclusion The battle mode rendering inherits the problems of the hangar mode. To get more predictable frame rates, they should rethink their resource management and streaming, and as far as i see Continue reading →

More...