Pherim

Alright, so I conducted a few tests, and they pretty much confirmed the suspicions I've had since I've been taking a closer look at meshes and their optimization recently. To make sure I'm not limited too much by the CPU I created an empty test cell with a platform for my character to stand on, and a number of instances of one of the most complex meshes in the game, the Leyawiin Mages Guild interior. It has about 35,000 triangles (not counting the collision geometry, which was irrelevant for this test) and causes exactly 15 draw calls, according to ReShade. First of all, it didn't really matter if I put 5, 10, 20 or 40 of them in the cell, with unlocked FPS I didn't even come close to the GPU limit, it seems. The more objects there were in the scene, the lower my GPU load actually was, because the additional draw calls are forcing the game into the CPU limit. With 80 instances rendered I only got about 45% GPU load, as now there were over 1000 draw calls. To get to the actual GPU limit (I've done that in Morrowind, it was several Millions of triangles), one would probably have to make a custom mesh with just one NiTriShape with the maximum possible amount of triangles, which is 65k, I believe (2^16), and place a whole lot of them in the cell. That way, 1 million triangles should be theoretically possible with just 15 draw calls. Maybe I'll try that next. Anyway, what I wanted to know was if NiTriShapes or NiTriStrips with a single strip were faster, and if Pyffi optimization had a noticeable effect on performance. The vanilla meshes mostly use NiTriStrips with a single strip each, and you often read that NiTriStrips are rendered "more efficiently". However, the latest "stable" version of Pyffi (2.2.2) converts them into NiTriShapes by default, which made me wonder if there really was a difference. The answer may surprise you... Alright, no more clickbait :wink:. With the vanilla mesh (NiTriStrips) and 40 instances of the mesh on the screen, I got around 370 FPS in an otherwise vanilla game (so no mod scripts or graphics extenders interfering). Then I used NifSkope to convert the NiTriStrips into NiTriShapes (Mesh->Triangulate), and this actually improved my performance, I was now at 380, give or take. That's about a 3% increase, not much, but it's there. As far as I know, NiTriStrips are mostly more efficient to store, as you don't have to store three vertices per Triangle, because two connected triangles can share two of them. With NiTriShapes, every Triangle has three vertices, and many of them are in the same place, if they belong to adjacent triangles (if these have the same vertex normals, the edges between triangles will be smoothed so it looks like a continuous surface). So, if anything, NiTriStrips might have reduced the file sizes which could have improved loading times back when Oblivion was released, although they were then compressed in the BSAs (and BSA compression is quite efficient for .nif files), so the difference could not have been a lot. And with modern high-speed SSDs, this has become a negligible factor. In fact, the triangulated version is slightly bigger than the stripified one, but not much. Now for Pyffi. First of all, Pyffi usually reduces the file size further than just with NiTriStrips. I don't know what exactly it does, but on vanilla meshes, it can be up to 10%. However, when I used Pyffi on the test model, there was absolutely no performance difference compared to the triangulated one. It may be possible that NifSkope does a few optimizations itself, but as I said, the triangulated version was slightly bigger in file size than the stripified one, and the Pyffi'ed one was smaller than both. Keep in mind that this is a single static mesh and a highly artificial test environment, so it is possible that the results are different in real gameplay. However, I don't believe that it really makes a noticeable difference, especially as modded installations are usually hard in the CPU limit. If you have tried similar things and got the same or different results, please let me know! Edit: My explanation about the difference between TriShapes and TriStrips was not entirely correct, as with TriShapes, adjacent triangles can also share vertices. The main difference seems to be that they are ordered in a certain way that makes them more efficient in memory.

The graphics card handles, well, graphics. Yes, modern games can also use the GPU for other things, including Physics calculations, but when Oblivion was released, real-time physics were a pretty new thing in games, and only the CPU was used. Therefore, collision geometry must be as simple as possible, because the GPU is not good at calculating complex geometry. As I said, I suspect that multiple strips in collision geometry are there to split the meshes into even simpler pieces, and only those that actually collide with something have to be calculated. However, that is just a theory and it might be difficult to test it, at least until I found a way to make collision geometry with multiple strips. Strangely enough, the "Stitch strips" setting in the Blender plugin only affects visible geometry, collision geometry is always stitched, as far as I can tell. Either that or try to convert strips to shapes with Sniff, that might be the safest option, though of course you won't have any additional optimizations Pyffi might do. If you use Sniff, be aware that it copies the files into the specified output folder, and you have to merge them with your mod/data folder (depending on how you install your mods) manually.

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. 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. 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.

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".

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.

Looks like it works again!

A strange thing I just noticed about the "Mods of the Month" pages: When they are still loading, the number of votes is shown correctly, but once the page has finished loading (Firefox and Chrome, I haven't checked other browsers), the number of downloads is displayed instead. It wasn't like this a while ago, I'm quite sure.

Another Giveaway? How awesome is that?

GOG and Nexus - two of my favorite websites!

Happy giveaway, everyone!

In response to post #64519381. #64520881 is also a reply to the same post. If they like what they do it's not a waste of time, at least not for the modders who participate in making it, but I agree that there is no reason to believe this will end up being any different than previous projects which aimed to do the exact same thing in the earlier games. To my knowledge, not even a single province has ever really been completed, not even the Morrowind main land in Tamriel Rebuilt, where they didn't even have to create the entire province (although the main land is bigger than the original game). And I totally agree that even if the landscape and towns and everything were finished at one point, there would still be the problem of content. Making all these areas is difficult enough, but filling them with fun and interesting gameplay is a completely different matter. Now, I haven't played Beyond Skyrim: Bruma yet, and from what I've heard it's pretty good, but for a whole continent many times the size of the original game? Not going to happen any time soon (and with regard to Tamriel Rebuild, "soon" could be at least up to 16 years). Skywind is also not available yet, 7 years after Skyrim's release. The only real exception seem to be the guys who made Enderal, who also managed to complete similar total conversions for Oblivion and Morrowind. On the other hand, Black Mesa (a fan remake of Half-Life 1 in the Half-Life 2 engine, if anyone is not aware) seems to be close to completion now, more than 14 years after the release of Half-Life 2 and three and a half years after it became an Early Access Steam Title (so they actually get money for making it now), and that's a pretty linear First Person shooter, no Open World RPG like Elder Scrolls, and certainly no huge open continent with multiple different provinces to explore. What I'm trying to say is these things take time, A LOT of time, and most of them never get finished. Anyway, I don't want to be rude or anything, I have a lot of respect and admiration for people working on projects like this, being a modder myself. But some of the people commenting may be a bit too enthusiastic or optimistic about it. Still, it's great that a part of it can already be played, and even if the entire thing never gets finished, that's more than many other big projects managed to achieve.

What is this I don't even

404 Comment Not Found

There is no spoon.

Yes, TXAA does that... Try FXAA.

Well, I get how the SKSE on Steam could cause confusion, as it pops up in the results when you search for "Skyrim", along with the SE, while the original game has been hidden from the store and can no longer be found this way.

Yes, I can confirm that, too, albeit with the firefox version of this extension. Seems like it was updated just a few days ago, maybe that's the cause?

Not possible, as far as I know. You'll either have to - set the game resolution to the desktop resolution - set the destop resolution to the game resolution - play in full screen Maybe you can try doing it with the windows magnifying tool or find a program that works similarly, but that's probably not going to be a real solution, as well.

Well, yes, I guess it does, but there have been occasions where I wanted to use them AND write something with "D... but then again, smileys are not that important. ;D

I know this is an old post - but nobody has answered it so far and the problem still persists. In fact I found it when I wanted to suggest that "D should not become a smiley, because whenever I try to put a word in quotation marks that starts with a D I get this laughing smiley, but only in the comments section, not in the forums. This is kind of annoying, because when dealing with Bethesda games you often refer to the "Data" folder, and I would like to be able to write this without the space in front of the D. It looks the same as the ;D ( ; D ) smiley, so it is redundant, and for some reason, the quotation mark is still displayed, so actually the "D" alone becomes the smiley. Maybe this can be fixed?

Here is something I just realized and I wanted to share it with all texture artists: Do not use GIMP for .dds export! It will result in bad mipmaps! Most of the time this won't matter much, but especially for textures with alpha channel (transparency) this can become a problem. I first realized it when I played around with a self made grass texture in Oblivion, wondering why my own texture looked alright in close proximity but increasingly bad in the distance. Not only was did it have jagged edges, but it also became darker and more saturated, which made it stand out most unpleasantly instead of blending in with it. I had already noticed this problem with this Oblivion mod before but I couldn't pinpoint it's cause, blamed Oblivion's engine or possibly OBGE for it. But strangely enough, other grasses did not have this problem and that was when I thought that it might be caused by the mipmaps, which made sense given that it only appeared when the object was seen from a distance. I remembered that I had already made the observation that Gimp is quite bad when it comes to resizing images. And as mipmaps are nothing else but resized versions of the main texture, I tried exporting the grass texture with Paint.NET, which in my opinion has very good resizing quality and also built-in .dds export. And suddenly the grass looked so much better, all problems mentioned above were gone. Then I tried it with the texture from the groundcover mod with the same result. Here is a comparison gif: https://lh3.googleusercontent.com/-1yIiU8JcHbA/VRc7kG3r3WI/AAAAAAAACPQ/FEdYNsWQHaU/s0/mipmaps.gif I am quite certain that the creator used Gimp for exporting the texture, as it looked exactly the same when I re-exported it with it again. The difference in the running game is even greater than in the comparison gif, and the further away the groundcover is, the worse it gets. It might depend on your screen and settings how apparent the difference is, but when it comes to the grass texture, it's immense. I might also provide a comparison of that tomorrow or so. Now that I know of this, I will revise some of the textures from my own Morrowind mods (especially the comberry plant) and see what difference it makes in Morrowind. If there also is a noticeable improvement I will probably update them, but we'll see. I hope this was helpful. I for one will not use Gimp for resizing and .dds export any more. However, it still is a great application, and I will continue using it for creating textures and other things. But from now on I will export the finished texture in a lossless format first and then create the .dds and mipmaps with Paint.NET. Edit: As I was just reminded, the GIMP .dds plugin has a lot of options for mipmap creation, including the filter mode. There are many to choose from and probably some are better than the default one. Maybe I'll try them out and compare them to the default one. Still, I assume many people (including myself) don't think much about this and just use the default setting. So I believe it's important to make people aware of this.