Optimising Oblivion v2.0

Part 2: Performance tuning

This has become somewhat of an art for Oblivion. It’s hard to argue that the game was well optimised on release. From low end to high end machines, it seems everyone has seen benefits with the following tweaks.

1) Raise the preload size limit
For 1G or less machines, use the following:

iPreloadSizeLimit=104857600   (default 26214400)

This raises the preload limit from 25M to 100M. For 2G or less machines, use the following:

iPreloadSizeLimit=262144000   (default 26214400)

Which does, of course, set the limit to 250M. You can go higher, but whether you will see further improvement is debatable. Observations on the preload limit: if set high enough, transitions between indoor and outdoor can become near instant for previously visited cells. I.e, entering and then leaving a shop or dungeon.

2) Raise the cell buffer
Setting the following keeps more cells in the preload cache:

uExterior Cell Buffer=100   (default 36)

Note: that this will raise automatically if using raising uGridsToLoad as per the level of detail tweak in Part 1. However, raising it higher can provide further benefit.
Note: this requires you to raise the iPreloadSizeLimit as in the above tweak, otherwise you may experience stutters or crashing.

3) Cut the grass
Grass is swank, but it’s also a huge performance drain. Reduce its frequency a big performance boost with little change in visuals:

MinGrassSize=130   (default 80)
fGrassEndDistance=8000.0000   (default 3000)
fGrassStartFadeDistance=7000.0000   (default 2000)

If you have a medium to high end machine, knock the distance values up to 10000 and 8000 respectively. For lower end machines, try a value of 150 or 200 for the minimum grass size.

4) Threads
The following tweaks appear to have a positive impact, but they are by their nature dependent on your hardware. While the theory goes that dual-core machines will benefit most, single core CPUs also spend a merry time running multiple threads, and these tweaks have helped single-core users too.

But remember, just because these tweaks allow Oblivion to better use your processor's resources, they don't necessarily mean the game will run faster. In fact, the benefit of these tweaks appears to deal more with preventing or reducing pauses and slowdowns than improving your framerate. Which is still a Very Good Thing.

bUseThreadedBlood=1   (default 0)
bUseThreadedMorpher=1   (default 0)
bUseThreadedTempEffects=1   (default 0)
bUseThreadedParticleSystem=1   (default 0)
bBackgroundLoadLipFiles=1   (default 0)
bLoadBackgroundFaceGen=1   (default 0)
bCloneModelsInBackground=1   (default 0)
bBackgroundPathing=1   (default 0)
iNumHavokThreads=3   (default 1)

Keep in mind that threads aren't magical cookies of blazing speed. The more threads you run, the more resources are required to run them. This actually leads us to the [OpenMP] section of your .ini file. Set the following:

iThreads=20   (default 3)
iOpenMPLevel=10   (default 10)

OpenMP is a specification for a multi-platform shared-memory multithreading API. It helps make it easy for developers to integrate parallel processing in their programs, and has the nifty ability of being able self manage threading resources -- threads are activated for parallel processing from a pool as required, so it's possible for an application to branch out from a single thread into multiple threads and then return to a single thread.

What this means to our understanding of Oblivion is not particularly a lot -- except perhaps to say that the iThreads setting is likely a limit to the maximum number of threads in the pool, and not the number of threads that will run continuously. You don't suddenly get Uber Performance by setting a high value here, you only allow Oblivion to use more threads if they will be of benefit. So how many threads can Oblivion make use of at its peak? Great question. If you know the answer, drop me a line at amills@atomicmpc.com.au

For the record iOpenMPLevel presumably sets the priority of the threads, for which 10 is 'Above normal' in Windows. It's probably best not to touch this -- too low and you'll hinder the performance of the threads, too high and you'll hinder the performance of everything else. It's worth noting that the previous sentence is somewhat of a total and utter guess, but it sounds good to us.