Combining Texture Mods

[AJStoner]

I have a question. I have a fair number of texture mods but was having some issues so I removed a bunch of smaller ones. Would it be of any value to combine the contense of all my non-esp texture mods into a single folder and make a fomod from that?

[dubiousintent]

I have no experience with that, but logically it does not make sense. If the files have the same name as an existing file in the same folder, they will overwrite. Otherwise they are unique and your problem is the total amount and cumulative size, which will not be changed. The folders are essential for where the mesh is looking for it's related texture, so getting rid of them will break things.

 

It would likely be more beneficial to look into reducing the size of the textures so they are all the same, and smaller. Ultra-resolution (4096x4096) is actually more than most people can really distinguish on their display: primarily due to monitor limitations but also because of how the eye works physically. It's high definition for little practical gain. High-res (2096x2096) is more than sufficient for most people, and mid-res (1024x1024) is significantly better than standard. There are tools such as "Texture Optimizer" designed to make reducing resolution relatively painless. See the TESTG pages "Utilities" and "Optimizing Files" for more detail.

 

-Dubious-

[uhmattbravo]

Also, if you're using Mod Organizer, since it stores mods in individual folders, there could be some that override others, which would essentially be a waste of space because similar to changes added by plugins, the last one loaded 'wins' any conflicts. In that scenario, unless you've already tried (or went through) each replacer individually, there could easily be textures you like better that you're not seeing because the last one loaded overrides them.

[AJStoner]

Understood, but what I mean is am I putting less stress on my system by having one big Texture mod (assembled from the individual ones I want) as opposed to having over a dozen texture mods running at once?

[dubiousintent]

Suspect this is a question of semantics. A "mod" is just a collection of resources, of which textures are one type of asset. The textures remain as individual files. (They have to, as the meshes are looking for those individual files. Take a look at a BSA file and it's structure.) What you are most likely suggesting would be to create a BSA file as a way to collect a number of individual files together. However, in order to be accessed, a BSA file requires an ESP with the same name (or at least the same beginning portion for both the ESP and BSA; see existing game pairs for examples) to get loaded. So you would have to merge the associated ESP files into one file as well, and then create a BSA for that file.

 

All textures do not get loaded at once. They get loaded when a cell is loaded that has meshes that call for them. The more meshes/objects placed in a given cell, the more textures that get called. So, packing them into a single big mod or BSA does not lessen the number of textures that get loaded.

 

As for system efficiency, the biggest bottleneck will be disk latency: the time it takes to move the drive head from one physical location to another. De-fragmentation of your hard disk is the best thing you can do. Having the files in a BSA will keep them together. But the game engine does not get involved in this: it just requests a file from the system and loads it when a cell is loaded. However, the game engine does not have any mechanism for determining which BSA file to use if the same mesh/texture file resides in more than one, so it grabs them from random BSAs. ("ArchiveInvalidation" does not overcome this issue. It simply tells the engine to use "loose files" in preference to BSA versions.) This often causes random weird visual artifacts: sometimes there and sometimes not.

 

Other mitigations to reduce stress from too many texture replacements:

* The INI setting "bBackgroundCellLoads=1" will enable the engine to load the next cells it believes it will need as a background process, improving efficiency. (Without checking I'm pretty sure this is the default.)

* "uGridsToLoad=5" should be left alone, as the engine has code that only works correctly at this setting. It must be an odd number value.

* Too large a FOV setting (which has interactions between several settings; use the mod "FOV Slider" to catch them all) can cause more adjacent cells to be loaded, which increases stress on the system.
* Prioritize whats important to you, and realize there WILL be limits you cannot overcome.

 

-Dubious-

Edited April 12, 2017 by dubiousintent