PyFFI - Why isn't it more popular?

[AllisterHenderson]

Been having a look at some of the PyFFI mesh optimizing mods out there, and I am surprised they are not more popular.

 

There is PyFFI Optimization Kit or Oblivion - PyFFI Binary Patch kit or Oblivion PyFFI Automator etc.

 

For the improvements in performance (fps), optimizing meshes with PyFFI produces, I was wondering why these mods aren't more popular.

 

I know that BFG99 initially reported that TES4LODGen was crashing their game here & here but then later determined it was because the PyFFI Optimization Kit was initially generating bad _far.nif meshes before TES4LODGen would process them.

 

....So need to avoid running PyFFI on _far.nif meshes! Is there any other reasons why optimizing meshes with PyFFI isn't more popular?

 

What is generally considered the best tool for optimizing meshes with PyFFI?

 

BFG99 said, "PyFFI itself comes with better scripts for Oblivion". The current version of PyFFI appears to be 2.2.2 (https://sourceforge.net/projects/pyffi/files/pyffi/). Is this the best version of PyFFI to use?

What about which version of Python to use alone side it? BRSullivan86 reported in the posts here that Python 3.2.5 worked okay, but had trouble with 3.3.X versions of Python........

 

.....So is using PyFFI itself the best option for optimizing meshes?

[mark12000]

Been having a look at some of the PyFFI mesh optimizing mods out there, and I am surprised they are not more popular.

 

There is PyFFI Optimization Kit or Oblivion - PyFFI Binary Patch kit or Oblivion PyFFI Automator etc.

 

For the improvements in performance (fps), optimizing meshes with PyFFI produces, I was wondering why these mods aren't more popular.

 

I know that BFG99 initially reported that TES4LODGen was crashing their game here & here but then later determined it was because the PyFFI Optimization Kit was initially generating bad _far.nif meshes before TES4LODGen would process them.

 

....So need to avoid running PyFFI on _far.nif meshes! Is there any other reasons why optimizing meshes with PyFFI isn't more popular?

 

What is generally considered the best tool for optimizing meshes with PyFFI?

 

BFG99 said, "PyFFI itself comes with better scripts for Oblivion". The current version of PyFFI appears to be 2.2.2 (https://sourceforge.net/projects/pyffi/files/pyffi/). Is this the best version of PyFFI to use?

What about which version of Python to use alone side it? BRSullivan86 reported in the posts here that Python 3.2.5 worked okay, but had trouble with 3.3.X versions of Python........

 

.....So is using PyFFI itself the best option for optimizing meshes?

Yeah I don't get why it's not more popular either, seems to be very under the radar... Do you have any recommendation for a good texture optimiser/BSA optimiser?

 

Did you end up using it? Did it work?

[AllisterHenderson]

To be honest, I totally forgot I even posted this :ohmy:..... and haven't done any testing with PyFFI mesh optimizing mods. The only "BSA optimiser" I have used is 'Oblivion BSA Decompressor' which just decompresses Oblivion BSA files to reduce loading times and stuttering... Apart from that, I haven't used any optimisers. I use the Mesh Improvement Project and all texture replacers I use are either 1k or 2k.... I wouldn't use 4k, as your FPS will drop badly. You best bet is to look at Oooiii's guide for what texture packs to use.

[Pherim]

Pyffi 2.2.2 is considered the most stable version, yes. I don't know about Pyffi Optimization Kit, but with 2.2.2, I am not aware of any issues with _far meshes, and I have frequently used it on them. There really isn't anything special about them - however, I noticed that Pyffi does give them a special treatment, particularly, removing collision and tangent spaces. However, it seems that it doesn't recognize files where .NIF is spelled in capital letters... having tangent spaces in _far.nif files is no problem in my experience (they are needed for normal maps to work correctly, however, they usually don't have any (or rather, they have blank ones) as normal maps on LOD objects apparently don't use mipmaps in Oblivion and therefore tend to flicker noticeably), I don't know about collision. In any case, I can recommend using Pyffi 2.2.2, I use it frequently (I haven't been playing or modding Oblivion for several years, only recently started modding it again, but from last time I don't recall every having problems with Pyffi-optimized meshes, though it should not be used on certain types of body/head/hair meshes, if I remember correctly).

 

About BSA optimization, I remember someone once tested the impact of BSA compression, though that might have been in Skyrim. In any case, back then HDDs were still common and it was argued that reading an uncompressed file from HDD and decompressing it in memory generally takes less time than reading an uncompressed file from HDD. However, with modern high-speed SSDs it is possible that uncompressed files are indeed faster.

[Pellape]

Puffy has some cool features for sure, but OBSE has been enough for me so far, no doubt. If I ever need to use Puffy commands, I will use them

[Pherim]

Puffy has some cool features for sure, but OBSE has been enough for me so far, no doubt. If I ever need to use Puffy commands, I will use them

I have no idea what you are talking about, this is about the tool Pyffi that is used to optimize meshes. OBSE is something completely different, and I haven't heard of anything called "Puffy".

[AllisterHenderson]

Pherim>

I now consider you the resident Oblivion expert on Pyffi :yes:

... and thanks again for your discovery and releasing your draw calls fix for the Unofficial patches :thumbsup:.

 

So you recommend Pyffi 2.2.2 over the newer Pyffi 2.2.3.......

 

It is a good thing then, that Pyffi 2.2.2, auto removes collision from the generated _far.nif files because you said here

that the extra strips occur in collision meshes and if collision geometry isn't drawn, it doesn't cause draw calls.

 

Would there be any harm in running 'good' meshes (already having 1 strip per NiTriStrips) through Pyffi 2.2.2.... because I was thinking after I finish my next mod build (if I ever do LOL) to just run Pyffi 2.2.2 on my entire Mesh directory.... It would be over-kill for majority of mesh files but will catch some with the 'strip bug', it wouldn't harm already 'good' meshes.. right?

 

Also thanks for tip about Pyffi 2.2.2 not recognizing .NIF, will have to manually rename .NIF files to .nif 1st before running it. Maybe there is some batch 'auto - renaming' program out there I could use.....

Edited September 11, 2021 by AllisterHenderson

[Pherim]

I now consider you the resident Oblivion expert on Pyffi :yes:

I'm not sure I am, really. I just know a thing or two about meshes, but not I'm not really an expert when it comes to Oblivion, to be honest.

 

It is a good thing then, that Pyffi 2.2.2, auto removes collision from the generated _far.nif files because you said here

that the extra strips occur in collision meshes and if collision geometry isn't drawn, it doesn't cause draw calls.

I don't know if collision meshes in _far.nif files has any impact on performance or anything. But they are certainly not needed.

 

But I think you misunderstood what I meant. Collision geometry is NEVER drawn (unless you enable it with the console command "tcg" or "ToggleCollisionGeometry", then you see them as wire frames, and they cause draw calls, thus decreasing performance), so it doesn't cause draw calls even if it has multiple strips, therefore it is ok if collision geometry has them. It is possible that it even increases performance, because maybe only the strips that actually collide with something would have to be calculated, and not the entire collision mesh. Be aware that collision is handled by the CPU, so having complex collision meshes can also decrease performance. Unfortunately, I don't know how to produce collision geometry with multiple strips, so I cannot test whether they improve or decrease performance. However, many of the vanilla meshes have multiple strips in their collision meshes, and importing and exporting them with Blender will stitch these strips so there is only one, and I could try comparing that with vanilla models, but that would require some effort.

The problem I discovered does NOT concern collision geometry, but visible geometry, which can also have multiple strips, but then they cause draw calls and it becomes a problem.

 

Would there be any harm in running 'good' meshes (already having 1 strip per NiTriStrips) through Pyffi 2.2.2.... because I was thinking after I finish my next mod build (if I ever do LOL) to just run Pyffi 2.2.2 on my entire Mesh directory.... It would be over-kill for majority of mesh files but will catch some with the 'strip bug', it wouldn't harm already 'good' meshes.. right?

Don't do that! It is very likely that it WILL break meshes that are perfectly fine. I know I said I don't recall having issues with Pyffi'ed meshes, but I just did, when I tried to fix the meshes from Maskar's Oblivion Overhaul that have the multiple strips issue. Apparently that broke the animations of some creatures, causing CTDs when getting near them.

Definitely use Sniff to detect problematic meshes! Then backup those that it reports, and use Pyffi only on those that have the issue. Don't use it on character models, creatures, possibly also armor and clothes, but I'm not sure about that. It's not a huge issue if some meshes still have the problem. Yes, there may be some FPS impact, but that's better than the whole game crashing, right? And if you get to a place where you experience heavy slow down, save the game, use ReShade to check if there actually are much more draw calls than there should be (however, it is difficult to say how much there should be, as that depends on many different factors, for example whether you are in an exterior or an interior cell, your current point of view, if you are using mods that add objects to the game world, and so on - but I'd say anything more than a couple of thousand is worth checking). Then you need to find out which mesh(es), if any, are causing the problem. Try to find out if looking at specific objects causes huge differences in draw calls or FPS, then try disabling them with the console to see if that helps. And if you think you found one, use FormID Finder to get the object's name and model path.

Never just use a tool like that on your entire folder, this pretty much guarantees that you will end up having more problems, not less.

[Pellape]

Well sorry, I was not entire awaken when I wrote that and I have not used it for any meshes as Nifskope will do similar.

[DrakeTheDragon]

Just for reference, I think the problem with pyffi'ing some NIFs causing crashes is due to there being morphs (EGM/TRI files) along with them. Morphs contain offsets over time on a per-vertex basis using vertex-indices for connection.

 

You already cannot use several of the deformation or optimization tools inside Blender on these meshes for that reason, as everything that even remotely alters either vertex count or order completely breaks the connection to the morphs, which is also known to cause CTD.

For instance the vertex order is already changed the moment you import or export the NIF, why these meshes can only ever be imported as OBJ with the option "preserve vertex order" checked.

 

I think it's not just an estimation that any such optimization steps Pyffi applies will also completely f-up the vertex order, thus break the morphs, thus create CTDs. Never touch NIF files with morphs, unless you completely know what you're doing or are prepared to re-do the morphs from the ground up.