Right on. I will just leave them as-is.

http://www.tesnexus.com/downloads/file.php?id=36882

I went ahead with releasing a new batch script which actually works, with up-to-date patches. It's based on the original Patch Scripts mod, but I rewrote the scripts and it supports Windows VIsta/7. It seems from viewing the originals that it had some oddly XP-specific syntax in there, that I still don't quite understand. Whatever it was no longer works. However, there's nothing I can see that would prevent my batch script from working in Windows XP. I followed the book with the syntax and I'm pretty sure mine will support XP. Please let me know if you are on XP and if you have any issues.

I've uploaded the PATCH file archives for both the vanilla Oblivion meshes BSA and the Shivering Isles meshes BSA. I also have an archive for QTP3 Redimized, though you do not follow the BSA extraction/creation instructions for that and instead unpack from the OMOD/BAIN archive and repack again.

One thing I noticed from the original patch scripts is that not everybody had FORFILES.EXE on their OS. I found it hosted on Microsoft's website, and I have it linked to in the Mirrors section. You only need to download it if you receive any "command not found" errors during the patching. Place it in the Patcher folder if you need it.

Arthmoor:

Why do you skip clutter and ground nifs?

He doesn't. There are two INI files. You have to run both of them.

Clutter and ground nifs are on the skip list for the main Optimize.ini. I thought that meant they get skipped? Let me take a look at the OP again...

EDIT:

Oh I see. So what does the second INI do that warrants a separate INI?

I'm not sure why the clutter nifs were included in the regex I'm using. There was some kind of reason, but it's buried in a past thread somewhere and I can't find it right now.

The second ini file is going back to cover what the first one misses. Which is the clutter folder and the _gnd.nif meshes. It skips the _gnd.nif files in the first run because many will overlap with the detection for helmets and such, but they're safe to optimize and so need to be picked up in a second pass. Usually that second pass is done in a fraction of the time because it skips over the stuff that's already done.

what mesh files other than EGM should not be pyffi?

Are LOD safe?

what about KF?

Yeah, this OP is in desperate need of an overhaul... I've been working on a candidate, but I want to let this thread run its course to make sure I've got everything. :confused:

These are the incompatible meshes:

-Any hair mesh
-Roothavok meshes
-Any mesh with a .EGM association (commonly helmets)
-Any mesh with a .TRI association (teeth, eyes, etc.)

_far.NIFs are ok, in fact, PyFFI is capable of further optimization specifically for them. Here's the batch script to call the Modify_makefarnif spell (courtesy of Vorians):

cd C:\Python26python.exe Scripts\niftoaster.py modify_makefarnif  --only _far.nif$ "C:\Program Files\Bethesda Softworks\Oblivion\Meshes"

Both of these will be covered in the OP overhaul I have waiting.

I've never seen PyFFI play around with .KF when running optimize, so I'd assume it doesn't optimize them. .KF files exist to tell the engine how to move skeleton bones for an animation, not much more. PyFFI is, however, capable of working a few tricks on them, such as reversing the animation or speeding it up/slowing it down.

Shouldn't that be "C:\Program Files\Bethesda Softworks\Oblivion\Data\Meshes"?

Actually that batch file from Vorians is intended for use in trying to generate _far.nif files. I think. It's been awhile, but that command structure looks obsolete. Which is where mine comes in:

"C:\Python26\python.exe" "C:\Python26\Scripts\niftoaster.py" --noninteractive opt_cleanfarnif --dest-dir= --source-dir= --pause --overwrite "%1" > "PyFFILog.txt"

You'll be sure it gets everything it should this way. I've also noticed that spell performs the normal geometry optimizations as it works.

When you say any hair mesh you mean even Hair.nif. Any nif that is for the hair slot in the game right?

And what about mesh NIF files that have EGM, do BOTH the myfile.nif AND myfile.EGM need to be removed from the Pyffi process or JUST the myfile.EGM?

LOD are ok then? Cool!

You are correct on the first one.

For #2, PyFFI doesn't do anything with the .EGMs, but it cannot optimize any meshes that have an associated .EGM, so in essence, both must be removed from the optimization process.

LOD meshes are just reduced quality meshes with all uneeded data (Specular, Vertex coloring, etc.) stripped from them, other than that they behave exactly as you would expect a run-of-the-mill mesh would as far as PyFFI is concerned. But as was stated, you can tell PyFFI to create or further optimize VWD meshes if you want.

A clarification requested for the batch files suggeted here by Arthmoor and Vorians.

I have used the context menu option right-click->"Optimize with Pyffi" in the past. How do I run these batch files posted (I know that I have to double-click on them), but where are they supposed to be placed? In the Oblivion folder? Or it does not matter?

Do the batch files optimize the extracted Oblivion - Meshes.bsa, or just files that are in the Oblivion/Data/Meshes folder?

Here's a question for those much more knowledgeable about PyFFI than I...
I recently just finished running every single mesh (except hair, helm, hood, and other excluded items) through the latest PyFFI/Python combination. I have since noticed a few graphical oddities, but am unsure whether they are related.

(1) A rock in a cave I visited recently (Grayrock Cave I think), was exhibiting some strange graphical glitches. The textures themselves appeared to be flickering, much like what appears when you have two meshes in the exact same position.
(2) Water now has a noticeable tiled surface effect. That is, an entire "tile" of water is evenly shaded.
(3) When approaching a light source from a distance, the light will suddenly "turn off" instead of slowly dimming as I approach. For example, a stationary city lamppost will have roughly the same brightness until I get within 100 or so units of it, and then it will not provide any ambient light at all (though the flame is still present).
(4) Torches in caves, etc. will light distant rocks unevenly. For example, half of a flat-faced rock will be fully lit, while the other half won't be lit at all.

Any idea what might be going on? I have a tough time believing PyFFI is responsible for all of this. After all, most of it seems related to shaders, not meshes. But I haven't touched the shaders in ages. At roughly the same time, I upgraded to the latest Nvidia drivers and also turned on Ambient Occlusion and Anisotropic Filtering. I suppose I should try rolling those back and see if it helps...

When you unpack your meshes to optimize, copy the batch files to that folder and double click them from there. My files are intended to be used from whatever folder they're sitting in. So some caution is probably warranted that you don't want to execute them from the wrong place.



All of that sounds like the Ambient Occlusion is messing things up. Oblivion does not support it, and I've never seen anyone have good things to say about forcing it to try via the nVidia drivers. Anisotropic Filtering shouldn't be an issue. I run that at maximum, and the last time I had an nVidia card it worked fine.

I would second that. I run with 16x AF set to "High Quality" on my Nvidia card (GTX260) and pretty new drivers 263.14 (I believe), and these AF settings still work fine today. Just saying...

@amorilla: Would it be practical/feasible to automatically run clean_far_nifs (after the regular optimize spell) when choosing the "Right-click -> Run PyFFI" option via the ini?

Sorry if I'm not following everything here - just to wrap up potential improvements for the next release:

• include Arthmoors improved skip list (I kind of hope that it would be possible to merge the two ini files into one... but probably not before I switch to Python 3 and argparse)?
  
• look into possibly integrating clean_far_nif into the optimize spell?
  
• add batch files to run the optimizer spells, and make the shell integration optional
  
• integrate jonwd7's patcher? (actually pyffi has a patching spell directly, although I guess this is most likely not well known!!)

Any other low hanging fruit I missed?

Optional shell integration is much appreciated.

If you want to integrate patching in some way, that sounds good to me. I don't know if my batch file is anything special. The old version by didn't work on anything but XP, and I still haven't gotten around to testing my batch file in XP Mode in Virtual PC. The thing is that I'm finding some people with GOTY version say their BSA differs, some say their BSA is the exact same. So I don't know who is right. I had somebody verify for me that their GOTY BSA had the exact same MD5/SHA-1 checksums as my original release BSA. The script also still relies on Forfiles.exe which not all Windows versions have, apparently. What this means is extracting the BSA and patching the files and recreating the BSA instead of PyFFI-ing is currently about as hard to get the head around as PyFFI-ing itself, for novice users. The only current benefits to patching is time.

I was possibly going to do a more robust EXE file... A commenter had some good ideas like BSA extraction/creation automation with BSA commander, which would help people with patching the vanilla BSAs, and I could verify checksums and what not even.

Of course, that all deals with just the vanilla meshes... Most PyFFI-ing doesn't take nearly as long, so what exactly is the need for patching in PyFFI? I'm not against it, just curious.

I could see it working in the In/Out environment. An additional Patches folder which generates the Patches after PyFFI has finished running (although the two-part INI process kind of mucks that up). The optimize-in-place PyFFI-ing seems more tricky. Of course the In/Out/Patches environment is identical to the way the patcher is currently set up, which is why it'd work well there.

Just remember to credit H2DOK instead since they're his improved skip lists, not mine

I would also make a backup of your Oblivion.ini file and try running with a default .ini file to see if the issue persists. Reason for this... I recently started using Deadly Reflex 6 and one of the suggested .ini tweaks for 1st person view to work properly was to edit fNearDistance=0.0000

Doing this caused all sorts of shader weirdness. Grass and distant LOD textures started to move rapidly as if the timescale was set to 1000.

Point being, any minor changes to the .ini can cause all sorts of weirdness.

Yep, it was the Ambient Occlusion all right. Thanks! When I forced AO off, most of the described symptoms disappeared. My FPS dramatically increased to boot. I still need to check on that flickering rock and tiled water however.

Tiled water sounds similar to something that cropped up when I switched to using ATI cards. Make sure you aren't messing with the uNumDepthGrids value in your ini. It should remain set at 3 or you'll get anomalies with the water.

Alright, after reading through all the posts, I want to make sure I'm doing this right.

I've unpacked the Oblivion Meshes.BSA, using OBMM, into the toaster/in folder. Do I have to go through and delete all the files below, before I run the optimization:

- Any hair mesh
-Roothavok meshes
-Any mesh with a .EGM association (commonly helmets)
-Any mesh with a .TRI association (teeth, eyes, etc.)

Don't delete them, PyFFI comes with a skip list that automatically skips them in the optimization process. Just unpack the meshes BSA to the in folder, select run PyFFI on the oblivion_optimize.INI, go get a sandwich, and when PyFFI is finished, place the contents of the out folder back into the in folder, overwriting as necessary, and repack the BSA.