This week I worked on some bugs of the robot shooter. There was a descent list of fixes, tweaks and optimalizations after the first QA session. The last one, optimalization is what I want to talk about today. In this case I want to look into simple, or high level optimalizations.
First some theory to start with. Games in general are rendered realtime to your screen and displayed using 'pixels'. Imagine having a 3D model displayed close to the camera. It fills up a lot of pixels with its shape, texture and polygons, because it is relatively close to the camera. We could say that how closer the 3D model is towards the camera, the more pixels it uses to display itself. Since it uses so many pixels, we are able to see all of the details of the model.
Now, when moving the 3D model away from the camera, it eats up less pixels to draw itself. Sounds logic right? This means that a single pixel on our display covers up some of the detail we have in the 3D model. We could say that the model is less detailed displayed than it actually is. While it is still being processed the sameway, with all of its details. Which actually costs performance. Therefor we could replace the model by lower resolution version of itself, if the model is on a certain distance. A system like this could be called a 'LOD', or 'Level Of Detail', system.
|Model and image by Owen Shepherds|
There are some drawbacks though. The system in this example uses 'distance to the camera' checks to know what to do. Distance checks can be expensive too, and sometimes can be even more expensive than just rendering extra polygons or models with a bit more complex shaders. But keep in mind that these LOD systems don't require to be updated every frame, which can also speed things up. It is all about finding the balance between direct optimalizations and LOD systems.