So, after our little sudden clarity moment of reexporting every asset we had due to OgreMax miss-configuration. Some of our artists were wondering why the game's framerate didn't improve much.
I told them “it's because we're heavily CPU bottlenecked”. Reapeating that phrase multiple times didn't work, so they were obviously not getting it.
PCs consists in two parts: The CPU & GPU. Both are similar and yet different. They both do math and read and write memory. And they work in parallel, at the same time. One does (usually) the heavy physics and logic, while the other handles graphics rendering.
The thing is, if one of them finished too early, it will keep idle waiting for the other to finish. Taking off jobs from the idle chip won't make it any faster. You need to take away work from the work from the overloaded system, which is the CPU in our case.
It's best explained with an analogy:
It's like surfing the web with a bad provider, terrible bandwidth and painfully slow latency (lag).
You will think the “computer” is slow. So you go and defrag the PC. That doesn't work. Then you add more RAM. It didn't work either. You try all major browser, same result. The list of what you can try goes on.
You may even get the best machine money can buy, like a 32-core Xeon CPU with 32GB of RAM, and 6 RAID0 SSDs harddrives. All that is not going to matter. Web surfing will still be awfully slow, and you may still think “that computer” is too slow.
In reality what you need to do is to move a better ISP and fix the network. Once you have decent bandwidth and latency, you will start noticing web browsing is suddenly instant-fast.
In the analogy, the the network is the bottleneck. In TDL, it's the CPU. Once it's fixed, factors like polycount, vertex count, number of lights, screen resolution, will start becoming a bigger factor. But for the time being, the problem is somewhere else, deep in C++ code.
So, there it is. The problem sometimes doesn't lie in vertex count or in more aggressive Lod, or shorter view distance.