I don't know. I use shortcuts myself. (actually I use a explorer replacement that has menu/button bar I can place programs in, it works almost like shortcuts)

Yeah, and since I also wanted to make some kind of sense of the output I've had to restrict the process to one core so I can see what meshes are failing to process. So far not a huge number, but it's got a lot of stuff to go through. I've already reported some failed meshes at the sourceforge site but I don't want to mass submit too many at once

Some of these things are having hundreds of duplicate collision verts removed - a few I've spotted in random jumps in the log are losing as much as 90% of them.

Well that was an overwhelming disappointment. Finished optimizing collision on all of the stuff in my custom BSA pack and there's no appreciable difference in FPS at all. I expected something to come of it, but it did absolutely nothing.

:(
I had hoped so too. As I said earlier I had nothing to compare with because it was a totaly new install of Oblivion. I do have a better flow in my new even with everything maxed out, somewhere I did something right.
Still, as it looses quite a chunk of memory requirements on some meshes (not all) one at least might have some less memory swapping.
I for one will still continue to optimize my collision meshes, slowly I will cover everything I have installed.

To bad nothing came from your, and mine, expectations.

Cheers!

Yeah. The only benefit I see is that the BSA is now 659MB where it used to be 813MB. 154MB is a decent savings, but I wasn't running out of space

Ok, I'm on crack and have no idea where I got those numbers. The difference is barely 20MB.

Every litlle bit...
I was about to check my meshes.bsa but discovered/remembered I had removed it and am running on pure folder meshes instead. Had some problems trying to swap some meshes in the original and the leading spaces that I had scotched.

As my install is mainly CPU dependent I was hoping the optimizing of the collision would help my poor overclocked CPU

Ah well, maybe the PyFFi team will have some heavier optimization for the collision in the future.

Cheers!

Folks using Lost Spires and Dungeons of Ivellon will be happy to note that THOSE mods will see substantial gains since a huge number of meshes got converted to MOPP collision which is far more efficient on CPU time than the older packed shapes method. Of course, that's of limited value outdoors, but in interiors using the custom assets, it'll be noticed.

It seems I have been away from the PyFFI thread for too long because I seem to be out of my depths regarding new features in v2.1.5, in particular the "opt_collisiongeometry" spell everyone keeps mentioning. Specifically, can anyone tell me what exactly it is and how I use this spell? Between Sourceforge and PyFFI's documents, the only mention of it I see is the changelog noting that it has been added.

There is a minor problem with the skip list, it is case-sensitive. The possible combinations of case makes this unpractical.

(I noticed this while installing the B&M I optimized yesterday, it had optimized the Ren_Hair* that is included in that. I did have "hair" in the skip list so I tried adding "Hair" to it. Then it skipped them.)

Is this optimization automatically applied when right-clicking folders with 2.1.5, or how do you actually make it work?

No, getting it to work via right-click takes some registry hacking. You lose log output that way, but if you're not worried about catching the ones that fail it works fine with a couple of tweaked files. I'd suggest avoiding registry hacking unless you know what you're doing. It's way too easy to break something in Windows otherwise.

Next best thing is to use a batch file, like this one:

"C:\Python26\python.exe" "C:\Python26\Scripts\niftoaster.py" --noninteractive --ini-file="C:\Program Files (x86)\PyFFI\utilities\toaster\collision.ini" --ini-file="C:\Program Files (x86)\PyFFI\utilities\toaster\oblivion_optimize_collision.ini" --dest-dir= --source-dir= --pause --overwrite "%1" > "PyFFILog.txt"

It will need a couple of new files, placed in C:\Program Files (x86)\PyFFI\utilities\toaster (or wherever your PyFFI support files ended up)

collision.ini:

[main]; default folder to toast; should *not* end with a trailing slashfolder = ./in[options]; set this to the number of cores you havejobs = 1; default source directory (for determining paths to write in destdir,; usually identical to folder); should *not* end with a trailing slashsource-dir = ./in; default destination directory; should *not* end with a trailing slashdest-dir = ./out; resume support (if True, nifs that already exist in destination; folder will be skipped)resume = True; if True, pause when donepause = True

oblivion_optimize_collision.ini:

[main]; run optimize spellspell = opt_collisiongeometry[options]; any patterns of files that should be skipped; (without quotes, separate different regular expressions by a space); at the moment:; - skipping hair nifs (vertex ordering!); - skipping roothavok nifs (not sure why, investigating); - skipping any nif that is known to have an egm or tri associated with it;   find . -name "*.egm" -or -name "*.tri" | sed 'sX.*/XXg' | sed 'sX.tri$XXg' | sed 'sX.egm$XXg' | sed 'y/ABCDEFGHIJKLMNOPQRSTUVWXYZ/abcdefghijklmnopqrstuvwxyz/' | sort | uniq | xargs;   (not necessary if all egm files are included, such as in vanilla Oblivion,;   but some mods only include nifs without egm files, and this makes sure;   these cases are handled as well)

I knocked out the skip list in oblivion_optimize_collision.ini because a mesh without collision won't get touched, and opt_collisiongeometry only acts on a select few types of collision anyway which the usual skipped files won't have anyway.

Stick the batch file in the folder you want worked on, and it will run through every mesh in that folder and any subfolders. It's output will end up in PyFFILog.txt where you can look for failures and see what it's doing. It's probably not going to help much to hit all the vanilla stuff with it, it did zilch for me there. However certain mods like Lost Spires and Dungeons of Ivellon have a lot of meshes using the older type of collision which this operation will convert into the more efficient MOPP type. So using it on mods is probably going to do more for you.

So far I've not run into any defects in the game so it appears to be perfectly safe.

I need help (and not just metaphorically). I pyffied my meshes BSA, repacked it, and started a game.. but I've got missing mesh markers in a lot of places. I checked the number of files against the original BSA, and it's got 31 more files :confused: I tried going back to the original BSA (using redirection in OBMM) but the game won't start. I tried resetting the timestamp on the pyffied BSA, and now the game won't start with that one either. :banghead: I just want to play Oblivion...

No idea how you ended up with 31 extra files, but missing mesh markers in radnom places sounds like you're on a 64bit system and the files that have leading spaces had them removed.

Unless one of the files got corrupted during the process, you should be able to use the UOPS to get around that as it resets the path to those resources to use the included files with no leading spaces in the names.

Nope, 32-bit system (Win XP). I also checked those specific meshes, and the leading spaces are there. The meshes I noticed as missing were on the front of Benirus Manor (maybe the morning glory?) and in a cave nearby (looked like the cairn bolete/wisp stalks). I check the BSA and found that the plants meshes were present, although I'm not sure which ones in particular to look for.

Dear Arthmoor,

thanks for the kind and very detailed reply - if Spires don't run smoothly I'll surely give them a good tweak with your script

Beyond MOPP collision and what done when right-clicking folders with 2.1.5, is there any further mesh optimization that you suggest?

Cheers, Tommy

Okay, this is really weird/annoying. I unpacked/repacked my pyffied BSA (to reset the timestamp), and now the game recognizes it (as well as the original BSA).

My problem: There are still some meshes that the game refuses to process. It took a little work, but I figured out what they were: Dun crates and dun barrels (those broken barrels and crates you find in caves and fort ruins). For some reason, they show up just fine in the CS, but even after manually extracting the files from the BSA and placing them into the Meshes/Dungeons/Misc folder, they won't show up in game. I've tried using both BSAs, and extracting the files from both, and neither one works.

Is there something that will prevent meshes from showing up properly, other than lacking the files?

I have to ask how long does it normally take to optimize the meshes in the Oblivion BSA? I am using an i7 860 and it seems to be taking advantage of it for the most part.

Edit: It took me a couple of hours. The last time that I tried this a year ago I left everything on overnight just to find out that it wasn't finished. I'm impressed with the progress that they've made with pyffi.

for some reason when i download pyffi my computer slows way down. this is once it is downloaded to my computer and on the download bar it says only 2.2 of 2.4 mb were downloaded but it is finished.... why is that?

srry for double post but i finally got it to download... but how do i install the pyffi automation?

What is the proper way of using the new spell? Should I run it after the old one on the files already optimized or on the originals (if it optimizes different files and won't overwrite the previous results)?

Some good news, and a call to help with testing...

First, the good news: I think I managed to fix the issue with FPS dropping substantially when many NPCs are in view - turned out I had to order the vertex map slightly differently. It's a very small thing, but it apparently makes a huge difference. This will be included with the next release.

Vertex cache optimization tests

Now, I've also started experimenting with an optimization scheme which does not optimize strip length, but which optimizes the vertex cache instead. This may lead to slightly larger files, but with better data locality, and therefore taking better advantage of the cache, leading to higher fps rates and a smoother gaming experience. I'm not sure how much additional gain there is to be expected, but in the best case it could be as much as 25%. Realistically, it may be closer to 5% to 10% gain because the stripification algorithms (such as NvTriStrip) often improve locality already by joining strips into patches. An extra boon is that optimizing for the vertex cache is *much faster* than trying to find the longest strips (there are linear-time algorithms!!). So, the optimizer will also run faster, definitely once I've profiled the code (I still have to do this...).

Still, there are different ways to represent such cache optimized geometries. In total, I've coded 4 different versions, as I'm not sure which approach is better. I'd be very grateful if some of you - particularly if you have a low-end video card!! - would want to test each of these and get back to me with your results: it is definitely worth trying this on many different types of hardware, and mileage may vary. But I hope one of the versions will be a clear winner...

Installers for the different versions

Below are links to the installers for the 4 different versions. One of them actually does not optimize for the cache, yet I've included it since it could be that on very old hardware the benefit of cache optimization is not as much as the benefit of having longer strips (this could happen for example if the cache is extremely small).

http://www.sendspace.com/file/t3abjj
http://www.sendspace.com/file/0u2y7b
http://www.sendspace.com/file/w1km3g
http://www.sendspace.com/file/4wh4v3

Posting your results

I guess most of you know this, but to see frame rate in Oblivion, start the console (tilde key), enter "tdt" and close the console again (tilde key). Obviously higher numbers are better. It's easier to collate all the information in a single place, so, if you have a sourceforge account, please post your results on the tracker webpage rather than in this thread:

https://sourceforge.net/tracker/index.php?func=detail&aid=2994654&group_id=199269&atid=968813

On the tracker page you can also follow the progress.

Thanks in advance to anyone who helps with testing this!

EDIT

@Elenhil: I forgot to mention, but all the above installers also include the new collision optimizer (which is pretty well tested by now, still some bugs in it but nothing you'd notice in-game). Just pick the first installer, and optimize in the usual way, if you want to use it (this one doesn't yet include the vertex cache optimizer so is most stable, and has least chance for bugs).

Okay....
I downloaded the second from top "vertex cache smallest size". Guess I'll run it on original meshes and not on already pyffid - which of course brings the question; what do you think would happen then, if one re-pyffied meshes? Just curios

But my meshes folder is a mess, but I'll start with the NPC affecting meshes as that is where it will "happen".

Thanks - you are an Oblivion saviour amorilla!

@Locksley: Thanks, it will be useful also to have confirmation that the NPC problem is fixed not just on my hardware (Geforce 8800 GTX). To answer your question: it doesn't hurt to run any version of pyffi on meshes that were already pyffid with another version - it shouldn't make any difference at all. Aside, on my system, "vertex cache smallest size" does slightly (though definitely) worse than "vertex cache strips" (although I don't have a good explanation for this...). I still have to test the other two more intensively before I'm able to draw further conclusions.

If I install one of the new versions, can I just right click to pyffi and it will do the new optimizations?

Also, is vertex cache strips the one you tested for the fps gain? Will it give the best results?

Yes



In theory, any of the three vertex cache ones should give about the same performance. I've seen some small differences nevertheless. Initially, I would have guessed that the "smallest size" gives best performance, but apparently, on my system at least, it does not (by a small but noticable margin). So I'm curious to find out if it's just my system or if it is something more systematic.

Once the results roll in, we'll hopefully know which is best generally. That's the goal here.