Utilities:Optimization

[Go to End]

Oblivion Texture Optimization Overview

The following are progress observations by Hlafordlaes as he experimented with various optimization methods once he had decide on using DDSOpt for textures and PyFII for meshes in Oblivion.

It is felt they help to flesh out the "steps" process by explaining his various choices within the proper context.

[Back to top]

[Go to end]


Hlafordlaes Setup

I play only at 1280x1024, but I'm on a Core2Duo E7600 3.02Ghz and a GTX 460 1GB (in a
PCIe1.0 4x slot for a 10% hit in performance), with 4GB RAM and using the 4GB patch. 20-
30FPS is the norm now as a result of these optimizations, with the ocassional dip (and
peak). No FPS controls are on in OSR or in the driver.

Most generally, what DDSOpt is doing for me right now is making me realize I can
"roll my own" reduction and variation packs on texture replacers, and so I am now doing
that and eliminating things like "QTP Redim Reduced" from my install. Also in general,
note that DDSOpt can be slow the first time through a set of files, as it must add and
subtract missing mipmaps, so a "QTP v3.1" first run can take > 60 minutes. Luckily, all
subsequent runs on that output are lightning fast, 1-3 minutes. Therefore, I use a first
run to fix things at the maximum resolution I'll be working with, and then I recopy that output to the
DDSOpt\in folder and make all my variations from that.

My goal is to see how far optimizing textures in the correct combinations allows me to use
higher resolution replacers while not getting such an FPS hit, and avoiding those horrible
sudden screen freezes that arise from encountering highly unoptimized textures all of a
sudden somewhere.

I started directly from "QTP v3.1 Redim", as those who produced it stated they had hand-
replaced and improved things. I figured there wasn't too much to gain by going back to
"QTP v3.1" vanilla. Now, from there on, there is still an improvement, with many mipmaps added,
meaning a better look at differing distances, and my impression is that DDSOpt is also
making some changes that are designed to be read by the Oblivion engine, if I understand
the author. It seems to be true; I get better FPS without lowering the resolution, and less
stuttering. No further reductions are needed, so I now forego any of the published reducers
I had been using.

[Back to top]

[Go to end]


Hlafordlaes Constraints

Note that all settings referred to are found in the "Constraints" tab in DDSOpt.

So far:

I tried using differences between resolution in uncompressed and compressed sizes, and
I may have not been doing things right, but I found little advantage to setting them
differently from each other, even some counter-intuitive results, so I use the same setting
always in both.

[Editor note: Compression is not about the textures themselves, but about removing disk-
throughput bottlenecks and speeding the transfer of the image from the disk drive to the
video card. See the "zlib" section of the [http://obge.paradice-insight.us/wiki/NIFopt
NIFOpt] documentation where compression is recommended "always and as much as possible".]

I've tried leaving textures relatively untouched on the first run (all lossless settings
at max rez) and only adding or removing missing mipmaps. In the end, however, if I
understand the author's write-up, it's best to optimize with "DXT". My first runs are now
all done using "DXTx" settings at 8192x4096 max, as I have decided I'll never want more than
4096x4096 (see next point below).

I then experimented with resolutions, which taught me that "big right hand" rectangular
textures (eg, 1024x2048) are left untouched by DDSOpt if one selects a resolution of
1024x1024. However, if one chooses output at 2048x1024, then these are properly reduced!!
This means that the second resolution constraint chosen in these cases will be the maximum
resolution of the output. IOW, the choice of 2048x1024 provides more consistent reduction.
So reducing to 2048x1024 or 1024x512 gives smaller file sets than 1024x1024 or 512x512,
respectively. (I am going nuts trying to clarify big left hand and big right hand rectangles,
and don't have my notes (lost them) from the runs. Try it yourself; you'll see what I mean if
you test and then peruse the out.log to see what was and was not handled.)

[Back to top]

[Go to end]


Hlafordlaes Resolutions

I then decided to experiment comparing variations of resolution in my main, cross-the-
board texture replacers: QTP3.1, Bomret's, Detailed Terrain and Insanity's Texture
Overhaul
, as well as some lower resolution general packs. The BAIN packages look like this,
in the order they appear in the installers tab of Wyre Bash:

Package Structure: "Winner Take All" (WTA) Texture Pack - Pre-QTP3.1 Std-Rez compendium [2]
00 Core Docs
01 1024x1024
01 1024x512
01 512x256

Package Structure: QTP3.1 Redimized - Mid/Hi Rez
00 Core Meshes
01 1024x512
01 2048x2048

Package Structure: Insanity's Texture Overhaul - Hi Rez
00 Core Docs
01 2048x1024
01 2048x2048

What I discovered is that to maintain a good FPS on my machine, it was necessary to lower
Insanity's stuff to 1024x1024 (2048x1024), but QTP 3.1, once optimized by DDSOpt, was no
problem at all on its maximum resolution. No more hating on QTP 3.1!!

I was also even fooling aroung with QTP 3.0 and 2.0 (parallax), but the first has less
content than 3.1 so no go, and the second led to a new approach (new for me, not new on
this board.) That "new" approach is to get some of the goodies from shaders, so I am using
OBGEv3 Parallax Occlusion Mapping and others to fool around, and boy is this a goldmine of
stuff (but off the topic of textures).

[Back to top]

[Go to end]


Hlafordlaes Results

After the above experimentation:

- Replacer packs are processed as above, but specialized replacers are left at my highest
default setting and only optimized (8192x4096).

- I process the textures of a given smallish non-replacer mod pack at the default highest
resolution as well, but larger mods are all currently at 2048x1024 (i.e., 1024x1024 max).

- Any replacers that affect the game across the board are made into packages like the ones
above (eg plant replacers, etc.) and generally are only allowed a max of 1024. The
exception is the latest Verdant Anthesis mod on TESNexus, which I am allowing to leave at
very high resolution; so far with no ill effects (and great results).

In the end, I am getting some stellar results with far less stuttering and better FPS,
using textures at resolutions I had not dared to use so much before.

[Back to top]

[Go to end]


Hlafordlaes Footnotes

Footnotes:

[1] * Winner take all packs:
I hate a huge list of packs in Wyre Bash, and all the extra annealling that may come with
them when making adjustments. So, when able, I make "winner take all" packs. Once I know
which replacers I prefer to win, I copy them onto the lower order replacers and make a
pack. I know if a pack is worth saving if the "matching files" tab in Wyre Bash BAIN still
indicates that the package makes a meaningful contribution. (On that basis, for example, I
have eliminated all my LOD replacers except for the noise replacer, as tes4ll does all the
work in that department for me now, and leaves those replacers with little to add.)

For example: the "WTA pack" listed above has:

Base: Oblivion General Vanilla Essence Textures, then Oblivion Texture Upgrades Pack
copied on to it, then CorePC's Vibrant Textures on top of that. This gives me a smaller
file and somewhat less wait for anneal operations.

Because it is notoriously ill-behaved, here is the structure of another mod so it
can stay 'where it belongs' without overwriting earlier stuff I may want:

Package Structure: Blood&Mud - The hardest mod to place in proper order!!
00 Core Mod
01 QTP3Meshes4Blood&Mud
02 QTP3_UOP342 Compatible Meshes
03 Full Video
04 Improved Flames - Dungeon White Particle Replacers
05 AWLS Bravil Meshes

[2] As it turned out, it was Insanity's Texture Overhaul pack that was really hurting performance
in my case. I had never given it much thought before. Confess that I had always assumed, but
never checked, that QTP was higher rez and so was deserving of the bad rep it gets for
slowing things down.

[3] Granted, the documentation linked to from the DDSOpt user guide
Modders Manual refers to OBGE, but the
explanation given regarding the benefits of using a constant "z" value in DTX5 and simplifying things
for the Oblivion engine is what I think is the "special sauce" about DDSOpt.

[4] Just went back and checked my QTP 3.0 files pre-DDSOpt. The resolutions are not all
that high, with some at 1024x2048. What you do have is a lot of uncompressed files in non-DTX
formats. Ostensibly these lossless formats require more effort to handle than a quick DTX
that is optimized for the engine.

[5] From the Wikipedia article Mipmap, regarding "mipmaps"
(and why adding them back saves processing effort while giving better quality at the same base
texture resolution):

"Each bitmap image of the mipmap set is a downsized duplicate of the main texture, but at
a certain reduced level of detail. Although the main texture would still be used when the
view is sufficient to render it in full detail, the renderer will switch to a suitable
mipmap image (or in fact, interpolate between the two nearest, if trilinear filtering is
activated) when the texture is viewed from a distance or at a small size. Rendering speed
increases since the number of texture pixels ("texels") being processed can be much lower
with the simple textures. Artifacts are reduced since the mipmap images are effectively
already anti-aliased, taking some of the burden off the real-time renderer. Scaling down
and up is made more efficient with mipmaps as well."

[6] I think some parts of the file are laid out differently when processed by DDSOpt,
but I cannot confirm that. They seem quicker to read using any tool as compared to the same
textures unprocessed.

[7] Confirm no harm is done to sensitive files using the steps discussed in here. I had been a bit on
edge about that, as I had left some body and face mods only partially done, once suspecting foul play.
Not at all, there was another cause. Just redid some last bits of my face and body replacers, plowing
through as per above, to good effect.

[8] Related learning point: Osmos hi-rez textures for HGEC are massive. DDSOpt seemed
almost to choke. No wonder there are still mystery Oblivion CTDs with things like this lurking. Once
optimized, they are much better behaved.

[9] Here's my Wrye Bash Install order as it stands right now:

Had to drop OBGE down below Insanity's for the moment, as the latter replaces
sunglare.dds. Gonna adjust that so I can put OBGE back up where I like to see it.

[Back to top]


Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License