Part 1: http://ftr.wot-news.com/2014/07/18/world-of-tanks-client-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 it thiere render target management contain some bugs that cause unnecessary resource allocations.
Some of the problems are also possible faults of the model and texture artist. As a programmer you can develop a content ‘backing’ tool that detects stuff that is duplicated and replace the duplicates with links to the resource. A backing tool could also help with some automated stuff like compressing images that are not compressed or shrinking textures that contain only one color to 1 by 1 pixel. These backing tools could also translate models created the old way into the new form to unify the rendering method, which could result in less state switches.
Again, give this guy a job at WG.
+1
They don’t deserve him. Works too hard.
Give him all the jobs…
That’s the problem WG has – guys like him won’t work for WG – never ;)
I agree, SS should get a position in WG, in stead the support worthless shit like Quickybaby
I did not write this.
But you do a great job here. You could manage the WG portal (EU).
No, SS is as good as he remains independent to WG. He couldn’t do what he does if he were on WG’s payroll.
True, but then I’d have other tools at my disposal. Everything has its pros and cons.
+1
Whats the problem with QB?
Well, he too says BS (E-50M depession woes… its -8 noob QB :D ) and can at times be an idiot.
No different fro Jingles though (BS IS-3 is buffed video, such a noob :D ).
Truth is both are human and make mistakes.
E50M gun depression is only -8 when the turret is sideways.
You may not like QB, but apparently you know less than him about that particular tank.
I actually like QB.
-8 to the sides, -6 at the exact front. He should have noticed that.
I wrote guides on it :P … I should know lol…
As an aside note, the T-62A is -5 (historically -7).
Aye, I make mistakes too, had a few nasty blunders over the year and half FTR exists. Shit happens.
You guys make a terrible mistake here:
QB is about Entertainment. Yes he does some “news”-Videos and tank reviews on how to play this and that, but it is for people who are primarily interested in playing WoT.
SS here is about information, not entertainment (althought some stuff is (sometimes unintentionally) very entertaining. What he does is on an entirely different level and aimed at completely different interests. it is for people who are interested in Tanks and who are interested not only in playing but in fully understanding WoT (and WG). Not everybody wants it this deep.
As Jingles is also mentioned – he is actually a bit like a “bridge” between the SS and the QB sphere of thing. From his videos I know that he reads this blog a lot and has a very high opinion of it and he thankfully uses the information sometimes. About as many times as he gets his stuff completly wrong. :)
The point is, that people watch him, because he has a nice voice and very entertaining, not because of the accuracy of his statements.
I am thankful for FTR, when I want a look into things or behind the scenes. I am thankful for Jingles on Monday morning, when he eases me into the dire workday and I am thankful for QB when he gives me a laugh in the evening.
Stop giving shit to the fork for not cutting the meat – it is neither supposed nor trying to be a knife.
I don’t get all the QB hate. He’s, by far, the most respectable and entertaining streamer/youtuber (in english at least).
He makes mistakes, but who doesn’t? When you’ve recorded ten minutes of speech, you won’t restart everything cause you said “-8 gun dep” instead of 7 or 6, seriously.
He never whines like Jingles, mostly stay quiet and never insults or starts pointless arguments with other people. And, no matter what you say, he’s a very good player.
My only beef with him is the constant arselicking to his public. “As always, you’ve been awesome guys, thank you SO much yada yada”. Dude, you’re playing for us, we pay you, stop pretending you like us.
If you think he’s the most entertaining streamer you should fucking visit other streamers. He’s fucking boring and arrogant as shit. It was super cringy when i was watching his stream and he literally told Ik(Ikzor i guess) to shut up because Ik talking was apparently making him nervous because he was alone against few enemies so everybody had to shut the fuck up so his majesty could carry the game. I mean if he’s this fucking rude to his platoon mate i don’t want to ever again watch his stream. Jingles is mediocre player, but at least he is fun to watch. QB is boring and acts too much like an all know douchebag.
This one is smaller, then the first article.
What map were you analyzed?
That’s because the first article had three parts or so mashed together, this is just one.
The analysis bases on a replay on South Coast map, but the behavior is on all maps the same.
I wouldn’t be so sure. As far as i know, latest maps, like Kharkiv, uses another rendering technique. At least those maps have PBS ready tag in their resources.
tiejeng,
i do take it your ar the author of the article?
If yes could u please check Kharkov, maybe there is something to what Sideburn said, i would really like to know.
mfg eX
PS: nice read, thanks!
Ok, i will take a look at it and check for any major differences.
“Some very large textures only contain one color, which is a lot of wasted space.”
This isn’t the big deal you might think it is in a modern render pipeline, and there are good reasons for doing it. That being said, it’s more of a clever hack for a problem that should probably be fixed in a more elegant way.
Can you elaborate on the reasons for doing it?
In WoT world, disk is free (true for nearly anyone these days), RAM is free (WoT doesn’t even hit the 32-bit limit), and DXTC is free via the GPU. WoT is extremely CPU limited though. Anything that lessens CPU impact, regardless of the other penalties, makes sense when they’re too lazy to fix the rest of the render pipeline.
More memory consumption are increasing the chance of cache misses, and cache misses are wasted execution cycles where the processor does nothing other than waiting for the memory.
If your textures are in the cpu cache, you’ve got bigger problems.
This game is so poorly optimized…. maybe its because they lack experienced specialists in Belarus ? After all, they said they hired every possible specialist in the country.
They also admitted that their devs come from PHP background and such and they learned everything on the fly, that’s why everything is written so that it barely works and that’s why they make videos to brag about stupid stuff – for them is a big achievement to make something that an IT student / 3D course attendant does as a simple assignment.
There’s a reason why, for example, Frostbite is a technologically advanced engine and lets you play 64 vs 64 with great visuals – they published tech videos of this and that which are worth seeing. Meantime, for WG devs it’s a great achievement to make tracks sync with sprocket wheel. Or they totally fuck up moving corpses – they used to twitch a bit, now they are moving all over the place and you have enemies standing behind invisible obstacles. That’s not even visual, that’s a game breaker. Should I mention how they took like a year or two to implement a reload timer?
I did some research, some of the problems are inherited from BigWorld (as an example, using d3d9 ext fx system, which is bad).
Yes it is, it’s very bad, and apart from performance/technical issues, there’s a very direct and important (for many clan players) problem with it – the Mumble overlay doesn’t work with DX9ex so you don’t see who’s talking. And Mumble > TS due to performance and audio quality :(
There is however a hack-around for it, you can force WoT to run on (pure) DX9 by injecting a correct .dll (if you are on x86 system), wonder how it affects the render pipeline? Does it just invalidate the ext fx calls thus granting performance “by the way” or is the overhead still there?
Can you give me some proof about that PHP thing?
Because I frankly have a hard time believing that. Most PHP devs could barely code a plasma effect, never work on a modern graphics engine…
They said it in one of the official videos, can’t recall which one. Something along the lines that their devs were doing web applications and had to learn quickly how to make WoT. It was one of those videos where they said that making something was very difficult but they are proud they done it blah blah blah. Maybe one about the new motion mechanics.
Thing is, that makes no sense. WG made games before WoT. Which implies that they would have had developers who were already experienced in C++.
In that context, it makes no sense that they would throw their web development team (responsible for the web presence) onto a game project like WoT when they already had experienced game developers.
I’m guessing that this video quote was probably a mis-translation or just plain bullshit. It wouldn’t the first time someone talked complete horse-shit in a WG video.
“t looks like all tanks get fully loaded during loading time, only the dead version is streamed in as needed.”
Does this apply to all battles or just random matches? Seems like it could be taken advantage of in CW if they always load all 30 tanks.
Again, this is an interesting follow-on to part 1 (Which I commented on, although I was perhaps overly harsh on the author) but I suspect most of the people reading and commenting will just think:
Hur-dur, Big World shit, WG shit, Hur-Dur.
The thing is, it’s very easy to look at a big, old codebase and denounce it is shit without understanding where that code-base came from and why it’s in the state it’s in. Never mind just attempting to de-compile executable code and drew solid conclusions from it. This is, true of the company I worked at previously. Objectively their codebase was horrible. Practically, you can’t throw away 10 years of development on a whim without losing all your clients and going out of business.
The analysis is impressive, from which we can see the author is a veteran on game application optimization, he is very skillful in many aspects; however on the other hand (with all due respect), not really familiar with how opt. works.
There is a famous quote about program optimization: “The first rule of program optimization: don’t do it. The second rule of program optimization (for experts only!): don’t do it yet.”(Michael A. Jackson). Why not to do it yet? Because it is suggested that never do opt. before you have your code/program profiled. Profiling is the key to all the the other opt. processes. Find the bottlenecks and solve them, rather than wasting time on fixing tiny defects which you thought might be slow, but later it turns out they are only one to some millions to other insignificant problems.
Many points in this article are really trivial – yes, they are not well implemented, but at least they worked, and it worth nothing to waste manhours to change their implementations at the risk of damaging them or other modules which are connected in a who-knows-the-hell way, especially for such an ancient engine – you can just imagine how smelly its codebase is, after years of maintainance by hundreds of coders. They are slow? Probably, but only if they are invoked in a very high frequency – like to load the user configuration a million times a second, that would make it slow.
Maybe the author just wanted to expose all the ill-implemented parts of this game, big or small, but the important points are blurred out. The article just gave us a feeling like “technically, the game is just a full load of shit, written by another load of WG shitty coders”, however it won’t solve the problems.
The unnecessary loading – and mostyl,e saving – of user configuration is stupid for one reason – if the game / PC crashes, you lose the config. Happened to me way more than once, game crashed during battle, whole configuration was erased on next launch.
I hope at least half of this gets brought to WG’s attention. Maybe that would help them or encourage them to do something about their game optimization in the future. That is if we assume they won’t be to lazy to give a fuck about this.
Frankly I believe they do know about it.
They said themself, there is a lack of professional game developers in the russian speaking area of the world and there is a lack of russian speaking game developers in the western world which inhabbit most developers.
My guess, they struggle with the workload of keeping the game runningas it is now and optimizing it. So we will see a lot of small fixes which will repeate the problem over time as it stays code in alot of stages of optimization. Everytime they fix something they have to be sure it works with the stuff they weren’t able to fix yet. That is a process which will never finish that way.
It may get better over time though.
Pingback: World of Tanks Client Analysis (Part 3) | For The Record