Tuesday, January 29, 2013

No, it's not the polycount what matters

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.
And now it's time to start talking about the PC's power: Javascript performance, which browser is more responsive, available RAM, impact of antivirus and other software running in the background.

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.

Sunday, January 20, 2013

OgreMax exports too many vertices!

OgreMax is the preferred Ogre mesh file exporter for both Maya and 3DS Max.

The problem is, it is exporting around 4x the required vertex count! Note this problem affects both versions of the plugin (Maya & 3DS Max)

Geoff asked us to look at the corn field because it was having a terrible framerate. I took a look with Jeff, the modeler responsible of it, and it wasn't exactly the most expensive model ever invented, to be generating such slowdown.

So, I took a deeper look with Ogre Meshy, and the vertex count (around 1100) seemed too high to be true. Even more suspicious was that the vertex count was exactly the index count.
I ask Jeff to handle me the obj file so I could export it in Blender. And the resulting vertex count went down to 442!!! I thought it could be a problem with the smoothing groups, as flat shading causes a lot more vertices to be generated (vertices with different normals need to be duplicated).

I reexported with flat shading this time, vertex count was now around 700, still lower than the exported mesh from OgreMax!

As we played with OgreMax settings, we found out the culprit is a setting named “REMOVE DUPLICATED VERTICESwhich is turned off by default!!
After re-exporting with this option on, OgreMax' exported model matched the vertex count from Blender (442)

This is very bad, because not only the amount of vertices is increased, but it's also the worst possible scenario: Every vertex is not being shared and thus can't be reused. This leaves the post vertex cache completely useless. I don't know why the default option is left unchecked, I can only think of very few possible scenarios where having 1:1 vertex - index ratio could be useful.

We proceeded to reexport all of our assets in, most important big ones first. The zombie vertex count went down 4.1x.

Thanks to our buddy Jeff who took the screenshts for us: